Cannot Access CompanyWeb After Installing 948110

[Today's post comes to us courtesy of Damian Leibaschoff and Justin Crosby]

SharePoint users who upgraded from SQL Server 2000 Desktop Engine (WMSDE) to any other edition of SQL Server 2000 (for example, SQL Server 2000 Standard Edition) may be incorrectly offered a WMSDE update for 948110. This problem can occur if the SQL Server 2000 edition is not patched correctly with SQL Server 2000 Service Pack 4 after the upgrade from WMSDE. The WMSDE update may cause SharePoint to stop working.  The issue we are discussion does not apply to SBS 2003 R2 users that migrated to SQL 2005 Workgroup Edition.

The symptoms the you will notice is that the service instance (e.g. mssql$Sharepoint) will start and then immediately stop.

In the C:\Program Files\Microsoft SQL Server\MSSQL$Sharepoint\Log\errorlog file you will see the following:

2008-07-09 09:38:33.30 spid2     Skipping startup of clean database id 4
2008-07-09 09:38:33.30 spid2     Skipping startup of clean database id 6
2008-07-09 09:38:33.30 spid2     Starting up database 'STS_Config'.
2008-07-09 09:38:33.38 spid5     Clearing tempdb database.
2008-07-09 09:38:33.41 spid5     Starting up database 'tempdb'.
2008-07-09 09:38:33.44 spid2     Recovery complete.
2008-07-09 09:38:34.35 spid2     Database 'master' has invalid schema.  <==Notice the invalid schema. 

The Windows Update detection logic is being fixed and this update should not be offered incorrectly to non-qualifying products, this change is still pending and should happen at any time now.

If you are not sure if you have SharePoint was upgraded to SQL 2000, you need to check the ERRORLOG files prior to the update being installed and review the versions reported there. The log files are usually found in C:\Program Files\Microsoft SQL Server\MSSQL$SharePoint\Log\, if you cannot find an ERRORLOG.n file that is older than the time of when the update was installed, try to get an older ERRORLOG from backup or shadow copy.

The CURRENT ERRORLOG will say:

2008-07-09 09:38:32.94 server    Microsoft SQL Server  2000 - 8.00.2050 (Intel X86)
Mar  7 2008 21:29:56
Copyright (c) 1988-2003 Microsoft Corporation
Desktop Engine (Windows) on Windows NT 5.2 (Build 3790: Service Pack 2)

While the older ERRORLOGs should say:

2008-06-17 09:53:09.12 server    Microsoft SQL Server  2000 - 8.00.2039 (Intel X86)
May  3 2005 23:18:38 
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

If this is your case, then you must properly update the instance back to SQL 2000 standard to regain functionality:

1. Perform the upgrade again to SQL Server 2000.
   Note You must use the same media that was previously used to perform the upgrade to SQL Server 2000.
   Please refer to the Premium Installation Step that shipped with your version of SBS 2003.  This can be found in the root of the Premium Technologies CD.
2. Restart the server instance. The server instance should start as the upgraded version.
3. Apply SQL Server 2000 Service Pack 4.
   Note Make sure that you apply the SQL Server 2000 Service Pack 4 and not the MSDE SP4 or WMSDE SP4 updates.
   For more information about how to obtain SQL Server 2000 Service Pack 4, visit the following Microsoft Web page: http://www.microsoft.com/downloads/details.aspx?FamilyID=8e2dfc8d-c20e-4446-99a9-b7f0213f8bc5&displaylang=en
4. Manually apply sp4_serv_uni.sql from the Install folder. To do this, type the following command at a command prompt:
   
   osql -n -b -d master -Slpc:%computername%\SHAREPOINT -i "%programfiles%\Microsoft SQL Server\MSSQL$SHAREPOINT\Install\sp4_serv_uni.sql" -o "%programfiles%\Microsoft SQL Server\MSSQL$SHAREPOINT\Install\sp4_serv_uni.out" -E
   
   Note These steps assume that the WMSDE installation folder is in the default location. If you are using a custom installation, you must adjust the path accordingly in the command.  Also note that this is a single command that has been wrapped for readability.

You do not need to re-apply the security update on this scenario. If you have already rolled back the BINN folder, you will be presented with the option to install the update again. Until the MU detection logic is fixed, make sure you are using Microsoft Update and not Windows Update and select the SQL update (not the Windows update that references WMSDE) (The bottom one on this screenshot)

Note: You may also receive the errors described above if your MSDB database is damaged, this will also cause the upgrade failure. The reason is that the setup needs to apply scripts that use MSDB stored procedures.  This is an uncommon scenario, most servers will not experience this scenario. This is not a problem with the security update per se, rather a latent problem in the instance itself. Any version of SQL can be affected by this behavior. If you are experiencing this scenario please contact support for further options <Link to CSS Support site> .