Introduction
I was recently installing SharePoint 2010 SP1, June 2011 Cumulative update and April 2012 Cumulative update. While going through the patching, I encountered couple of unusual errors. Both the issues were encountered while running the PSConfig command post the patch installation. One of the issues was related to an orphan database entry for webapplication in the SharePoint config database when running the PSConfig command after installing SP1 while, the other issue was the PSConfig command kept failing with the error that June 2011 Cumulative update SharePoint server patch (not the SharePoint foundation patch) was not installed on the servers but, was in fact installed on all the servers.
Issue 1
Description
The first issue I faced as mentioned above was after installing the SP1 patch and trying to run PSConfig command. I have done a fair bit of patching but never encountered this issue. The PSConfig failed and referred to the upgrade logs as usual to find the error. The upgrade log error listed below was cryptic and did not provide any direct information on what was causing it.
Resolution
After breaking my head and stuck at this point I ran a script that we used to list all the databases attached to all the webapplications in the environment. When I checked the file with the output, I found that there was one line with nothing listed there except quotes. This indicated that there was some orphan database entry for a webapplication but was not sure which one. Following are the steps taken to find the webapplication and orphan database entry.
Run the following commands for all the webapplications in the farm
Note – This is easy to figure if you are using dismount and mount method for patching and upgrading the schema. When all the databases are dismounted and you run this command, the count for databases should be “0”
$db = get-spwebapplication –identity “url of the webapplication”
To get the count of databases attached to the webapplication type the following and hit enter
$db.contentdatabses.count
This outputs the number of content databases attached to webapplication on the screen, which in our case should be “0” because we have dismounted all the databases for upgrade. Finally one of the webapplications showed the count as “1” which meant that we had got our culprit webapplication. Next step was to delete the orphan entry to do which we needed the guid of the database.
To get the guid we ran the following sql query on the config database (objects table).
select name, CAST(properties as XML) from objects where Properties like '%SPIisSettings%'
This provided as on output as shown in the screenshot below. The left column contained the name of the webapplication and right column contains a link to an xml file that lists all the properties of the objects table.
We went through the xml file associated with the webapplication that listed the database count as “1” and searched for the following pattern.
<sFld type="Guid">74b52848-f29e-48bb-ab01-5e7aed5d3743</sFld>
<fld type="null"/>
Where the “null” in the “fld type” tag denoted an orphan object. We noted down the guid. The next step was to delete the entry. We ran the following commands to do that
$db = get-spwebapplication –identity “url of the webapplication that had the null entry”
Next run the following command to delete the orphan entry
Use the guid we noted down in the earlier step when we ran the sql query. Once the command has run successfully, please verify that the databases count is “0” by the running the following command
$db.contentdatabses.count
Now you can rerun the PSConfig command and it should complete successfully.
Issue 2
Description
This issue cropped up when we ran the PSConfig after installing the June 2011 Cumulative Update. The PSConfig would fail with the error that the June 2011 Cumulative Update patch was not installed on all the servers in the farm. We verified that the patch was installed on all the servers by checking the installed updates through control panel > programs.
Resolution
We ran the following version of the PSConfig to resolve the issue. This way of running the PSConfig skips the install check part on the farm.
psconfig.exe -cmd upgrade -inplace b2b -force -wait -cmd installcheck –noinstallcheck
The PSConfig should run without checking the patches installed but once the command is completed successfully, please go to central administrator> upgrades and migration> Check product and patch installation status and make sure that none of the patches are listed as missing and the patch for which the PSConfig was failing is listed as installed.
For issue 1, the following thread helped me
http://sharepoint.stackexchange.com/questions/31964/sharepoint-server-2010-update-and-psconfig-issue
Special thanks to my dear friend and colleague Colin White who provided me with his expertise in resolving the above issues
