I got tasked with a problem today which was plain weird…

New servers being deployed, are unable to contact the WSUS distribution point to check for updates.

The file C:\Windows\WindowsUpdate.log show the following errors:

2010-11-23 11:03:45:106 800 634 Misc WARNING: SendRequest failed with hr = 80072ee2. Proxy List used:
Bypass List used : <(null)> Auth Schemes used : <>
2010-11-23 11:03:45:106 800 634 PT + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
2010-11-23 11:03:45:106 800 634 PT + Caller provided proxy = No
2010-11-23 11:03:45:106 800 634 PT + Proxy list used = theproxyip:80
2010-11-23 11:03:45:106 800 634 PT + Bypass list used =

Microsoft’s error code list (here – http://support.microsoft.com/kb/836941), show thats 0x80072EE2 is a connection timeout error.

The “working solution” for the time being by the SCCM guy was to run:
netsh winhttp set proxy theproxyip:80 *.thisdomain.local

The problem here is the  fact that it’s using a proxy in the first place, more importantly, with no bypass list being used. (We want it to detect the proxy, but bypass it).

We use a WPAD implementation, which uses a DNS CNAME entry to redirect wpad.thisdomain.local to the TMG proxy server array, in addition to DHCP option 252 for client PCs. The WPAD file’s purpose is to tell IE and WPAD aware services, what the proxy server address is, and what sites should bypass the proxy (i.e. it essentially populates Internet Options -> Connections -> LAN Settings).

Initially checking the WPAD file, failed to show the address *.thisdomain.local/* in the bypass list, meaning it wouldn’t bypass the proxy to begin with. First step was to fix this.

In the TMG console, *.thisdomain.local/* was added to the bypass list by going to Networking, and editing the properties for the Internal network. On the Web Browser tab, you add this entry into the listbox at the lower half of the screen. After applying these settings, checking the WPAD file again shows this address in the bypass list.

This failed to fix the issue however…

After searching high and low, not being able to work out what the heck was going on, I finally landed on a post advising that the WSUS Distribution Point URL absolutely, HAS to be lowercase. Bingo!

The WindowsUpdate.log file showed the distribution point as https://WSUS.THISDOMAIN.LOCAL:8531 – this was confirmed by running a GP Result report, which showed the WSUS setting being configured in the Local Group Policy.

I jumped into the machine, and ran “gpedit.msc”, where I reconfigured this setting as lowercase. I then restarted the Windows Update service, ran “wuauclt /detectnow”, then checked the log file again. Fixed!

From my coding knowledge, I can see that the WPAD file “attempts” to convert URLs to lowercase. I suspect this works perfectly fine, and that Windows Update purely mangles this, taking the bypass list and proxy settings from the WPAD file and just ignoring all the functions that make it work properly…

• *.thisdomain.local/* needs to be in the TMG bypass list!
• The WSUS distribution point must be entered in lower case!
• The WPAD file needs to also be published properly, although this was already good.

It’s quite possible also, that Windows Update service is possibly even smart enough to realise that it doesn’t need the proxy, when it’s configured properly in lowercase… But I’m not convinced yet…