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?

Gigabytes.

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 Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Hotfix\SQL9_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:

Failed ACL:
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: sqlca\sqlsddlca.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 Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\ 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 ...

Recently, I unpacked somebody's installer.

I know, it might be borderline with the license, but I just wanted to take a peek.

It's a redistributable package which is distributed with a development environment so it can be incorporated into an installer bootstrapper. And it has been updated several times for individual download as an update or full install, yet without packaging information for said bootstrapper package.

If that doesn't call for some peeking and tweaking, I don't know what does.

When I unpacked and "darked" the installer, I was left with a bunch of files named with arbitrary numbers in arbitrary directories and an XML document that had the information about those names in various elements across it's hierarchy.

CMD.EXE's "FOR /F" is a blessing, but in it's heyday, nobody thought of renaming files based on information in XML documents.

Short of creating an XSLT, I gave Powershell a try.

But it doesn't do it in a one-liner, due to the pain in the neck that is XPath's handling of default XML Namespaces:

[xml]$wxs = get-content D:\Temp\ReportViewer\ReportViewer.wxs

$nsmgr = new-object System.Xml.XmlNamespaceManager($wxs.get_NameTable())

$nsmgr.AddNamespace("w","http://schemas.microsoft.com/wix/2003/01/wi")

$wxs.SelectNodes("//w:File",$nsmgr) | ForEach-Object -process {$f = get-childitem -path $_.Source;$f.MoveTo($f.DirectoryName + '\' + $_.LongName)}

The foreach-object is an ugly workaround. A colleague of mine (who I tortured with every step to get to these lines) brought up the idea of taking the object pipeline concept a little further by using

Add-Member -memberType NoteProperty -passThru

to join the two streams of information.

A lot of stuff to rename four files.

Completion of the latter approach left as homework for the interested reader.

Please note: script code fragment samples provided "AS IS", without support or warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the author or copyright holder be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.