Over the last few weeks, I’ve been looking at using web proxy auto discovery (WPAD) to let a client’s PCs automatically discover the location of their Microsoft ISA Server 2000 web proxy servers through the Internet Explorer client. Note that WPAD is used by web proxy clients and firewall clients use winsock proxy auto detection (WSPAD).

Microsoft knowledge base article 296591 gives background information on WPAD (for WSPAD see Microsoft knowledge base article 260210) but basically, what is involved is:

• A properly configured web proxy client (i.e one which has automatically detect settings checked in the Internet Explorer LAN connection settings) queries the DHCP server for option 252, which identifies an HTTP address for a file called wpad.dat which is ISA Server’s dynamically generated proxy auto configuration (PAC) file.
• If a DHCP server does not respond with option 252, the web proxy client attempts to access http://wpad.domainsuffix:80/wpad.dat (or http://wpad.domainsuffix:80/wspad.dat for the firewall client). To locate this URL, the remote client queries its configured DNS servers for wpad.domainsuffix – obviously issues with incorrectly configured domain suffixes will prevent automatic discovery from working. Microsoft knowledge base article 307502 also indicates that the WPAD address is case sensitive.

It should be noted that WPAD is not supported for clients that connect to the LAN with any type of dial-up connection.

To set up WPAD, three steps are involved, as detailed in Microsoft knowledge base article 309814 (Windows 2000) and Microsoft knowledge base article 816320 (Windows Server 2003):

The web proxy servers must publish automatic discovery information (which might require the web proxy service to be restarted).

DHCP (and optionally, DNS) needs to be configured to send the WPAD URL to the web proxy client (as detailed in Microsoft knowledge base article 252898).

Finally, the clients need to be set to automatically detect settings.

We planned to roll out WPAD on a site-by-site basis, using DHCP (adding a DNS entry would affect all clients) and everything looked good using DHCP alone (no DNS installed) in my test environment; however the existing route used for production clients to access the Internet is direct via the firewall, and so the clients failed to use the DHCP-assigned WPAD information as the direct path was working (that’s the theory – it is difficult to diagnose the DHCP traffic to that level of certainty, other than using a network monitor and examining packets).

One possibility for the failure is described in Microsoft knowledge base article 312864 but I could not replicate this behaviour in testing and as it is only linked from the Windows Server 2003 version of the knowledge base article describing configuration of firewall and web proxy client auto discovery, I am not convinced that the article applies to clients using Windows 2000 DHCP servers.

The current plan is to use a group policy object, filtered by group membership, to manipulate client proxy settings and use http://proxyarray.domainname.suffix/wpad.dat as an automatic configuration script. This has the advantage that we can control who can access the Internet (take a user out of the group to remove their proxy access – once the direct path has been removed), but does not use WPAD at all.

One comment which my client made was that the wpad.dat file which ISA Server uses looks complex compared to the .PAC files used by the parent company’s web proxy servers. We could have used a simple .PAC file, but the major advantage of wpad.dat is that it is updated dynamically to reflect changes in the proxy server configuration.