SQL server service pack installation may fail if your instance name is a Windows reserved word

  • Article

Okay, so I woke up one morning and decided that this was a good day to patch my SQL Server 2008 R2 instance (named LPT2) to Service Pack 1. So I just downloaded the service pack from the Microsoft Website, ran it, went through the screens and clicked on Upgrade. Unfortunately, the Service pack setup failed right away. And even worse, I did not even get the basic error prompt that I feel is the least DBA’s like me deserve. So I decided to take a look at the setup logs.

I pulled up the C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log folder, selected the folder with the date modified that most closely matched the time of the ill-fated installation attempt, and opened the summary.txt inside it….but alas, no clues there. No problem, I thought to myself, lets dig in deeper. So I opened the Detail.txt in the same folder, and searched for the common error strings like “Return value 3” and “at Microsoft.SQLserver”, etc. Surprisingly enough, still nothing…!!!
So I just switched to the basic “failed”, and found this error message:-

2011-10-19 11:08:50 Slp: Attempting to run patch request for instance: LPT2
2011-10-19 11:08:53 Slp: Error: Failed to run patch request for instance: LPT2 (exit code: -2068774911)

By now I was pretty sure this was not a simple, every day issue. Upon doing some (okay, a lot of) research, I arrived at the following conclusion:-

The root cause of the issue was that my instance name was the same as a windows reserved keyword. You can find a list of the Windows reserved keywords here (under the “Naming Conventions” section):-

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx

The issue occurs because from SQL 2008 onwards, the service pack/CU installation creates a folder with the instance name inside the respective "date_timestamp" folder in C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log folder. Since the instance name is a windows reserved keyword, the installation is not able to create the folder, and is hence unable to proceed beyond this point.

Yes, I know you're surprised that we're able to install an instance with such a name in the first place, but that's because the instance folder is named MSSQL10.<keyword>, or MSSQL10_50.<keyword>, so Windows allows the folder creation at the time of running the RTM installation.

The bad news is, there is (did I say unfortunately?) no resolution for this situation. The only way to proceed from here is to use a different instance name i.e. you have to install a new instance and move all the databases over to it.

So if you’re still reading this post, I hope it leaves you with the same lesson that it left me with:-

“DO NOT install instances with names that are windows reserved keywords”

Written By:
Harshdeep Narula,SE,Microsoft GTSC

Reviewed By:
Akbar Farishta. TL,Microsoft GTSC

Vijay Sirohi, Sr.SEE,Microsoft GTSC

Comments

  • Anonymous
    November 02, 2011
    Hi Harsh Thanks for this great info. Really helpful Regards Nitin Brightpoint ME

  • Anonymous
    November 24, 2011
    Helpful article which would deserve a modification of the SQL Server documentation to avoid this problem. But is it only for SQL Server 2008 and later versions ? You wrote for SQL Server 2008 but is it always possible with Denali ?

  • Anonymous
    February 08, 2012
    Hi Papy, Thanks for showing interest in the blog. Yes, this issue is also possible for Denali. But we will have to wait for a service pack for Denali to be released to be sure. Do let me know if you need further info. Regards, HarshDeep Singhj

  • Anonymous
    April 02, 2012
    Okay, I learnt of a workaround for this issue, specific to clusters and SQL 2008 onwards. One of our customers actually did this: He removed a node from the cluster (uninstalled SQL), installed SQL 2008 R2 with SP1 slipstreamed, and then added it back to the cluster. He then failed over, and repeated this process for the other node. All this while retaining the same instance name, which is a windows reserved word. Though it's not something I recommend, it does indeed work. How? Simple. Since the Service Pack is slipstreamed with the base installation, it does not need to create a folder with the instance name in the Setup Bootstrap<datetime> folder, and hence succeeds. Also, everytime there is a Service Pack released, you will have to go through the entire process. Not very neat, but a workaround nonetheless.