SMTP error from remote mail server after end of data: 550 Action not taken

Have you set up a new mail server, configured DKIM and SPF correctly, but for some reason you still have email being intermittently rejected when forwarding to Gmail and other services with messages that are unhelpful like: –

SMTP error from remote mail server after end of data: 550 Action not taken

If that’s the case, you may need to set up a DNS PTR record for your mail server’s IP address. It appears that, depending on the circumstances of the forwarded email and the domain performing the forwarding, this step is crucial to ensure smooth email forwarding delivery.

Of course, you should ensure that the PTR record IP address and hostname match what you see in the SMTP header.

Update 31st Oct 2018:

Since writing this article a few days ago, I encountered some further issues with reliable mail delivery, specifically through Exim on cPanel.

Normally, when configuring forwarding, you should also enable SRS (Sending Rewriting Scheme), which adds additional information to the mail headers to inform the receiving MTA that the email has been forwarded and “signed” by the forwarding MTA (in my case, Exim on a cPanel/centOS installation).

While this was enabled in the Exim config, I did not realise that it wasn’t actually operating correctly.

Below is what you SHOULD see when SRS is operating correctly (forwarding to a Gmail account): –

Received-SPF: pass ( domain of designates <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
dkim=pass header.s=default header.b=HnochmZG;
dkim=pass header.s=default header.b=C8B9JAt8;
spf=pass ( domain of designates <your MTA IP> as permitted sender) smtp.mailfrom=””;

Here’s what it looks like WITHOUT SRS (again, forwarding to a Gmail account): –

Received-SPF: fail ( domain of does not designate <your MTA IP> as permitted sender) client-ip=<your MTA IP>;
spf=fail ( domain of does not designate <your MTA IP> as permitted sender);
dmarc=fail (p=NONE sp=NONE dis=NONE)

As you can see, in the SRS example, the sender information is modified to include information about the forwarding domain (i.e. your domain) so that it is clear that your MTA is not trying to forge or spoof the original sender’s domain.

In my case, SRS was turned on properly, however it seems that the cPanel archiving functionality was somehow breaking this on the version of cPanel that I was running. As a workaround, I will be disabling email archiving to ensure that SRS is applied to my forwarded messages and applying any cPanel updates as they are released that will hopefully resolve the issue.

Final Update 3rd November 2018:

Further to my last update, it seems that I had another factor contributing to this issue – Namecheap (my previous provider) had been intercepting my SMTP traffic through the use of a transparent SMTP proxy of some description (they were not forthcoming with information).

It seems that this was also causing mail delivery issues that were causing the likes of Gmail and Microsoft to return 550 back to my server after transmitting messages.

After unsuccessfully attempting to persuade Namecheap to allow me to bypass this technology, I have moved to a new VPS provider and my emails are again being delivered perfectly.

Wireless access point not connecting to NPS server

As part of my migration from my Server 2008 R2 environment, I ended up taking my NPS server offline. The trouble is, my wireless clients were unable to connect after it was brought back online.

Nothing had changed on the operating system, or the wireless access point. The only change is that the NPS server was migrated on to a Server 2012 Hyper-V environment.

I have not looked in to the root cause, but I suspect that it is to do with either the new Network Virtualization capabilities of Hyper-V 2012, or with the new virtual network card that it installs by default… Or both.

In any case, the clients would just continue to try and connect, and then fail. Normally, the Security event logs will give you a bit more information here, but in this case there was absolutely nothing logged. This originally led me to believe that the issue was with the wireless access point configuration, because the request did not even appear to be reaching the NPS server at all.

Checking the RADIUS accounting logs disproved this, as I could see that the connection attempts were indeed being logged. This means that NPS was receiving the connection, but for some reason wasn’t even trying to match it to a connection or network policy (as nothing was being logged in the Security event log).

Some example entries in the log were: –

<Timestamp data_type=”4″>12/09/2012 20:36:23.148</Timestamp>
<Computer-Name data_type=”1″>SVR01NPS</Computer-Name>
<Event-Source data_type=”1″>IAS</Event-Source>
<Class data_type=”1″>311 1 12/09/2012 10:28:56 9</Class>
<Session-Timeout data_type=”0″>30</Session-Timeout>
<Fully-Qualifed-User-Name data_type=”1″> Mirabito</Fully-Qualifed-User-Name>
<Quarantine-Update-Non-Compliant data_type=”0″>1</Quarantine-Update-Non-Compliant>
<Client-IP-Address data_type=”3″></Client-IP-Address>
<Client-Vendor data_type=”0″>0</Client-Vendor>
<Client-Friendly-Name data_type=”1″>SVR01AP</Client-Friendly-Name>
<Proxy-Policy-Name data_type=”1″>Wireless Access Policy</Proxy-Policy-Name>
<Provider-Type data_type=”0″>1</Provider-Type>
<SAM-Account-Name data_type=”1″>MYDOMAIN\mat</SAM-Account-Name>
<NP-Policy-Name data_type=”1″>Wireless Access Policy</NP-Policy-Name>
<Authentication-Type data_type=”0″>5</Authentication-Type>
<Packet-Type data_type=”0″>11</Packet-Type>
<Reason-Code data_type=”0″>0</Reason-Code>

<Timestamp data_type=”4″>12/09/2012 20:36:23.164</Timestamp>
<Computer-Name data_type=”1″>SVR01NPS</Computer-Name>
<Event-Source data_type=”1″>IAS</Event-Source>
<NAS-IP-Address data_type=”3″></NAS-IP-Address>
<NAS-Port data_type=”0″>0</NAS-Port>
<Called-Station-Id data_type=”1″>64-70-02-7F-99-64:MYSSID</Called-Station-Id>
<Calling-Station-Id data_type=”1″>24-77-03-94-F3-90</Calling-Station-Id>
<Framed-MTU data_type=”0″>1400</Framed-MTU>
<NAS-Port-Type data_type=”0″>19</NAS-Port-Type>
<Connect-Info data_type=”1″>CONNECT 0Mbps 802.11</Connect-Info>
<Client-IP-Address data_type=”3″></Client-IP-Address>
<Client-Vendor data_type=”0″>0</Client-Vendor>
<Client-Friendly-Name data_type=”1″>SVR01AP</Client-Friendly-Name>
<User-Name data_type=”1″>mat</User-Name>
<Proxy-Policy-Name data_type=”1″>Wireless Access Policy</Proxy-Policy-Name>
<Provider-Type data_type=”0″>1</Provider-Type>
<SAM-Account-Name data_type=”1″>MYDOMAIN\mat</SAM-Account-Name>
<Class data_type=”1″>311 1 12/09/2012 10:28:56 10</Class>
<Authentication-Type data_type=”0″>5</Authentication-Type>
<NP-Policy-Name data_type=”1″>Wireless Access Policy</NP-Policy-Name>
<Fully-Qualifed-User-Name data_type=”1″> Mirabito</Fully-Qualifed-User-Name>
<Quarantine-Update-Non-Compliant data_type=”0″>1</Quarantine-Update-Non-Compliant>
<Packet-Type data_type=”0″>1</Packet-Type>
<Reason-Code data_type=”0″>0</Reason-Code>

It was the second event that got my on the right track, particularly this line: –

<Framed-MTU data_type=”0″>1400</Framed-MTU>

In some cases, such as when network devices are either not correctly, or unable to fragment the RADIUS requests, NPS is unable to process the request.

In these cases, you can resolve the issue by modifying the Framed-MTU value in the network policy in question, to 1344. The following steps are taken directly from this TechNet article: –

  1. Click Start, click Administrative Tools, and then click Network Policy Server. The NPS console opens.
  2. Double-click Policies, click Network Policies, and then in the details pane double-click the policy that you want to configure.
  3. In the policy Properties dialog box, click the Settings tab.
  4. In Settings, in RADIUS Attributes, click Standard. In the details pane, click Add. The Add Standard RADIUS Attribute dialog box opens.
  5. In Attributes, scroll down to and click Framed-MTU, and then click Add. The Attribute Information dialog box opens.
  6. In Attribute Value, type a value equal to or less than 1344. Click OK, click Close, and then click OK.

After making this change, my wireless clients were immediately able to connect to my secure wireless network as they had before the NPS server moved on to Hyper-V 2012… Now to investigate the root cause further!

Repairing the DHCP Client service after a Conficker worm infection

If you’ve recently removed a Conficker infection from one of your machines, you might find that you can no longer start the DHCP Client service on the machine in question.

This is still a problem, even if the machine doesn’t rely on DHCP for it’s IP addressing, because the DHCP Client service still plays an important role in machines configured with static IP’s, in that it is responsible for dynamic registration and updating of it’s DNS record on it’s configured DNS servers. Without the service starting, the records will eventually get scavenged (if the DNS servers are configured for scavenging) because the records haven’t been “touched” by the DHCP Client service on the machine in question.

In fact, that might be how you determine that a problem exists, because you can no longer resolve machines in DNS that previously had a Conficker infection.

The service fails to start, because Conficker makes changes to services which call the svchost.exe process so that it can attach itself and attempt to spread throughout a network. During this process, permissions are reset on the registry keys which contain the service information for the DHCP Client service. Without looking too deep in to why these permissions are changed, I suspect that Conficker entirely removes and recreates the DHCP Client service registry keys, which will of course inherit the parent permissions by default. The DHCP Client service requires the following non-inherited permissions in order to be controlled:

HKLM\SYSTEM\CurrentControlSet\Services\Dhcp – NETWORK SERVICE, Read
HKLM\SYSTEM\CurrentControlSet\Services\Dhcp – NETWORK SERVICE, Full control

Setting these permissions will allow the service to be controller again. I recommend checking the Windows Event Logs to ensure that DNS registration occurs successfully once the service has been started.

Unrealistically Fast (or Negative) Ping Responses in Server 2003 Hyper-V Guests

I came across an interesting problem the other day while I was doing some unrelated troubleshooting on one of my Hyper-V guests.

The symptoms were that my Windows Server 2003 machine would return very strange results when pinging hosts, both internally and externally, such as returning all four responses within about half a second, yet measuring them at over 3000ms (which means they should have timed out, rather than given me a reading in milliseconds) as well as occasionally providing negative values for response times.

Obviously the results were completely inaccurate, but I couldn’t work out why the issue was only happening on a handful (not all) Hyper-V guests running Windows Server 2003 and none on Server 2008.

Turns out that this is an issue if all of the following are true:

  • You are running an operating system prior to Windows Vista or Windows Server 2008
  • You are running the current implementation of Microsoft Hyper-V (i.e. at the time of writing)
  • You have presented multiple processors to the Hyper-V guest

The issue occurs because the multiprocessor HAL in Hyper-V causes the guest’s operating system Time Stamp Counter (TSC) to skew. According to this blog the problem wouldn’t ordinarily occur if you were running Windows Server 2003 with SP2 unless the BIOS check fails to determine if the TSC should be used. More specifically, if I understand correctly the issue occurs because the processors (or cores, if we’re talking about a single multicore processor) are not in sync with each other, which produces sporadic out-of-time results where time sensitive operations (such as ping responses) are in use.

The resolution is to force the guest to use the PM timer instead of the TSC, by adding /USEPMTIMER in the boot.ini file and then restart. You can easily test this by running a ping -t to a host and checking for drastically abnormal results.

Securing Wireless Networks with Windows Server 2008 and NPS

In this post I’m going to go through the process of securing your wireless network using Windows Server 2008 and the NPS (Network Policy Services) role from start to finish.

Previously, I was using Windows Server 2003 with IAS (Internet Authentication Services) to secure my wireless network, until I recently upgraded all of my servers to Windows Server 2008 – By the way, NPS is the new version and name for IAS.

Here is the TechNet guide which I followed – – I will be applying these guidelines to the following environment…

  • A Windows Server 2008 machine running AD DS (Active Directory Domain Services)
  • A Windows Server 2008 machine running NPS (Network Protection Services) and AD CS (Active Directory Certificate Services)
  • A Linksys WAP54G (an entry level wireless access point – you can use any wireless access point that supports RADIUS)

You can run NPS, AD DS and AD CS on the same machine if you want to, but I wouldn’t recommend it (personally, I prefer to keep my domain controllers running only AD DS).

I’m not going to go through the process of installing AD DS as it’s a little out of scope for this post, so we’ll start from having an established domain, and a clean install of Windows Server 2008 on which we will install AD CS and NPS.

The first step is installing AD CS and NPS on your clean Windows Server 2008 install…

  1. First, you’ll need to join the server to your existing domain and then restart;
  2. After the server restarts, open Server Manager;
  3. Click on the Roles node;
  4. Click on the Add Roles;
  5. On the Server Roles screen, select Active Directory Certificate Services and Network Policy and Access Services;
  6. Follow the wizard, selecting Network Policy Server when configuring the Network Policy and Access Services role and leaving the default Certification Authority role service selected for AD CS;
  7. Select Enterprise for the setup type for AD CS;
  8. Choose Root CA for the CA Type (remember we’re assuming that this is the first Certification Authority in your environment, so if it’s not you either don’t need to install this role, or if you choose you can configure this server as a Subordinate CA instead);
  9. Run through the rest of the wizard, making any changes you may wish to, otherwise just leave the defaults as they are appropriate (I changed the CA Common Name to the name of the server, as I think it’s cleaner) – Note that there is a warning at the end of the wizard, stating that the name of this server cannot be changed after installing the AD CS role.

Now that you have a Root CA and an NPS server on your domain, we can start configuring it…

  1. Open an MMC console, and go to File -> Add/Remove Snap-in…
  2. Add the Certificates snap-in, selecting Computer account for the local computer;
  3. Expand Certificates (Local Computers) -> Personal, right click on Certificates and choose Request new certificate;
  4. Follow the wizard, choosing Computer for the certificate type and then click the Enroll button, then close MMC;
  5. Open the Network Policy Server administrative console from Administrative Tools;
  6. Right click on the parent node, NPS (Local) and click Register server in Active Directory – Click OK on the two informational popups;
  7. With the NPS (Local) node still selected, choose RADIUS server for 802.1X Wireless or Wired Connections and then click on the Configure 802.1X button;
  8. Under Type of 802.1X connections, select Secure Wireless Connections and provide an appropriate name for the policies which will be created as part of this wizard;
  9. In the next step, you’ll need to configure a RADIUS client (by the way, RADIUS stands for Remote Authentication Dial In User Service), so click on the Add button;
  10. The RADIUS client will be your wireless access point, so for the friendly name type in something to identify the access point (for example, AP01), then provide the IP address or DNS entry for the access point;
  11. Click on the Generate radio button, and then click on the Generate button to generate a shared secret – Copy the shared secret to a notepad document, and click OK – Note that on my particular access point, a character limit of 22 characters exists for shared secrets so I had to cut the string down to the acceptable limit, so I would suggest checking for this limitation on your own hardware;
  12. Click Next, and then choose Microsoft: Protected EAP (PEAP) and then click on the Configure button (if you get an error message, you probably didn’t follow steps 1 -> 4 correctly);
  13. Ensure that the Certificate issued drop down box has the certificate you enrolled in step 4;
  14. Click Next, and then click on the Add button to use an Active Directory group to secure your wireless (you should add both the machine accounts and user accounts to this group to allow the machine to authenticate on the wireless before the user logs in);
  15. On the next step of the wizard, you can configure VLAN information, otherwise just accept defaults to complete;
  16. Restart the Network Policy Server service.

If you expand the Policies node now, you’ll see that the wizard has created a Connection Request Policy and a Network Policy containing the appropriate settings to authenticate your wireless connection – These individual policies can obviously be created manually, but the wizard is an easier method.

You can also remove the less secure authentication method options, and increase the encryption methods in the network policy if you wish (I have configured mine this way)…

  1. Under the Network Policies node, bring up the properties of the newly created policy;
  2. On the Constraints tab, uncheck all of the checkboxes under Less secure authentication methods;
  3. On the Settings tab, click on Encryption and uncheck all boxes except Strongest encryption (MPPE 128-bit);
  4. Save the policy and then restart the Network Policy Server service.

With the NPS server configured to accept requests from your wireless access point, you’ll now need to configure the access point to communicate with the NPS servers – These instructions are for my Linksys WAP54G, but will be similar to most access points which support RADIUS…

  1. In the web interface for the access point, click on the Wireless tab and assign an appropriate SSID;
  2. Click on the Security sub-tab, and set the Security Mode to WPA-Enterprise (if your access point supports WPA2-Enterprise, use this instead);
  3. Set the Encryption to AES, and then provide the NPS server IP as the RADIUS Server and the Shared Secret that you saved in step 11 above;
  4. Save your settings and restart the access point.

Now your access point should be configured to talk to your NPS server, so all that is left is to configure your clients to connect – The recommended way of doing this, would be to use Group Policy, but the instructions below are for configuring a Windows Vista client – You can easily replicate these actions in a Group Policy under the Security node.

To configure a Windows Vista client which is joined to the domain…

  1. Open up the Network and Sharing Center;
  2. Click on Connect to a network;
  3. Locate the network you have just secured (it should say Security-enabled network next to it) and click the Connect button;
  4. It will take a short while to set up the profile and then connect successfully.

You can also configure a few extra settings to speed up the time it takes to connect (it won’t improve the overall speed, only the time it takes to initially connect to the wireless network)…

  1. In the Network and Sharing Center, click on Manage wireless networks and then double click the network you set up above;
  2. Click the Security tab, and then the Settings button below;
  3. The Validate server certificate checkbox should already be selected by default, but you should also select the CA that you set up earlier under the Trusted Root Certification Authorities to speed up the certificate verification process;
  4. You can also check the box Do not prompt user to authorize new servers or trusted certification authorities in order to improve the user’s experience.

Some suggestions recommendations…

  • Use a security group with the appropriate machine and user accounts as members to secure your network;
  • Group Policy is by far the best way to deploy the client side settings, but will obviously require an established domain connection in order to push these settings down to the clients;
  • While disabling the SSID of your access point sounds like an increased security measure, it can be a security risk if you are configuring your workstations to actively look for the SSID name – Potential session hijackers could intercept this traffic and set up an SSID for the requested name, unknowingly to the user which would then connect to a potentially malicious network;
  • You can vary the encryption type from AES to TKIP if your devices don’t all support AES, although AES is the preferred encryption algorithm;
  • If you’re having trouble with your connection, there are a few places you can look to troubleshoot, namely – Local client event logs, the NPS log file which lives in C:WindowsSystem32logfiles and most importantly the Security event logs of the NPS server which contains detailed information about access successes and failures.

(Nearly) All You Need to Know About Proxy Autoconfiguration, WPAD and PAC files

The principle behind the automatic configuration of proxy settings is obvious – To enable users to automatically obtain their proxy settings, without the requirement of having the manually configure their browser (or internet application) settings. There are other benefits, such as the ability to quickly update proxy information, as well as the ability to specify fail-over proxies, in the event that a primary proxy is not available, and I’ll go through those as well, but first…

PAC stands for Proxy Automic Configuration, and PAC files are the files that WPAD uses to pull down the proxy information. PAC files can be published via the WPAD protocol, or alternatively they can be manually configured in the browser by providing a path or URL to their location.

WPAD stands for Web Proxy Automatic Discovery, and is a method published by either DHCP, DNS or both in order to enable browsers to automatically detect the proxy settings required for the network that they are on.

PAC Files

I’ll begin with talking about PAC files, as that is where the proxy information is actually stored, and everything else is just the distribution method of your PAC files.

PAC files are written in the Javascript language. They primarily contain the following information…

  • The proxy server(s) to use
  • The port of the proxy server(s)
  • A list of sites or hosts that the proxy bypasses (the requests go directly out to the internet, without bypassing the proxy)

An example of a pretty basic PAC file, is this (don’t worry, I’ll break it down further)…

function FindProxyForURL(url, host)


if (isPlainHostName(host)) { return “DIRECT”; }

if (isInNet(host, “”, “”)) { return “DIRECT”; }

if (shExpMatch(host, “”)) { return “DIRECT”; }

if (shExpMatch(url, “*”)) { return “DIRECT”; }

return “PROXY proxy1:8080; PROXY proxy2:8080; DIRECT”;


This is a standard PAC file, that retrieves the URL or host that the user’s browser has accessed, and compares it to a list of exceptions to determine whether it will allow direct access to the internet, or whether it will pass the connection through a proxy server.

If the URL or host doesn’t match anything in the exclusion list, it will then pass the connection through the first proxy.

If the first proxy (proxy1) doesn’t respond on port 8080, it will try to pass the connection through the second proxy (proxy2) on port 8080, and if that also fails, it will then allow the connection to pass out through the internet directly, as it’s least preferred option. You do not need to allow the connection to pass through to the internet directly if the proxy servers don’t respond – In fact, if you do not specifically include it as a fallback option, the connection will instead time out and the user will not be able to establish their connection until a proxy server responds.

In case you’re having difficulty identifying what does what in my PAC file example, I’ll break it down a bit further…

function FindProxyForURL(url, host)

This line obtains the URL and host information from the browser, so that it has information to compare against it’s exception list – For example, if the user was trying to access Google, then would be the URL and would be the host.

if (isPlainHostName(host)) { return “DIRECT”; }

This essentially checks if this is a “single label” host, which means there are no full stops (periods). If a single label host can be resolved, it’s pretty much going to be internal (such as http://intranet for the URL or just intranet for the host. If the host fits these conditions, then the connection is not passed through the proxy – This is what the return “DIRECT” part of the line means.

if (isInNet(host, “”, “”)) { return “DIRECT”; }

This checks if the IP address of the host is on the internal network (assuming – is your internal network) and therefore also bypasses the proxy for this connection.

if shExpMatch(host, “”)) { return “DIRECT”; }

This is a direct string comparison, and grabs the host variable specified earlier, and compares it against – If it matches, then the connection bypasses the proxy.

if shExpMatch(url, “*”)) [ return “DIRECT”; }

