So I’m having an exciting Friday night at home catching up on some support tickets, and I have one monitoring ticket for one of my managed SBS 2003 boxes where Microsoft update 961143 fails to install repeatedly.  Normally, whenever I have a patch that fails to install via Kaseya – simply logging in to the device & running Windows Update to install the problem patch resolves the issue.  Yeah – not so much with this one.  Installing the update via Windows Update, or by downloading the update & running it manually – it consistently fails.  Running the install manually, I just get a pop-up saying something vague to the effect that installation failed and click OK to undo changes.  I searched the web, and continually found thread after thread after thread of people having the same issue, but no solution.  Some suggested solutions included verifying the companyweb site was using the default app pool, some saying to check a registry key or two – but nothing worked.

The windowsupdate.log was vague – and the error code it provided (0x8007f070) didn’t help any with my web searches either.  I then dug down and found the individual update installation log (%temp%\QFE73170.log) and reviewed its contents:

2010/05/14 21:33:36    ————————————————————–
2010/05/14 21:33:36    begin installing the fix
2010/05/14 21:33:36    enable kerberos if necessary on companyweb
2010/05/14 21:33:36    the current start type of iis admin service is: 2
2010/05/14 21:33:36    find virtual server id of hostName: companyweb
2010/05/14 21:33:36    iterate through each IISWebServer under IIS://localhost/w3svc
2010/05/14 21:33:36    current server binding: IIS://localhost/w3svc/1, 192.168.16.2:80:
2010/05/14 21:33:36    current server binding: IIS://localhost/w3svc/1, 127.0.0.1:80:
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/2, :6345:
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/3, :8081:
2010/05/14 21:33:37    current server binding: IIS://localhost/w3svc/4, 192.168.16.2:80:companyweb
2010/05/14 21:33:37    found virtual server, server path is: IIS://localhost/w3svc/4/root
2010/05/14 21:33:37    get single property: IIS://localhost/w3svc/4/root,AppPoolID
2010/05/14 21:33:37    get single property successfully
2010/05/14 21:33:37    current virtual server is using app pool: DefaultAppPool
2010/05/14 21:33:37    get single property: IIS://localhost/w3svc/apppools/DefaultAppPool,AppPoolIdentityType
2010/05/14 21:33:37    get single property successfully
2010/05/14 21:33:37    identity of current virtual server’s app pool is: 0
2010/05/14 21:33:37    not using network service to run current virtual server

That last line in the log was the key:  For whatever reason, MSKB 961143 will bomb out if the DefaultAppPool is not using the NETWORK SERVICE identity.  I opened up IIS Admin, expanded <server> | Application Pools.   I right-clicked on DefaultAppPool and selected Properties.  I then went to the Identity tab on the app pool properties page, and sure enough – my DefaultAppPool was running under the LOCAL SYSTEM identity.  I changed the identity from LOCAL SYSTEM to NETWORK SERVICE, and clicked OK to save the changes.  Back in IIS Admin, I right-clicked on the DefaultAppPool again and selected Recycle to stop & restart the app pool.  After recycling the DefaultAppPool, I re-ran the KB 961143 installer and the update installed successfully.