When I started developing problems with a couple of SP1 Vista installs recently—application crashes, system instability, system software components shutting down—I started my troubleshooting by eliminating potential hardware-related causes. Once those were behind me, I encountered some issues with the accretion of application installs and uninstalls over time.
I have to believe this is a result of what Jeff Duntemann so rightly calls “Windows Gunk”. Thus, I decided to use my fresh copy of Windows Vista Ultimate with SP1 slipstreamed to perform an upgrade install on those two machines, in hope of curing my problems.
Cure them it did on one machine but that process also left a few other minor issues in its wake. I documented one of them in my previous blog Post SP1 Cleanup, Part 1 where I describe how to get rid of a WMI error that occurs in the wake of an SP1 install (or reinstall, as was the case for me). Here, Part 2 hinges on what happened when I tried to access Windows Update on my machine right after completing the upgrade install (but I read online this also happens after applying SP1 to build 6000 Vista as well)—namely an inability to access Windows Update. Each time I ran Windows Update, the process would conclude with an error code 0x80072EE2 and a notification that the PC was “unable to access Windows Update.”
As I started poking around in Technet to research this error code, I happened upon Knowledge Base (KB) article 836941 which would ultimately prove to contain the ingredients needed to repair these access issues. After plowing through some irrelevant resolution language, I found this entirely appropriate phase: “Home users or users who are not behind a proxy server,” which described my current networking situation completely. As recommended in the KB article, a little poking into the windowsupdate.log file in the %systemroot% directory confirmed this diagnosis (I’ve trimmed date and time stamps to compress the listing a little):
PT +++++++++++ PT: Synchronizing server updates +++++++++++
PT + ServiceId = {7971F918-A847-4430-9279-4A52D1EFE18D},
Server URL = https://www.update.microsoft.com/v6/ClientWebService/client.asmx
Misc WARNING: Send failed with hr = 80072ee2.
Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)>
Bypass List used : <(null)> Auth Schemes used : <>
PT + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
PT + Caller provided credentials = No
PT + Impersonate flags = 0
PT + Possible authorization schemes used =
PT WARNING: SyncUpdates failure, error = 0x80072EE2, soap client error = 5,
soap error code = 0, HTTP status code = 200
PT WARNING: PTError: 0x80072ee2
PT WARNING: SyncUpdates_WithRecovery failed.: 0x80072ee2
As it turns out, the solution to my problem was lurking in step 4 of the KB article, where it instructs users to add two URLs for the Windows Update pages to the Trusted Site addresses in Internet Explorer. To do that, in IE click Tools, Internet Options, then select the Security tab, click Trusted sites, then the Sites button, and finally, use the Add button to add http://update.microsoft.com and http://download.windowsupdate.microsoft.com to that list. It’s also a good idea to uncheck the “Require server verification (https:) . . .” checkbox beneath the Websites textbox as well. Apparently, even though Windows Update actually accesses the secure HTTP address https://www.update.microsoft.com, as shown in the preceding log file snippet, these emendations to IE security settings are necessary, because Windows Update started working immediately after I made those changes.
By adding Windows Update URLs to the Trusted sites list in IE,
you can also regain access to Windows Update services.
I’m still not precisely sure why this works, but immediately after making this change in IE, the next log entry shows a successful access to the very same secure HTTP server cited as unreachable in the preceding paragraph. But work it does, and so I’ll pass this fix along with my puzzled compliments.
— Ed —
