This was a tricky one!

I was attempting to install the client tools for SQL 2008 on my Vista SP1 workstation. Whenever I got to the "Setup Support Files" step, it would fail with the following error.

TITLE: SQL Server Setup failure.
------------------------------

SQL Server Setup has encountered the following error:

MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{AEB9948B-4FF2-47C9-990E-47014492A0FE}'. Error code: 1608..

First, I tried my old friend, ProcMon. No luck. There was no sign of any access to that GUID in the registry or file system. So I scoured the Google. I found a lot of people complaining about this error with beta versions of SQL 2008 and the only solution was a reformat and reinstall. That's just not acceptible to me.

So, I fired up RegEdit and looked for that GUID. It turns out that GUID belongs to MSXML6. I figured maybe I had a corrupt MSXML6 installation, so I downloaded the package from Microsoft and then attempted to remove the old one in Programs and Features. It definitely was corrupt because it would not uninstall. I had to download and fire up the Windows Installer Clean Up to get rid of it. It's a nice, but dangerous tool, so be careful when using it.

Well, the removal happened without incident and I tried to reinstall MSXML6 from the installer. No luck. It would immediately "succeed" without even attempting to install (I guess that's code for FAIL). It was apparently seeing something somewhere to indicate MSXML6 was already installed still. I wanted to forcefully overwrite it, but nothing I tried worked. I tried MSIEXEC flags for repair and uninstall -- no good!

The only solution at this stage was to look at the MSI itself. MSIs are just simple little databases. It is relatively easy to modify MSIs if the pre-existing installation detection logic is failing (as in this case). Note: THIS IS EXTREMELY UNSUPPORTED BY MICROSOFT, SO PROCEED AT YOUR OWN RISK FROM THIS POINT ON.

Using Orca, which is a handy little tool for editing MSIs (unfortunately, you have to download a very large SDK to get to this tiny tool), I was going to try to remove previous installation detection conditions and force the MSI to reinstall over whatever remnants of MSXML6 were left. I took the shotgun approach because I had no idea which line was causing it to fail (and I was beginning to get very frustrated).

In the InstallExecuteSequence table, I first sorted by the Sequence column ascending (makes it easier to see the order the operations occur). I then dropped the following rows: SkipInstallCA, LaunchConditions, FindRelatedProducts, CA_SetRefCountUpgradeFlag, CA_SetRefCountNewerFoundFlag, IsPendingRebootKey, CA_ErrorDifferentLang, and CA_ErrorPendingReboot.

I then went to the InstallUISequence table and sorted by the Sequence column again. I then dropped the following rows: SkipInstallCA, LaunchConditions, CA_SetRefCountUpgradeFlag, CA_SetRefCountNewerFoundFlag, IsPendingRebootKey, CA_ErrorNewerVersion, CA_ErrorDifferentLang, and CA_ErrorPendingReboot.

That dropped pretty much every potential version-related error condition possible in this MSI that I could see. I then saved the MSI and launched it. MSXML6 installed. Yes!

Okay, so now I thought I had a working MSXML6, but the true test would be if SQL 2008 would install.

So, I fired up the SQL Server 2008 installation and...

IT WORKED!

Mystery Solved.

How did I get a corrupted MSXML6? I have no idea... I wish I did.

I ran into a very strange situation on an old Windows Server 2003 server at work today. The Windows Search service could not be started, stopped, or have its permissions modified by anybody -- not even an administrator!

I first noticed there was something wrong when I tried to apply a Security Configuration Wizard template. Among other things, the template disabled Windows Search, which wasn't being used. It kept failing with an "Access Denied" message. It was very misleading, because it kept pointing to access being denied to a configuration file. In hindsight, this must have been a bug in the way it reported errors, because access was actually being denied via the Security Configuration Manager (SCM), the "service" that runs all other services on Windows.

Before I got a chance to break out with all the fun diagnostic tools (such as SysInternals' ProcMon), I realized that the Windows Search service (WSearch) was still started in the Service.msc MMC. I tried to stop it and got "access denied" which I found to be quite odd.

I then opened up another MMC and added the Security Configuration and Anlaysis snap-in and also the Security Template snap-in. I quickly ran a quick audit and looked at the permissions on the Windows Search service. "Everyone" had "read" access, but only SYSTEM had "Full Control" access. Bummer.

At this point, applying a custom template would do nothing (I didn't have access), but I tried anyway. No luck. So what does one do in this case?

You need to log on as the SYSTEM account. This is actually pretty easy to do if you are an administrator. First, make sure you are either logged on at the console or using the console session in remote desktop. Now, open a command prompt and type "at 10:53 cmd /interactive" minus the quotes. Also, replace "10:53" with the time that is exactly one minute from now. What this does is it tells the old legacy "at" process scheduler to open an interactive command prompt one minute from now. Since there is no direct way to log on as SYSTEM, this is second best. Since everything run via "at" uses the SYSTEM account and since it's told to interact with the desktop (but only the console session), you get a command prompt running as SYSTEM. Fun!

Now, use the "SC" command to apply new permissions. This can be most easily done using the "sdshow" and "sdset" flags. Look up help on SC at Microsoft's website for more information. All permissions for "sdshow" and "sdset" use the SDDL formatted descriptor. If you don't like SDDL, the easiest way to fix this is to boot-strap permissions for your locked up service. Use "sdshow" on a service you know you can manipulate. I used w3svc. Then take the exact string shown and apply it to the locked service using "sdset." Now your regular admin account can use the afforementioned friendlier "Security Configuration and Analysis" and "Security Templates" MMC approach which has the nice GUI. Of course, if you are well-versed with SDDL, you can just modify the permissions directly from the command line.

I can't say why this happened, but it's an old server and has had a lot of roles, so I speculate that some third party application must have screwed up service permissions at some point.

Either way, mystery solved!

As most of you probably realize by now, I love birds -- especially parrots! One issue that always bothered me was how chain pet stores (in particular PetSmart and PetCo) emphasize responsible adoption of dogs and cats, while at the same time sell birds and small mammals from factory breeders (the bird and rodent equivelent of "puppymills"). I have yet to walk into a PetSmart or PetCo where the birds waiting for adoption look healthy and happy.

Well, love them or hate them, the always controversial PETA is on the case. No matter what your opinion of PETA is in general, this particular campaign of theirs is very important. It's quite simple. You sign a pledge that you will not shop at PetSmart (or PetCo or other chain store) until the sale of live animals has stopped and send a letter to PetSmart to let them know of your boycott. With enough people boycotting and enough negative exposure, they will stop this cruel practice on small animals, just as they already have on dogs and cats.

Live animal breeding should be left to the experts in the breed of animal, not chain stores where the animal is subject to an impulse-buy. Sign the petition and send your letter!

http://www.petsmartcruelty.com/