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):-
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
Thanks for this great info.
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 ?
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.
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.