So recently I have been charged with updating several SQL Server 2005 clusters from SP2 + GDR to SP3. My experiences have been relatively good but the past few have been downright horrible. I have come across two pretty serious issues, and I am not sure which issue is worse, so I am just going to present them to you in arbitrary order:
The first issue that I have seen on three or four occasions now is the case where the setup routine assures me that patching the database engine has failed; yet, upon rebooting, the sqlservr.exe version, @@VERSION etc. all say 9.00.4035. Also when attempting to install the post-SP3 CU1 update in this case, it never complains and always works without a hitch… and if the instance hadn't been patched successfully, wouldn't it balk? Anyway, the moral of this story is: don't always believe the outcome of the setup program for SP3. It may be telling you that there was a problem but everything about my instances in these cases appears to point to the fact that they are indeed patched and working properly.
The scarier issue I have seen, and luckily this has been restricted to one domain, is that setup for some reason changes mixed mode authentication to Windows authentication only. Initially I thought this was just an anomaly, but I have now seen it on two distinct clusters in this specific environment. I have several questions into Microsoft about this one, and will post more information here when I get some answers. But I wanted to get this out to you because it is something you should watch out for. If you are using mixed mode, please check the authentication mode that is in place immediately following any SP3 and post-SP3 CU1 installs.
Puri,
Maybe try SP4? Not enough information there for me to help, really.
MSI (s) (50:58) [10:09:31:248]: Product: Microsoft SQL Server 2005 (64-bit) – Update 'Service Pack 3 for SQL Server Database Services 2005 (64-bit) ENU (KB955706)' could not be installed. Error code 1603. Additional information is available in the log file C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix\SQL9_Hotfix_KB955706_sqlrun_sql.msp.log.
MSI (s) (50:58) [10:09:31:248]: Windows Installer installed an update. Product Name: Microsoft SQL Server 2005 (64-bit). Product Version: 9.3.4035.00. Product Language: 1033. Update Name: Service Pack 3 for SQL Server Database Services 2005 (64-bit) ENU (KB955706). Installation success or error status: 1603.
MSI (s) (50:58) [10:09:31:248]: Note: 1: 1729
MSI (s) (50:58) [10:09:31:248]: Transforming table Error.
MSI (s) (50:58) [10:09:31:248]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:264]: Transforming table Error.
MSI (s) (50:58) [10:09:31:264]: Transforming table Error.
MSI (s) (50:58) [10:09:31:264]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:264]: Transforming table Error.
MSI (s) (50:58) [10:09:31:264]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:264]: Transforming table Error.
MSI (s) (50:58) [10:09:31:264]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:264]: Transforming table Error.
MSI (s) (50:58) [10:09:31:264]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:280]: Transforming table Error.
MSI (s) (50:58) [10:09:31:297]: Transforming table Error.
MSI (s) (50:58) [10:09:31:297]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:297]: Transforming table Error.
MSI (s) (50:58) [10:09:31:297]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:297]: Transforming table Error.
MSI (s) (50:58) [10:09:31:297]: Note: 1: 2262 2: Error 3: -2147287038
MSI (s) (50:58) [10:09:31:297]: Product: Microsoft SQL Server 2005 (64-bit) — Configuration failed.
MSI (s) (50:58) [10:09:31:297]: Windows Installer reconfigured the product. Product Name: Microsoft SQL Server 2005 (64-bit). Product Version: 9.3.4035.00. Product Language: 1033. Reconfiguration success or error status: 1603.
MSI (s) (50:58) [10:09:31:297]: Attempting to delete file C:\WINDOWS\Installer\847e2.msp
MSI (s) (50:58) [10:09:31:297]: Unable to delete the file. LastError = 32
MSI (s) (50:58) [10:09:31:313]: Cleaning up uninstalled install packages, if any exist
MSI (s) (50:58) [10:09:31:313]: Attempting to delete file C:\WINDOWS\Installer\847e2.msp
MSI (s) (50:58) [10:09:31:329]: MainEngineThread is returning 1603
MSI (s) (50:F0) [10:09:31:329]: No System Restore sequence number for this installation.
=== Logging stopped: 6/22/2011 10:09:31 ===
MSI (s) (50:F0) [10:09:31:329]: User policy value 'DisableRollback' is 0
MSI (s) (50:F0) [10:09:31:329]: Machine policy value 'DisableRollback' is 0
MSI (s) (50:F0) [10:09:31:329]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (50:F0) [10:09:31:329]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (50:F0) [10:09:31:345]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (50:F0) [10:09:31:345]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (50:F0) [10:09:31:345]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (50:F0) [10:09:31:345]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (50:F0) [10:09:31:345]: Restoring environment variables
MSI (c) (40:AC) [10:09:31:345]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (40:AC) [10:09:31:345]: MainEngineThread is returning 1603
=== Verbose logging stopped: 6/22/2011 10:09:31 ===
got above error when i was applying sp3 on sql 2005 clsuter.
We did a SP3 upgrade last week on our production farm. And we have the same issue. Although it's not consistent. not every clusternode made the same changes from mixed to single. Some nodes remain unchanged.
We are now using our Premier contract, and have openend a case. Suggestion of Microsoft is that a failover should resolve the problem.
To be continued…
Adam, yes, you may be right. I haven't done enough thorough investigation to determine the cause. I had a case open with Microsoft support last year and it was resolved as not reproducible. š
I can validate both of your experiences though the second issue is quite troubling to us. I have opened a connect but no responses from microsoft yet. http://web.archive.org/web/*/https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=480487
I have done some reading on cluster groups moving and sync'ing registry paths on the quorum drive sometimes using checkpoint files. To back this theory, during the patching process would the instances be brought into Windows only mode and then back out to mixed. I have seen them move into single mode. I figure that would create checkpoint files and upon reboot or failover, if the cluster used that point in time .CPT file, it would bring the instance online with reflective security model of Windows Only. …any thoughts?
Brian, I did not post on Connect, since my interaction with support led me to believe this was the first and only instance of it they had come across. So I assumed that I was an anomaly and perhaps the issue was influenced by something else.
Aaron,
I tried look for the Windows authentication only switch on Connect but didn't find it. Do you have an ID on it? A poster on SQL Server Central is reporting the same issue after applying KBKB960090.
Minh, you are the first person I have seen with this symptom.
My experience with sp3 is that it deleted all my user database triggers. I searched the internet but it seems that I'm the only one who is affected by sp3. Can someone back me up on this?
Thanks in advance
Yes, I have heard of a lot of people who freed up space by deleting old MSI files from the Windows installer folder. It should be much harder to delete those files, or SQL Server should be putting them in a more obscure place or giving them a more obvious "don't delete me" kind of name. Though, I am not sure why an SP3 install would need to use the SP2 MSI file for anything in the first place.
Just to clarify something about my previous comment, I could finally upgrade the Client Components in my server, all I had to do is to copy a file from SP2 install in the C:\windows\installer folder.
I saw an article that helped me a lot fixing that:
http://social.msdn.microsoft.com/Forums/en-US/sqlsetupandupgrade/thread/3a9324d4-e28a-40a0-b2db-f0d5855ec7b2
I have had issues installing SP3 too, I had to install Windows Installer 4.5 in some servers after trying several times to install it with no luck, after installing WI 4.5 it worked.
And in one of my servers I could never update the Client Components.
=(