This is another direct string comparison, but ends in a wildcard (*) which means that if the URL begins with then it bypasses the proxy.

return “PROXY proxy1:8080; PROXY proxy2:8080; DIRECT”;

This is where your preferred proxy servers are listed. The connection will try proxy1 on port 8080 first, proxy2 on port 8080 second, and then go out directly to the internet if the first two proxies gave no response.

PAC files can be called anything you want to call them, except if you are using the DNS WPAD implementation, in which case it MUST be called wpad.dat in lower case.

Publishing Your PAC File

There are essentially two ways to publish your PAC file – On a file system (network share, or local machine) or via HTTP (on a web server).

The file system method is pretty simple. Just copy the PAC file to the desired location. This could be the user’s local machine, or a file server.

If you are using the user’s local machine, then I would assume this would either be a temporary measure, or that you are deploying PAC files to each of the machines for a specific requirement. The more common file system method, would be to copy the PAC file up to a file server, and reference it via a network share.

In either of the file system based scenarios, you need to reference the PAC file by appending file://// to the beginning of the location, so a file stored in the user’s C: would become file:////C:/proxy.pac – Notice the use of forward slashes, rather than backslashes in the path. This isn’t specifically required, but makes sense.

The same is true for the PAC file hosted on a file server, in that the reference would be file:////SERVER/SHARE/proxy.pac

