Those dreaded Tuesdays. Patchday. Can’t avoid them forever.
Must. Install. Reboot. Hope.
Bang: Windows Server 2003 Service Pack 2
Bang: SQL Server 2005 Service Pack 2
Bang: Visual Studio 2005 Service Pack 1 (because SQL Server Business Intelligence Studio really is Visual Studio 2005 in disguise)
… and aren’t there tons of Critical Patch Updates for Unbreakable Oracle as well?
… and the Google Toolbar spreaders: Adobe Reader and Java Runtime?
And then the hoping. Although, you know it’s going to happen.
Puff, one of them updates fail. SQL Server. Not patched. Not starting. Unknown state. Windows Update Error Code: 0x7342 – that’s not helping.
Waiting for SP3 is tempting, considering the mess that is SP2. But, THEY need the databases. THEY have rights, too.
Maybe, there’s something in the Application EventLog. Indeed:
Product: Microsoft SQL Server 2005 – Update ‘Service Pack 2 for SQL Server Database Services 2005 ENU (KB921896)’ could not be installed. Error code 1603. Additional information is available in the log file C:Program FilesMicrosoft SQL Server90Setup BootstrapLOGHotfixSQL9_Hotfix_KB921896_sqlrun_sql.msp.log.
Error code 1603 – Windows Installer’s way of saying "Som’thn gone South.", more politely but not more informative "A fatal error occurred during installation."
But the log file is interesting:
SetSecurityFileDescriptor is failed at the error code 5; Converted SDDL: ‘(A;OICI;FA;;;S-1-5-21-600294000-123456789-9876543210-1234)’
Error Code: 0x80077342 (29506)
Windows Error Text: Source File Name: sqlcasqlsddlca.cpp
Compiler Timestamp: Wed Jun 14 16:27:11 2006
Function Name: ExceptionInSDDL
Source Line Number: 65
Yippie! It’s almost English! And the patch is setting ACL’s! Hope begins where trust ends. I can only try to imagine how that’s rolled back when an error occurs… And an error occurred (5 – Access denied):
Product: Microsoft SQL Server 2005 — Error 29506. SQL Server Setup failed to modify security permissions on file C:Program FilesMicrosoft SQL ServerMSSQL.1MSSQLData for user rumpelstiltskin. To proceed, verify that the account and domain running SQL Server Setup exist, that the account running SQL Server Setup has administrator privileges, and that exists on the destination drive.
The accounts exists (well, not that name). The domain exists. Not less than the universe. Rumpelstiltskin’s alter ego has administrative privileges and what ever that is, that exists on the destination drive, I might not know. But in fact, the ACL is already fine. So to say, exactly how it should look like if that ACL setting would have succeeded.
Try to guess what goes wrong here. Tip: It’s your fault. I promise.
Google or Live Search for "SQL Server Setup failed to modify security permissions on file", this will return Knowledge Base Article 916766, which (spoiler warning) tells you that you should check the files inside that directory for their permissions.
Remember that database you just copied in there? Oracle wouldn’t have let you do that, would it?
Grant rumpelstiltskin full access to each and every database and log files in that directory and the service pack will not fail with an error.
Not until the next time …