How *Not* To Install SQL 2008 R2 - A Cautionary Tale

I was recently tasked with adding a SQL Server 2008 R2 instance to an existing three-node Windows 2008 cluster that was already hosting two SQL 2008 (not R2) instances.  I fired up R2 setup on the first node and received the following error (retrieved from C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20101005_104106\Summary_<server>_20101005_104106_ComponentUpdate.txt):

Overall summary:

  Final result:                  Failed: see details below

  Exit code (Decimal):           2064843076

  Exit facility code:            787

  Exit error code:               324

  Exit message:                  MsiGetProductInfo failed to retrieve ProductVersion for package with Product Code = '{FBD367D1-642F-47CF-B79B-9BE48FB34007}'. Error code: 1608.

  Start time:                    2010-10-05 10:46:00

  End time:                      2010-10-05 10:53:03

  Requested action:              ComponentUpdate

Like pretty much every DBA I know, I went to my primary troubleshooting tool, Google (sorry Bing) and looked for “MsiGetProductInfo failed to retrieve ProductVersion for package” – this led me to this blog by Dibakar Dharchoudhury  (Sanjayap on MSDN) about a similar but related problem he encountered when upgrading SQL 2005 to 2008.

The amazing part of this to me (I would love to read something by an MVP or MCM explaining why this is this way) is the following bit describing how to find the offending registry entries:

Get the Product Code = '{0826F9E4-787E-481D-83E0-BC6A57B056D5}' from the error message that you are getting.

Byte reverse the first part from 0826F9E4 to 4E9F6280.

Search in the registry under HKEY_CLASSES_ROOT\Installer\UpgradeCodes and try to find a match.

Take a backup of the registry and delete the parent key.

You have to byte-reverse the first “octet” to find it in the registry?  Seriously?

So I attempted this, changing FBD367D1 to 1D763DBF, and was able to find two offending entries, which I deleted and then continued on past that stage of Setup.

…and then found I had made a more crucial error:

I didn’t have enough free space on my C: drive – a horrible rookie-type mistake that unfortunately was staring me in the face.  I needed at least 4.9 GB free and I only had 3.5 GB – with insufficient temp or user data I could clean – ouch!

I made the mistake of assuming “this is a relatively new server cluster – the C: drive will be OK” – WRONG! – ALWAYS CHECK!

At least we learned something else – we are fairly new at rolling out Windows 2008 in our environment and didn’t realize that the 32 GB C: drives we have been using standard for Windows 2003 won’t quite work with Windows 2008, where C:\Windows is now ~10 GB larger at install (and will get even larger over time) due to an architecture change related to the C:\Windows\WinSXS folder (as described here by Joseph Conway, an escalation engineer at Microsoft: )

So, I worked with our Storage person and Server staff and we got the C: drive expanded to 50 GB overnight – the next morning I tried the install again and received this error:

MSI (s) (1C:BC) [12:32:13:163]: Specified instance {FBD367D1-642F-47CF-B79B-9BE48FB34007} via transform :InstID01.mst;:InstName01.mst is already installed. MSINEWINSTANCE requires a new instance that is not installed.

That was a new one to me, so I Google’d “MSINEWINSTANCE requires a new instance that is not installed” and “SQL 2008” to see what I could find…not much – various errors related to a given instance name already existing, or various Reporting Services install-related errors that talk about finding the offending GUID in the registry and deleting it (sound familiar?) So I fired up regedit, and searched for the instance ID in the error message – nothing.

After reading some more and spinning my wheels for a half hour or so I remembered my issue from the previous day, and sure enough, the instance code matched the offending product code from that attempt, and byte-reversing the first “octet” of the instance code from FBD367D1 to 1D763DBF allowed me to find it in the registry.

46 times.

Apparently the failed attempt (with insufficient C Drive space) had left 46 hooks in the registry referring to that code – all of them in the

HKLM>SOFTWARE>Microsoft>Windows>Installer>UpgradeCodes

and

HKLM>SOFTWARE>Microsoft>Windows>Uninstall

registry hives.

So I went through and cleaned them out, and whadyaknow -  my install went through successfully – workstation tools, etc. upgraded from 2008>>>R2 and new R2 instance ready to go.

So - lessons of the day:

(1) Windows 2008 takes up more room on the system drive than you may be used to - thanks Joseph Conway @ Microsoft!

(2) Always check for byte reversed product codes if you can't find the straight product code in your registry (checking context once you do to make sure you aren’t about to delete the registry keys for your virus software or some other non-related software!) – thanks Dibakar Dharchoudhury!

(3) ALWAYS CHECK YOUR C: DRIVE TO MAKE SURE THERE IS ENOUGH FREE SPACE *BEFORE* YOU INSTALL SOFTWARE!

Learn from my mistakes and have a great day!  {-: