Error 1053 While Installing SQL 2005 on Windows 2003

We are moving an old SQL 2005/Windows 2003 server from one blade to another (retiring old blade chasses due to switching hardware vendors) and unfortunately can not move it to Windows 2008 or SQL 2008 due to lack of vendor support (sigh).

As such, I was installing SQL 2005 on the new Windows 2003 SP2 box and during the install I received the following error for the Database service itself:

Unable to start service (1053)
Error Code: 0x8007041d (1053)
Windows Error Text: The service did not respond to the start or control request in a timely fashion.

I turned to my trusty troubleshooting tool of choice and Google'd the hex error code, which brought me to the Microsoft Support Page On a computer that has a multicore processor, you may be unable to install SQL Server 2005.

Sure enough, I was installing on a blade with two multi-core CPU's (Dual Socket AMD with 6 cores each) so I continued to read down the KB article.  There are two workaround methods listed for Windows 2003, and the first method (expanding the SP file and using the HOTFIXPATCH switch to slipstream the SP into the install) didn't work.  I still received the message that the SQL Service would not start.

Sigh.

I almost went looking for a different answer but decided first to at least try the second option - manually changing the number of logical processors visible to 1 using msconfig.  I followed the KB steps, checked Add/Remove Programs to see that it didn't show a SQL instance installed, and tried running the SQL install again, only to have the installer tell me that there is already a default instance of SQL 2005 present on my machine!

ARGH!

I opened Add/Remove Programs and removed everything SQL-related that was listed, and ran the install again - SUCCESS!  I then applied the SP, rebooted the machine, used msconfig to revert to "Normal Startup" and all was well.

Now I just need to remember this next time!

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!  {-: