Internet Explorer isn't auto-discovering http://wpad/wpad.dat auto-config

David,

In case you're still hitting up against this problem, it's actually rather simple to fix. But it's not documented ANYWHERE, and it took me ages to sort it out in my environment. Everything you've done is good, and it's what I'd call a bug in how IE gets it's WPAD info and connects to the web server.

First of all, you can't use a CNAME record for WPAD. Use an A record. Silly, I know, and it shouldn't make any difference, but it's definitely the case. So remove your CNAME in your DNS, and make an A record for the IP Address of the web server.

Secondly (and this may be more tricky for you), you need to have the WPAD.DAT file located on the root of the default website that's listening on the IP Address that you've assigned above. This is the key. It WILL NOT work with a host-header field or anything like that.

Explanation: What IE does is resolve the name WPAD to an IP Address. It's got to be able to resolve it directly to an IP Address. If it resolves as a CNAME query does to a different name, it won't work. So once IE's got the IP address that WPAD resolves to, what it actually does is connect to http://<>/WPAD.dat. If you've got a different website set up on the same webserver, listening on port 80 but using a host header field like I had (IE, "default web site", as well as "WPAD Website"), then you'll have everything set up correctly, but it won't work for that very reason. Put a copy of your WPAD.DAT file on the root of your default website, and things should start working.

Of course, if you can't get access to the root of that website (or you can't secure the root of that website), then you may need to look at moving your WPAD site to a different server where it can be at the root of the IP Address assigned to that server.

Give that a shot anyway. That's the process that worked for me. It took me ages to get it working, but it's been reliably working now for a long time. All the above though is simply my understanding of how IE works in relation to WPAD.DAT files, and might not be correct - it's simply based on the observation of what it does in my own environment. Yours may be different, but I'd put some money at least on that fixing your issue.

Let me know how you get on! Matto :)

Another method of resolving this for IE8 (may work for IE7 too) is to change a couple of settings in Group Policy.

• Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Make proxy settings per-machine (rather than per-user) = Enabled
• User Configuration > Administrative Templates > Windows Components > Internet Explorer > Disable caching of Auto-Proxy scripts = Enabled

With the above 2 settings modified, I was able to get WPAD settings to work in IE8.

NOTE: You dont need to be in a domain environment to use this. On a workgroup PC, simply use GPEDIT.MSC to change the local computer policy.

See: How to disable automatic proxy caching in Internet Explorer

Regards, Kym

This serverfault question appears high in google searches which is why I am replying to it. I hope others find this useful as this problem was a real pain for me.

Almost every Windows 7 computer on our domain of about 50 users was affected - going around and resetting IE was not acceptable as far as I was concerned so I eventually resolved it as follows:

Firstly here are a couple of useful but very hard to find links I came across:

http://blog.frankleonhardt.com/2011/wpad-and-windows-7-and-internet-explorer-8/

http://kb.k12usa.com/Knowledgebase/Proxy-Auto-Detect-WPAD-Issues-With-IE-Windows-7

http://infratalk.wordpress.com/2011/09/10/troubleshooting-windows-proxy-autodiscovery-wpad/

I would suggest you read each of the links first.

The following quote from the fist link is particularly interesting:

"It turns out that those smart guys at Microsoft have implemented a feature to stop checking for a WPAD server after a few failed attempts. It reckons it knows which network a roaming machine is on, leaves a note for itself in the registry if it’s not going to bother looking again. A fat lot of use if you’ve only just implemented it."

I found the wpad reg key noted in the links, which is actually how I found the links in google. I got ruthless during testing and found that the following works:

Close all IE sessions, Open Control Panel -> Internet Options -> Connections Tab -> Lan Settings and un-tick "Automatically Detect Settings" (and all other options) - DO NOT OPEN IE AGAIN.

Delete the following reg key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad

Open Control Panel -> Internet Options -> Connections Tab -> Lan Settings and TICK "Automatically Detect Settings".

If you refresh your regedit window (F5) you should see the wpad reg key re-created but it will be empty.

Now open IE. Refresh the wpad reg again and you should see it populate with a subkey containing various wpad info.

