I needed to upgrade MOSS 2007 farm on a Windows 2003 Server from the RTM version to Service Pack 1 as a required step to prepare for a migration to Windows 2008 64-bit. The process involved installing the WSS 3.0 SP1, ignoring the Configuration Wizard, running the MOSS 2007 SP1, then running the Configuration Wizard. In this case, the last step of the Configuration Wizard failed. The Wizard screen said to look in the event log, which showed three errors similar to this:
Configuration of SharePoint Products and Technologies failed. Configuration must be performed in order for this product to operate properly. To diagnose the problem, review the extended error information located at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\PSCDiagnostics_5_8_2009_19…log, fix the problem, and run this configuration wizard again.
I consulted the PSCDiagnostics log, but all it did was repeat the error message shown above. Looking in the Upgrade.log file, the last entry looked like this:
[SPManager] [INFO] [5/8/2009 7:45:10 PM]: Inplace Upgrade session finishes. root object = SPFarm Name=SharePoint_Config, recursive = True. 1 errors and 0 warnings encountered.
Searching back up through the file, I found one area where errors were reported:
[SPManager] [ERROR] [5/8/2009 7:45:03 PM]: Pre-Upgrade [SPSite Url=http://sitename/sites/TestSite] failed. Microsoft.SharePoint.Upgrade.SPSiteWssSequence has the ContinueOnFailiure bit set. Moving on to the next object in sequence.
[SPManager] [ERROR] [5/8/2009 7:45:03 PM]: The system cannot find the path specified. (Exception from HRESULT: 0×80070003)
The error was caused by a site that is no longer there. This happens sometimes when a site is deleted from SharePoint, but it doesn’t get removed all the way from the configuration database. It will often show up in Central Administration after you have deleted it.
Looking through the Microsoft SharePoint Service Pack 1 installation documentation, there were no fixes in the troubleshooting section that fit this scenario. I found many articles about removing orphaned sites, but this site was not a true orphan (its parent was not missing). If you have a true orphan, you can use the stsadm parameter databaserepair.
In this case, the solution was to detach the content database within SharePoint then reattach it. When you do that, it removes the old entry from the configuration database. This operation can normally be done by detaching and reattaching a content database within Central Administration, but since the upgrade was not complete and the farm disabled, I used stsadm.
stsadm –o deletecontentdb –url http://sitename –database contentdatabasename –databaseserver sqlserver\sqlinstance
stsadm –o addcontentdb –url http://sitename –database contentdatabasename –databaseserver sqlserver\sqlinstance
*The deletecontentdb parameter does not delete the database, it only detaches the reference to it from your SharePoint farm.
After this, I ran psconfig at the command line:
psconfig -cmd upgrade -inplace b2b -wait -force
Once that completed successfully, I launched the Configuration Wizard manually from All Programs > Administrative Tools > SharePoint Products and Technologies Configuration Wizard to get visual confirmation that the upgrade was completed.
After upgrading SharePoint, always check the Upgrade.log in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS for “Finished upgrading SPFarmn Name=<configuration database>”, “0 errors and 0 warnings” at the end.