I had a good time patching my SharePoint 2010 Dev VM today and thought I would share. This is another good reason that you should detach your content databases prior to patching
I started out with my box at RTM SharePoint 2010. Downloaded the August 2010 Cumulative Update. Ran the setup, rebooted when prompted, then started the configuration wizard. The wizard seemed to hang stating that the upgrade was being performed in the Timer Service and was 10% complete. Seemed odd since I didn’t remember having much content in this environment. I crossed my fingers, but it was no use, it eventually failed. I then tried the command line version, just so I could see something happening:
PSConfig.exe –cmd upgrade –inplace b2b –force
A couple of times the upgrade status would show 88.15% complete (an oddly precise number), then would fail catastrophically. I eventually made my way to the upgrade log file in the \14\Logs folder to see what I can find in there as the PSConfig log and the Trace logs are not being very helpful. This is when I find the following entries:
[OWSTIMER] [SPSiteWssSequence] [ERROR] [10/19/2010 5:11:57 PM]: Action 220.127.116.11 of Microsoft.SharePoint.Upgrade.SPSiteWssSequence failed.
[OWSTIMER] [SPSiteWssSequence] [ERROR] [10/19/2010 5:11:57 PM]: Exception: <nativehr>0x80070002</nativehr><nativestack></nativestack>There is no Web named "/sites/Code/Sub1/Sub2".
Great. Looks like an orphan. I then ran Get-SPContentDatabase, and I saw a content database that was from my SharePoint 2007 environment. At this point, the memories flood back, and I remembered that I was using the database to see what would happen during specific upgrade scenarios. The upgrade failed on the 2007 database when I mounted it to the 2010 farm, so not surprising the upgrade after the patch is failing. Guess that will teach me for not cleaning up my messes. Since I wasn’t using that database anymore, I ran Remove-SPContentDatabase and passed in the name of the Content Database I wanted to remove. This worked, and I was able to upgrade the farm and continue working.
Note: The Remove-SPContentDatabase command actually deletes the database from SQL as well as detaching from the farm. If you just want to detach the database from SharePoint, use the Dismount-SPContentDatabase.