I have seen some cases where an extra fifth slash is required after file: particular in Firefox. You’ll need to find the right balance here, depending on what your application prefers.

If you’re using the HTTP method, you need a MIME type of application/x-ns-proxy-autoconfig for the file extension, which should either be .dat or .pac and then reference the file using the full URL, for example http://server/proxy.pac

Manually Configuring PAC Files In Your Browser

This method assumes a few things about your environment…

  • Your only have a few machines to manage, and manually configuring each one is no big deal; or
  • You have a method of managing the browser configuration, such as Group Policy AND your are confident there are no internet capable application outside of your management (or they don’t matter) AND your environment does not cater for external users roaming on your network (or it’s no big deal to configure these machines as they come on to your environment, and to de-configure them before they leave)

If you aren’t happy with these conditions, then the WPAD method (in the Deploying Automatic Configuration Using WPAD section) might be the way to go for you.

For the purpose of this article, I’m only going to go through Internet Explorer 7 (which is the same for Internet Explorer 6) and Firefox. Any other compatible applications will have a very similar configuration method.

Let’s start with Internet Explorer. Fire up IE, click on Tools -> Internet Options, go to the Connections tab and click on the LAN Settings button.

You should clear any previous proxy configuration from here, and then tick Use automatic configuration script and provide the path or URL to your PAC file in here (see the section above Publishing Your PAC File if you haven’t already). You should also ensure no other tick boxes are checked, such as the Automatically detect settings box, as this will slow things down (it will be looking for the WPAD implementation, and when it can’t find it, it will load your proxy script – There is a noticeable delay).

