How to unblock Windows Server 2003 SP1 setup if a beta version of SP1 is installed on the machine

  • Article

I received this comment from a customer last week, and some investigation led to an interesting problem and solution I wanted to share here. This customer was having trouble and getting some odd errors while installing and trying to use Symantec System Center on Windows Server 2003. The customer reported that they have Windows Server 2003 service pack 1 installed on this machine. Initial troubleshooting showed that the version number of the Windows Installer files on this machine were 3.1.4000.1289.

Based on some past experience, I knew that build 1289 was not the final build number for Windows Server 2003 SP1 (it is actually 1830), so I asked the customer for some additional information to try to figure out how the machine got into the state it was currently in and then figure out how to upgrade it to the final release of SP1. It turned out that this machine had a beta build of SP1 installed, but SP1 was installed using a slipstream method that caused it to not allow the user to uninstall it. This was complicated by some setup logic in the final release of SP1 and in the installer package for Windows Installer 3.1 that blocked the customer from being able to install the final build of SP1 or the final release of Windows Installer 3.1. The setup UI for SP1 told the customer to go uninstall the beta version of SP1 first, but since SP1 was installed via slipstream, there was no Add/Remove Programs entry, and the files were not cached in the %windir%\$NtServicePackUninstall$\spuninst folder to allow for manual uninstall either.

Since this machine was currently being used in production, we wanted to try to avoid needing to rebuild it from scratch. I used some knowledge I had from previous projects about how Windows service pack setup logic works to see if I could trick the installer into letting me run it even though there was a beta build of SP1 installed. Windows service packs and hotfixes use the following registry key/value to determine what OS service pack is installed and then decide whether or not to allow the user to run setup based on this data:

  • Key Name: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows
  • Value Name: CSDVersion
  • Data Type: REG_DWORD
  • Value Data: multiples of 256 - for example, if SP1 is installed the value = 256, if SP2 is installed the value = 512, etc

So, what I saw on the customer's machine was tha tthis value was set to 256, which made SP1 setup think SP1 was already installed. I changed this value back to 0 and re-ran Windows Server 2003 SP1 setup and it allowed me to install and correctly updated all of the files and registry to the final released version of SP1. Once I did this, I saw that the version of Windows Installer files now showed 3.1.4000.1830. Then, the customer re-tried the Symantec System Center scenarios that were failing previously, and things started working as expected.

Please note that this method of working around the beta block inside of Windows Server 2003 setup is not an officially supported method. But if you are stuck and want to try to avoid rebuilding your server, this might be an option for you. Just make sure that you make a system backup of some sort before doing so (or be willing to accept rebuilding if things don't work as well as they did in this customer's scenario).