This article gives a brief description of the workaround when encountering issues during the installation/upgrade of WSS3.0 Service Pack 1.
Scenario
During the installation of the WSS 3.0 Service Pack 1, the SharePoint Products and technologies wizard is started:
After continuing the wizard, accepting the restart of services, and acknowledging that every other server in the farm was updated with new binaries (and is waiting on the same message) step 8 of the upgrade process may fail (only if the particular server has the Windows SharePoint Services Help Search service running).
The wizard states that a error has occurred with the following description:
Failed to upgrade SharePoint Products and Technologies. Further information regarding this failure can be found at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.log.
An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: Failed to upgrade SharePoint Products and Technologies.
Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException: Exception of type 'Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException' was thrown.
at Microsoft.SharePoint.PostSetupConfiguration.UpgradeTask.Run()
at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()
Check the error log
To verify that the error that has occurred is the same as described in this document, please review the Upgrade.log file that was described in the error message normally located in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\.
Scroll down to the bottom of the file and locate the following error message:
Invalid column name 'ItemHighPriority'.
Invalid column name 'CrawlScope'.
This indicates that the described workaround is valid for your upgrade error. Any other errors do not apply to this workaround.
How to work around this issue
After you have verified that the error you received is the same as described here, follow these steps to work around the issue:
1. Disable the Windows SharePoint Services Help Search service for all servers
a. Navigate to the central administration of the environment
b. Open the Operations tab and click on the Servers in Farm.
c. Click on the link/name of the server which is running the Windows SharePoint Services Help Search service and click on the name of the service.
d. Write down the name of the database and stop the service.
e. Do this for every server in the farm that is running this service.
2. Remove the databases from the SQL server.
a. Use the enterprise manager console on the SQL server to detach the Search databases, use the database names retrieved in step 1d.
b. Move the mdf and ldf database files from their current location to a backup location.
3. Re-enable the Windows SharePoint Services Help Search service for all servers that where running the service in step 1.
a. Use the same database names for each server as previously used.
b. You do not have to fill in the usernames/passwords, these where saved in the configuration database even though they appear blank.
4. Re-execute the SharePoint Products and Technologies configuration wizard on every SharePoint server in the farm (the sequence does not matter) and complete the upgrade process.
Effects the workaround has on the server farm
Because all the search databases where re-created, all search data is lost. This can be recovered by initiating a Full Crawl over all content sources.
Also, the backup of the SQL server needs to be checked to see if these re-created databases need to be added in the backup-script.
If the upgrade finalizes successful, the old files of the search databases can be removed.
What caused this?
We don't know for sure, but we suspect this behaviour occurs on farms wich are installed with MOSS Beta 2 and upgraded ever since. (so B2 -> B2TR -> RTM)
Hope this helps you!