This is similar in Firefox. Click on Tools -> Options, click on the Advanced icon up the top, click the Network tab and then click the Settings button.

Clear any previous proxy information here, select the Automatic proxy configuration URL radio button and provide the path or URL to your PAC file in here (see the section above Publishing Your PAC File if you haven’t already).

As I mentioned before, you can manage these settings using Group Policy. For Internet Explorer, there are built-in configuration options in Group Policy, but in Firefox you need to rely on the use of third party tools, or alternatively an in-house developed option. There is a fantastic Firefox setting management add-on for Group Policy called FirefoxADM which can be downloaded from SourceForge at

Deploying Automatic Configuration Using WPAD

As mentioned at the beginning of this article, you can publish your wpad.dat file using DNS and/or DHCP, although DHCP is probably the more preferred method because it is more flexible and is more easily distributed to your client machines than DNS is.

The DNS method requires the HTTP distribution of the wpad.dat file, and also requires that a CNAME alias record called wpad is created in the root domain in DNS and points to the web server that hosts your wpad.dat file. I’ll go in to specifics shortly.

The DHCP method is much more flexible, as it supports both the file system and HTTP based methods of wpad.dat distribution, and requires that you add an extra scope option to your DHCP server.


You need to have uploaded your wpad.dat (remember, lower casing for compatibility reasons) to an HTTP server and added the MIME type of application/x-ns-proxy-autoconfig for .dat file extensions. Also, it’s important that the file can be downloaded via the IP address, rather than the hostname (which means you CAN’T use host headers) because some applications actually resolve the host themselves, the then use the IP address to obtain the wpad.dat file from the server. Basically, if you can’t download http://<ipaddress>/wpad.dat, then you’re probably going to run in to issues.

