I haven't blogged in a while, so I thought I would post another Russinovich-style "case of" post about a problem I ran into recently. I had a WSUS client machine that was failing to install two specific Office Outlook 2003 updates. This is a very specific solution to a very generic error, but I'm hoping it might help somebody out there.
The client computer is running Windows Vista Business (x86) and the Office version is 2003, SP3.
The generic error I was getting was 779. I clicked on the 'search for more information' link and all I got were the generic troubleshooting tips. A cursory search on the live search and the google revealed nothing other than "reinstall office" suggestions, which, in my opinion, is the lazy way out and should always be the absolute last resort.
I decided to do some digging. First, I fired up SysInternal's amazing Process Monitor (ProcMon) application. This is my favorite troubleshooting tool in my toolbelt. Next, I performed the update installation from Windows Update manually. (Unfortunately, I couldn't find the standalone installers -- which I prefer -- for these updates, but it didn't make much difference this time.)
I let the installation finish and fail. Same error code: 779.
I started at the bottom of the ProcMon results and searched in the upward direction for "access denied" messages, since those are the most frequent causes of update errors, in my experience.
The first one I found was for the file C:\Windows\system32\mapisvc.inf when MSIExec.exe was attempting to create (write over) the file. This is a bit odd as usually the culprit is the registry. I also opened up the WindowsUpdate.log file in c:\windows to attempt to confirm that this was what was causing both updates to fail.
I, again, started at the bottom and scanned up to see what error the update engine was reporting. I saw the following which confirmed my suspicion.
2008-05-30 14:09:15:833 2376 12a8 Handler C:\Windows\SoftwareDistribution\Download\ 79834ebef0aa43d1dd3408b229219bfb\img\OLKINTL.MSP
2008-05-30 14:09:15:833 2376 12a8 Handler MSP final command line: DISABLESRCPROMPT=1 LOCALCACHESRCRES=0 NOLOCALCACHEROLLBACK=1 REBOOT=REALLYSUPPRESS MSIRESTARTMANAGERCONTROL=Disable
2008-05-30 14:09:45:816 2376 12a8 Handler MSP Error List:
2008-05-30 14:09:45:816 2376 12a8 Handler 1: 1913 2: C:\Windows\system32\ 3: mapisvc.inf
2008-05-30 14:09:45:816 2376 12a8 Handler : MSI transaction completed. MSI: 0x80070643, Handler: 0x8024200b, Source: No, Reboot: 0
2008-05-30 14:09:45:816 2376 12a8 Handler : WARNING: First failure for update {6D6FD00B-5750-4C4B-B6B2-4D7D0C078F2E}, transaction error = 0x8024200b, MSI result = 0x80070643, MSI action = RemoveIniValues
2008-05-30 14:09:45:816 1056 11c0 AU >>## RESUMED ## AU: Installing update [UpdateId = {3BE47429-68D2-41D9-947B-6EB2D71B73FD}]
2008-05-30 14:09:45:832 1056 11c0 AU # WARNING: Install failed, error = 0x80070643 / 0x00000779
2008-05-30 14:09:45:832 2376 12a8 Handler : WARNING: Operation failed at update 0, Exit code = 0x8024200B
As you can see in the highlighted line above, the update engine was reporting that it was, indeed, having problems with that file. I wonder why?
I looked at the properties of the file and it made sense immediately. No account had write access on the file. Administrators and SYSTEM (which is the account that the update service runs under) only had read access. This is strange because it is inheriting permissions from SYSTEM32, which by default grants Full Control to administrators and SYSTEM. Since the inherited permissions do not match the actual permissions on the folder, that can only mean one thing: the file's ACL was corrupted. This is easy to fix.
First, take ownership of the file. Apply the changes. Next, uncheck inherit permissions. Apply the changes again. Now, check inherit permissions. Apply the changes one more time. Hooray! The SYSTEM account once again has full control on the file.
I ran Windows Update again and it completed successfully.
Mystery solved!