One of many Microsoft patches used the Microsoft Update.exe Package Installer and that got me almost into trouble tonight…

The Update.exe Package Installer relies on Update.inf to check wheither the update, patch or hotfix is suited for the operating system and patch levels of your application.  Normally, this poses no problem, but at times you might have something running which was supported, and then not.

So tonight seemed to be the case.  For various reasons, I had an Exchange 2000 Server running on a Windows Server 2003.  On paper incompatible, but with Service Pack 3 of Exchange, it works fine.  Up until you want to run the August 2004 Exchange 2000 Server Post-Service Pack 3 Update Rollup from KB870540 and are greeted with a screen which tells you:

Now, offcourse, you go check the registry settings for your Exchange Server, and notice the actual “NewestBuild” DWORD value in HKLMSoftwareMicrosoftExchangeSetup clearly states 4417 (or 0x00001141 in hex).  So the installer must be clearly mistaken.

Halfway, tho.  After extracting the Package Installer with the -x argument on the command line, I am greeted with the standard Package Installer layout: a directory with all the package files, and a subdirectory Update which hosts the infamous update.exe and it’s friend update.inf.  On closer examination of Update.inf, I notice that the first segment of the file, the [version] segment, has multiple settings for minimum and maximum version requirements for the OS and – in this case – Exchange.

I did the normal fiddling: changed the Exchange build values in the .inf file, changed them in the registry, …  All but to no avail.  There was light in the darkness when I tried to modify the NT version builds, up until the point where lowering the Windows build versions in regedit did not give any effect, and modifying them in update.inf giving the following message:

The Cryptographic Service provides three management services: Catalog Database Service, which confirms the signatures of Windows files; Protected Root Service, which adds and removes Trusted Root Certification Authority certificates from this computer; and Key Service, which helps enroll this computer for certificates. If this service is stopped, these management services will not function properly. If this service is disabled, any services that explicitly depend on it will fail to start.

That is the official version.  The reality is that, once you stop this service and run Update.exe, this service is started again.  Even if you disable the service, the service pops up again and welcomes you with the nasty error message, blocking installation of the patch.

I started fiddling some more.  I wrote a quick batch script that would continously stop the Cryptographic Service.  When it ran, Update.exe would not continue: it needed confirmation from this service that the added update.inf was genuine! And offcourse, an update.inf with changed build numbers for my OS failed the test.  So I needed a solution where my update.inf would ánd pass the test, ánd have a different setting than the original. 

I wrote one last final hack as a batch file:

net stop "Cryptographic Services" 
copy update.good.inf update.inf 
start update.exe 
ping localhost 
copy update.orig.inf update.inf

It stops the nasty service, gives time to copy a “faulty” update.inf with a higher build number to accomodate for Windows 2003’s 3700’s build number, start Update.exe, wait a few seconds for Update.exe to read in the “faulty” file (sleep.exe is not default installed on Windows 2003) and copy the “correct” file before Update.exe launches up the Cryptographic Services again to check on Update.inf’s genuinity.