Windows Update fails for some workstations behind TMG when using WPAD

This post is about a recent scenario where TMG Administrator was receiving complains that some workstations that were using TMG as proxy were failing to run Windows Update. The interesting part of this issue was that only some workstations were having such problem and only if they were using “Automatic Detection” settings (which use WPAD). But all other workstations were using the same setting and were working just fine.

Data Gathering
In order to troubleshoot this I started TMG Data Packager in repro mode using Web Proxy and Web Publishing template and performed the following steps in the client workstation that was having the issue:

  1. Clear the wpad cache by executing the following command in an elevated command window: del \wpad*.dat /s
  2. Restart Windows Update service
  3. Wait for the error to happen on Windows Update.

Data Analysis
I started the data review by looking to the TMG Logging and notice that when it failed the following URL was sent it back to the client:**error=-2145107946**\&ln=en-us\&IsMu=true\&wgaerrorcode=0\&wgaend=

Notice that this URL returns the error -2145107946 (in decimal), which corresponds to 0x80244016 (in Hex), which means the following:

# Same as HTTP status 400 - the server could not process the
# request due to invalid syntax.

Having that info, it was time to review the netmon trace to understand why the request was invalid and after reading the trace, it was possible to understand why it was invalid.

By using Netmon it was possible to see the moment that client downloads the WPAD file and tries to access the TMG. But, in it can’t access for some reason (in this case it was a networking routing issue) and switches to another TMG. I wasn’t aware that this environment had another TMG, so I opened the WPAD file and found the following entry called BackupRoute:


This was a backup TMG that was supposed to be used only if the main one was down. So the problem here was:

  1. Both TMG servers were listening for CERN proxy requests on the default port 8080.
  2. They were also listening for WPAD requests on port 80.
  3. The CONNECT requests sent from the client to the was done on port 80 (wpad listener).This caused the failure (error 0x80244016) since the only valid request to this listener is GET /wpad.dat or GET /array.dll?GetRouting.Script.

In order to fix this it was necessary to change the entry on the Alternate Forefront TMG field within TMG console to be as shown below:


Once this change was done, the WPAD file changed to have the following entry on the backup route:


Have a happy Windows Update process behind TMG !!

Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront (ISA/TMG) Team