This was a fix without having to reset IE but I still needed to deploy it across 50 machines somehow. I did that as follows:

I created the following reg by using a computer I had reset as above (do not copy this verbatim as it was created based on our domain and I edited the domain name), the wpadOverride line was manaully added:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad]
"WpadLastNetwork"="{F03DC3BF-50F6-4DB1-9570-CF84875F6EDC}"
"WpadOverride"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\a4-0c-c3-62-7b-2d]
"WpadDecisionReason"=dword:00000000
"WpadDecisionTime"=hex:10,50,19,cf,b1,73,cc,01
"WpadDecision"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{F03DC3BF-50F6-4DB1-9570-CF84875F6EDC}]
"WpadDecisionReason"=dword:00000000
"WpadDecisionTime"=hex:10,50,19,cf,b1,73,cc,01
"WpadDecision"=dword:00000001
"WpadNetworkName"="example.local"

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{F03DC3BF-50F6-4DB1-9570-CF84875F6EDC}\a4-0c-c3-62-7b-2d]

This was added to user login scripts and basically deletes the reg key and replaces it.

I then created a GPO to disable "Automatically Detect Settings" and manually added the wpad url:

User Configuration -> Policies -> Windows Settings -> Internet Explorer Maintenance -> Connection -> Automatic Browser Configuration | Un-tick "Automatically Detect Configuration Settings" and Tick "Enable Automatic Configuration" and insert "http://wpad.example.local/wpad.dat" into "Automatic Configuration URL".

I also enabled the "IE WPAD Decision Caching Override" (see the second link above).

I then left this for a few days to deploy to as many computers as possible then disabled the "Automatic Configuration URL" and ticked "Automatically Detect Configuration Settings" again and removed the reg key from the login script.

I did this as it did not appear to work by simply unticking and then ticking the "Automatically Detect Configuration Settings" box via GPO so the addition of the URL may not be ultimately necessary.

I had hoped the WpadOverride would work without the extra steps but unfortunately it didn't in my case.

Incidentally using a cname works perfectly well on our network.

Any computers that were off for the duration of the fix were just handled manually after that.

I hope this helps other who come across this question like I did via google. This "feature" by Microsoft is just downright stupid.

I had the exact same issue but only for a few computers...

Wireshark showed that IE doesn't attempt anything on the network before hitting the target web server. The web server that is set to host wpad responds to any hostname on that particular IP address.

I got the non-working IE8 clients to download wpad.dat again by doing this:

1. Tools->Internet Options->Advanced->Reset
2. Closed IE and re-opened it

Unfortunately, after making modifications to the wpad.dat file it is apparent that IE8 after the first download of wpad.dat doesn't do any further downloads :-(

Another thing to look out for is detailed in the following URL: https://technet.microsoft.com/en-au/library/cc995158.aspx

DNS may have a block list enabled of which wpad is defined as a blocked record, this is a protective measure.

Try running wireshark on a client machine... see where IE is looking? Does your webserver log that it has served any wpads?

Internet Explorer will attempt to access "http://wpad.your-machine's-dns-suffix.com/wpad.dat". Make sure the web server that's configured to serve the wpad.dat file is answering for the fully-qualified hostname. (BTW, IE will decompose the DNS suffix trying each parent domain, too. Have a look at http://wpad.com. The guy that owns that domain could've been really, really evil if he'd wanted to...)

IE Version 6.0.2900.xxxx looks for the filename "wpad.da" instead of "wpad.dat" BE CAREFUL! ;) Just use a sniffer or check your webserver logs.

Hope this helps!

As Tom Newton suggest run wireshark to see what IE is doing (DNS query, HTTP GET, ...), also look at your webserver logs.
Take care that IE send the IP instead of the Host name (wpad) as 'Host' in the GET query so that you can't use a virtualhost 'wpad' on the webserver.

If you're using DHCP, then there is a setting (option 252, IIRC), for declaring the location of your wpad file. I believe you are incorrect about Firefox not being able to use this.

Additionally, do you have localdomain in the search list?