I had needed to make a change to a customer’s WPAD file to add a direct access location. I made my changes and tested it only to find out that it didn’t work. I decided that I would check and make sure the client could access the WPAD file, so I tested access to HTTP:// SERVERNAME/ WPAD.dat. I was able to see the changes I had saved in the file. However, the client still didn’t seem to be following the rules. I tried changing the Automatic Settings in Internet Explorer Proxy settings to use HTTP:// SERVERNAME/ WPAD.dat specifically as the proxy script to use. As long as I had the Automatic Settings unchecked and the path to the WPAD file defined in the script box, it worked. However, I needed to make sure it would work with Automatic Settings instead. [more]
What I found out was that a client gets it’s instructions about the location of the WPAD file to use through DHCP option 252. Upon checking the settings of this option, I found that it was using HTTP://WPAD/WPAD.dat instead of SERVERNAME. The DNS entry for WPAD was an alias that pointed to SERVERNAME. I went back to the web browser and went to HTTP://WPAD/WPAD.dat. I discovered that it did not have the changes that I had made even though HTTP://SERVERNAME/WPAD.dat was correct. On the WPAD server, I restarted IIS and checked it again. This time, both WPAD.dat files had my changes and the Automatic Settings began working successfully.
It appeared to me what happened was that IIS was serving a cached version of the WPAD.dat file when browsers tried to connect to the DNS alias while the actual server name was not cached.