If you can get to your wpad.dat this way, then you’re nearly there… The second requirement is that you need to manage your own DNS services internally, and you need to add a CNAME alias record called wpad which points to the hostname of your HTTP server where your wpad.dat file is stored. This CNAME record needs to exist in the domain that you have recorded in your client’s DNS suffix configuration on their NIC settings. If this doesn’t exist, you need to populate that information on the NIC settings to avoid problems. If you are on a Windows domain, this should already be configured.

From the clients, ensure you can ping browse to http://wpad/wpad.dat and download the file. If you can, then skip over the next DHCP section down to the part about browser configuration for WPAD.


This is my preferred method, because…

  • It supports both file system and HTTP based hosting of the PAC file;
  • It supports custom ports;
  • It doesn’t require internally managed DNS;
  • It doesn’t require NIC settings modification to allow remote or misconfigured machines to resolve the WPAD DNS entry

To deploy your PAC file via DHCP, you need to add an extra scope option 252 to your DHCP scope. If you are using Windows 2003 DHCP, then you can following this article –

If you’re running a different DHCP server, you need to ensure that it supports the addition of custom scope options. If it does, create the 252 option, and then add it to your scope populating the information with the location to your PAC file, but it’s important to add a trailing space to the location of your file, as there are some cases where the last character is truncated and therefore the PAC file is not loaded correctly.

You’ll need to renew the DHCP lease on the clients in order for them to obtain this information. Unfortunately, the only way to verify that your clients are receiving this information, is to use network capturing software, such as Microsoft’s NetMon, to monitor the DHCP lease negotiation.

Configuring the browser

The last step with the WPAD implementation, is just to ensure that the Automatically detect settings box is checked in the browser (called Auto-detect proxy settings for this network in Firefox).

You can do this by Group Policy, if that’s an option, or make the change for/advise your users.