AbeFroman
asked on
New WPAD file not being retrieved by clients
Our company is in the process of transitioning from an old to a new proxy server. Clients IE browsers are configured by the automatically detect settings feature via DHCP option 252. As we wish to trial the new proxy server first we have created an alternative WPAD file for this purpose.
Option 252 in DHCP was usually configured in this way - http://<server name>.<domain name>:80/wpad.dat. This has worked well for a number of years. We want to trial the new proxy at a number of sites so have configured DHCP option 252 for those sites as follows- http://<server name>.<domain name>:80/wpadnew.dat. We had found that this was working and clients at the trial sites were picking up the wpadnew.dat file without issue. In the last week or so some strange things have been happening.
1. With Option 252 for a particular scope set to the new WPAD file, clients still retrieve the http://<server name>.<domain name>:80/wpad.dat file.
2. At a site with more than one scope (with all scopes configured with option 252 for the new file) clients on some scopes retrieve the new file while clients on the others still retrieve the old file.
3. If I move a client from a scope where it should have retrieved the new file, but was still retrieving the old to a subnet where the clients were able to retrieve the new file, it will successfully retrieve the new file and when I move it back it still retrieves the new file.
To me it seems like perhaps some scopes aren't providing DHCP option 252 information to the clients so the clients are just working from the cached file and settings in the registry. Has anyone seen anything like this before?
Domain controllers are Windows Server 2008 R2 and clients are Windows 7. IE version is 9.
Option 252 in DHCP was usually configured in this way - http://<server name>.<domain name>:80/wpad.dat. This has worked well for a number of years. We want to trial the new proxy at a number of sites so have configured DHCP option 252 for those sites as follows- http://<server name>.<domain name>:80/wpadnew.dat. We had found that this was working and clients at the trial sites were picking up the wpadnew.dat file without issue. In the last week or so some strange things have been happening.
1. With Option 252 for a particular scope set to the new WPAD file, clients still retrieve the http://<server name>.<domain name>:80/wpad.dat file.
2. At a site with more than one scope (with all scopes configured with option 252 for the new file) clients on some scopes retrieve the new file while clients on the others still retrieve the old file.
3. If I move a client from a scope where it should have retrieved the new file, but was still retrieving the old to a subnet where the clients were able to retrieve the new file, it will successfully retrieve the new file and when I move it back it still retrieves the new file.
To me it seems like perhaps some scopes aren't providing DHCP option 252 information to the clients so the clients are just working from the cached file and settings in the registry. Has anyone seen anything like this before?
Domain controllers are Windows Server 2008 R2 and clients are Windows 7. IE version is 9.
I may be mistaken but I believe in order t ouse WPAD.dat you need to use this name as it and cannot change it... Again I could be totally wrong...
If you take a client and update the local host file to point to the new wpad location does it work if you rename the file on the new WPAD server to WPAD.dat?
The following articles may help you as well...
https://technet.microsoft.com/en-us/library/cc995261.aspx
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
If you take a client and update the local host file to point to the new wpad location does it work if you rename the file on the new WPAD server to WPAD.dat?
The following articles may help you as well...
https://technet.microsoft.com/en-us/library/cc995261.aspx
http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
ASKER
@gheist - Not sure what your comment means. As stated in the question we use DHCP option 252.
@compdigit44 - we've been using the two files, wpad.dat and wpadnew.dat for quite some time now without issue. Both sit in the root of the same web server and we just update DHCP option 252 for a particular scope with the new file name. To me it seems like some scopes aren't providing the option 252 information in the DHCP process so the clients are just using the cached information.
@compdigit44 - we've been using the two files, wpad.dat and wpadnew.dat for quite some time now without issue. Both sit in the root of the same web server and we just update DHCP option 252 for a particular scope with the new file name. To me it seems like some scopes aren't providing the option 252 information in the DHCP process so the clients are just using the cached information.
dhcp option can use any file name
WPAD.DAT is used by DNS-based PAC file discovery.
WPAD.DAT is used by DNS-based PAC file discovery.
ASKER
@gheist - ok I' still not sure how that helps, as mentioned our option 252 looks like this - http://<server name>.<domain name>:80/wpad.dat which has worked forever and still works. We don't use the DNS method. So trying to figure out why clients in some scopes keep using the above file and not http://<server name>,<domain name>:80/wpadnew.dat which we have changed to.
San you share realistic server names?
According to you it works in one sentence and does not in another.
According to you it works in one sentence and does not in another.
ASKER
@gheist - ok, so take this example, I have a domain controller running DHCP for a site named DC01. DC01 has two scopes. Scope 1 is 192.168.0.0/24. Scope 2 is 192.168.0.1/24. Server options for these scopes has option 252 configured. Previously this was configured as http://IIS01.companydomain.com:80/wpad.dat. This has worked well for a couple of years, now we need to transition this site over to a new proxy server and want to use a different file. So option 252 has been modified to http://IIS01.companydomain.com:80/wpadnew.dat. Clients in Scope 1 are using wpadnew.dat, but clients in Scope 2 keep using wpad.dat from http://IIS01.companydomain.com:80 even though server options configure option 252 for all scopes.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
@gheist - I admit I haven't waited double the lease time, I wasn't aware that I would have to as I assumed that DHCP information would be refreshed on a client reboot, but perhaps that isn't the case so I'll keep an eye on a client and verify settings after double the lease time.
Having said that I did take a client that was using the incorrect file, deleted the lease from DHCP and rebooted. I would think at this point a new DHCP process would take place. The client still used the incorrect, old file.
Having said that I did take a client that was using the incorrect file, deleted the lease from DHCP and rebooted. I would think at this point a new DHCP process would take place. The client still used the incorrect, old file.
Why dont you correct the old file or make it a dynamic page using ASP.NET?
do you still need the old wpad.dat? if not rename it to wpad.dat.old and rename the new one to wpad.dat Adjust DHCP server as necessary
ASKER
@David Johnson - yes, still need the old file as its a staged transition to a new proxy server.
ASKER
Update (2015-06-04) - This has started working at the sites and on the subnets not previously working. I believe gheist is onto something when he asked "Did you wait at least double of DHCP lease time?" I'm not sure if DHCP is supposed to hand out the Option 252 information with each lease renewal or at some other time, but it seemed like lease renewals weren't necessarily triggering the handover of information, but at some point later. I shall award gheist's comment as the solution, but it would be handy to know how DHCP actually works with regards to providing Option 252 information to clients.
WPAD is either picking it from dns or dhcp