SQL Server Service Pack installation may fail if your instance name is a Windows reserved word
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, and was going through the screens, whistling softly to myself, when….CRASH…!!!! The Service pack setup failed…!!! 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 just thought to myself, "okay fine, Mr. Service Pack, so you wanna play this the hard way? Let’s see what you got."
I pulled up the C:Program FilesMicrosoft SQL Server100Setup BootstrapLog 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 dive 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 "immensely descriptive" 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 had lost track of the tune which I was whistling, and an uncertain frown had taken over my expression. 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 keyword. You can find a list of the Windows reserved keywords here:
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 installation creates a folder with the instance name inside the respective "date_timestamp" folder in C:Program FilesMicrosoft SQL Server100Setup BootstrapLog folder. Since the instance name is a windows reserved keyword, the installation is not able to create the folder; hence it is 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:-
“Don’t install instances with names that are windows reserved keywords”
Please let me know if you have any questions or concerns regarding the issue mentioned in this post. Or, if you have been unfortunate enough to encounter this issue yourself, and know of a workaround for it, your two cents would be highly appreciated.
Comments
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.Anonymous
September 20, 2012
Very helpful post