Tuesday, September 7, 2010

Orphaned Application Pool in ConfigDB

I ran across a new type of orphaned data in the config database while at a clients the other day. I was in the process of adding a new SSRS server to a MOSS 2007 farm when it started failing on step 2 with the following error:

09/02/2010 22:17:33  8  ERR                      An exception of type System.InvalidOperationException was thrown.  Additional exception information: 1387
System.InvalidOperationException: 1387
   at Microsoft.SharePoint.Win32.SPNetApi32.NetLocalGroupAddMember(String groupName, String userName)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.AddGroupMember(String username, Int32 group)
   at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionProcessIdentity(String strUserName, SecureString secStrPassword, IdentityType identityType, Boolean isAdminProcess, Boolean isWindowsService, String strServiceName, Boolean dontRestartService)

(After banging my head against my desk for a few hours)I took a look and see if the PSCONFIG wizard added any of the application pool to IIS. I noticed that it was attempting to provision a app pool that doesn’t exist! This typically would not be a problem, except that the identity account it was using was local to their WFE server!

At this point, I attempted to simply change the account to the DOMAIN web application account and re-run the PSCONFIG wizard. Aaannnndddd it failed again as it simply attemped to provision the app pool again with the wrong account. So I returned to the drawing board…

SOLUTION:

If you are still reading this then you really must need to resolve this issue. I will give you two methods. The second method below is to be done at your own risk. Please read carefully and take your time (or you might get yourself into a worse situation).

Your FIRST choice to solving this problem is to disconnect your your contentdb(s) from any production web application, disconnect each SharePoint server from farm, create new configdb, add each SharePoint Server BACK to the farm, recreate your web applications, and connect your content databases to corresponding their web apps.

Unfortunately, there also might come a day when you do not have a proper maintenance window available and you need to resolve this without interuption to your users… Below are instructions that directly query your SharePoint ConfigDB.

Manually query your configdb to retrieve the guid of your orphaned app pool.

select *
from objects
where name is not null

Review the list that returned- under the Name column you will see you orphaned app pool along with. Pay close attention to grab the one that says “SPApplicationPool” and copy the GUID from the ID column.

<object type="Microsoft.SharePoint.Administration.SPApplicationPool, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c">

Now that you have your GUID- we can get out of the DB! Lets head to one of the SharePoint Server’s in the farm and run the following STSADM command.

stsadm –o deleteconfigurationobject –id <guid>

1 comment:

  1. Thanks. This post was extremely helpful. Had a non-existent service account on an old app pool in the config db. You saved me a good bit of time.

    ReplyDelete