They check proxies every hour and display them to the public. Free.

Another way to look at this situation: Group Policy (GP) is designed to look after the internal enterprise through Group Policy Objects (GPO’s). In todays world, many corporate users will use a company laptop outwith the enterprise at least some of the time.

In a GP assigned environment, if the user wants to go on-line outside the corporate network they have to start manually disabling proxy settings, as GP is not clever enough to realise the laptop has left the corporate environment and should, therefore, turn off the proxy setting.

It is also becoming more common in industry to see companies performing remote filtering – i.e. continuing to police the web-content available on the laptop outside of the enterprise network. This can be achieved in several ways. One is to open port 8080 (or whatever port you are using for proxy) to the outside world with an associated public DNS entry. This, however, exposes a rather large (and somewhat unsavoury) hole in your firewall for the delivery of variable HTTP content.

The second is to use a remote-filtering system (such as that offered by Websense). The problem with the Websense system is that it will detect and filter when the system is outside the network, but will not swap the connection to the internal address when brought back in to the enterprise.

In the first scenario, you would be asking for trouble – opening the proxy port is providing potential attackers with lots of bi-directional obscure data traffic to hide within. The second scenario would still require the user to manually intervene with the proxy settings at some stage.

By introducing a PAC file, you do not need to trust users to make the correct changes. Trust me, there are some people who simply cannot grasp this – even though it is only un-checking a box. PAC files make the administration much easier . As a text file, it is much more straightforward to navigate than GPMC when adding exceptions. With GP, you must wait for the changes to replicate throughout the enterprise, then you need to wait for the client PCs to update their policies. This can take hours, depending on your replicate / update scehedules. With a PAC file, you modify it, save it and the changes are live – much more flexible!

david.

The best examples that I can give for a PAC file are those that I’ve listed in the article:
- Laptop users don’t need to adjust their proxy settings
- If you need to route some URLs through specific proxy servers you can with an auto-config script

Some other that I can think of:
- Instead of multiple GPOs for different BU’s or domains – centralise proxy settings in the script
- An auto-config script can change proxy settings based on client IP (e.g. VPN connections)
- Browsers will auto-detect by default, so with correct DNS configuration, you don’t need to deploy GPO at all

Ultimately, if you can make hard setting a proxy server work for you and a bypass list is manageable, then perhaps an auto-config script may be more work to implement. I would still recommend being familiar with PAC files as I think they’re pretty cool stuff.

Even Jason’s reason for it seem more simply solved with private network exceptions and proper DNS configuration. How big can a bypass list really need to be? Can you give a detailed example where .pac files would be the easier method?