Everyone has experienced issues with Windows updates not being installed smoothly. There are so many possible causes I’m not going to give some kind of overview (someone who is able to do this must be really crazy). There is one particular scenario though I would like to share with you: the default automatic Windows update mechanism fails to even check which updates are available to download and even consulting the Windows Update or Microsoft Update site manually just fails: error 0x80072F8F is the result.
Normally updates should be installed in a controlled way, following some update policy. Most of the time this means updating happens in an automatic way, but preferably including a test phase before rolling out to production. For a certain reason some of my systems have to be updated manually though. I’m not going to explain you why, because it doesn’t matter here, but I can stress the fact that’s a temporary situation. On most systems this goes very smoothly: surfing to the MU site, checking for updates, downloading and installing them normally doesn’t imply problems. On two of my servers, both of them running ISA Server 2006, all this fails: error 0x80072F8F appears very early, I haven’t seen the available updates yet!
Luckily this error comes with 3 suggestions to solve the problem:
1) The system is out of sync. Your date/time is incorrect, so you should get it right. Double click the clock in the notification arear if it’s present there or open the Date and Time applet in Control Panel to configure the date and time.
2) The reregistration of 4 DLLs through regsvr32 could fix the problem: Softpub.dll, Wintrust.dll, Initpki.dll and Mssip32.dll.
3) Clear the setting “Check for server certificate revocation” in IE. I must say I do NOT advise you to do this, because then the revocation status of server certificates isn’t checked anymore. This is one of the big checks that should occur on certificates, so IMHO clearing this setting is not a good thing security wise. Of course you could try, just to see if this is a working workaround and/or just during updating (updates are needed too for security, so if you really don’t find a solution clearing the setting temporarily could be acceptable).
Three suggestions were made, none of them worked. What the hell was going on? And why did this happen on only 2 servers (not 1, not all of them)? Did ISA Server had something to do with this issue?
First thing to do was checking out the Internet: it was Bing time again! Most people claimed one of the three suggestions from Microsoft solved their problem, but some others seemed to find themselves in the same situation as I. For some of them configuring a proxy server was the solution (seems weird to me, but hey, I haven’t looked at their system, so I cannot judge). Others noted that disabling the firewall could make you able to use Windows Update again. Well, not for me, that is… “Luckily” there were still a few other people being left alone with their problem, giving me the impression the cause couldn’t be THAT special…
After more techniscal research, a lot of trial and error and further skimming all those forums, I finally got the evildoer! I was missing one trusted root CA certificate needed for WU/MU. The missing one wasthe GTE CyberTrust Global Root root certificate. After putting this one in the correct certificate store folder again, WU/MU worked again as well as before. Note that this certificate should be present in the Trusted Root Certification Authorities folder of the computer’s certificate store.
You could wonder why this root cert was missing. Well, it’s not impossible someone could delete it by mistake. But that wasn’t the case for me (remember 2 servers with ISA Server suffered from the update problem)… In the past I had to clean up this folder, so I removed all the certificates except for those I really need and those Windows really needs (check out Microsoft KB 293781 to obtain this list). The GTE CyberTrust Global Root certificate was NOT mentioned in the KB article, even if it’s needed for be able to check for updates via WU/MU. If you don’t update, yes, then you don’t need this certificate, so perhaps that’s why Microsoft hasn’t included it in the list…?
One last thing: the reason I had to clean up that particular folder had to do with client certificate authentication. If you connect to a published service that is secured with SSL, a server certificate and the client certificate authentication requirement, on the client side you choose your client certificate from a list (except when there are 0 or 1 valid certificates and your browser (if the published service is a web site/service) is configured to not show the dialog box for making a selection). This list consists of only those client certificates whose path originates at a root CA trusted by the server side. So if you have a client certificate with a certification path originating at a root CA and the certificate for this root CA is present in the Trusted Root Certification Authorities on the server(s), then the client certificate will appear in the list of possible client cert candidates in the client application. This means the client has to know which root CAs are trusted by the server. That’s why the server initially sends a lit of its trusted root CAs to the client. This list has a maximum size and yes, I see you get it: too many root CA certs in the Trusted Root Certification Authorities folder could mean some root CAs are not seen by the client as trusted by the server. Result: some client certificates don’t appear in a client’s browser when surfing to that highly secure published web site Clean up the folder (but leave everything available in the Third-Party Root Certification Authorities folder) and everything works fine again! Well, this story is still all true, but because of one certificate not being mentioned in the KB article, another problem has arised. But hey, it’s solved now: wo do know now that GTE CyberTrust Global Root should be present in the Trusted Root Certification Authorities folder of the computer’s (!) cert store.
Let’s update again!!
Link: http://support.microsoft.com/kb/293781/
