Office 365 PAC File

When we talk about Office 365 services with our customers, a lot of the discussion revolves around the networking components.  While we generally have a "good idea" of networking, we're not experts in your technology and will frequently tell you to go talk to your vendors.  We have some guidance on how to configure your environments, but generally don't provide configuration files or samples that can be used in products that are not our own (understandably).

One area that we typically have a lot of talks on is the proxy environment.  Typically, the security people want all of the organization's egress traffic to flow through a proxy (presumably to categorize site visit frequency and bandwidth consumption patterns).  However, all Office 365 traffic is encrypted, so aside from seeing the request URL, none of the content will be visible.  As such, the proxies will terminate this traffic and then start a new session on the requesting client's behalf (hence, "proxy.")  This works fine for simple HTTP web requests from browsers.  Office applications (such as Outlook) were originally designed for LAN environments and consequently, still sometimes behave like that.  An Outlook client with a few open mailboxes and a GAL query may consume 10 or 15 sessions by itself on the proxy sever; at some point, with enough users doing this, you will exhaust the resources in your proxy environment for no discernable benefit.  Thus, we recommend customers bypass the proxy of Office 365 requests.

Typically, you can configure your proxy server environment (if its an implicit proxy) or configure desktops (if it's explicit) with a PAC file, which contains instructions for handling URLs and IP addresses (such as "go to proxy" or "go direct").  Successfully bypassing your proxy requires two parts:

  1. Configure a bypass list.  Possible options include a proxy automatic configuration file (PAC) or a Group Policy Object that explicitly defines which sites to not send to a proxy server.
  2. Configure an outbound firewall rule to allow access to the appropriate IPs and URLs.

Some modern firewalls include URL filtering, but many in the field do not.  For those customers with more traditional hardware, you will  need to configure those two line items separately.  The sticky wicket is that many administrators don't know how to actually write a proxy PAC file.  A PAC file is a JavaScript construct that tells the browser where to send URL requests.  Once you deploy a Proxy PAC file, you need to keep it up to date (which can be tedious).  I have attempted to kill both of those birds with this script.  You can schedule it and set its output to a network location, and then point a GPO or WPAD discovery to this output.

For more information on how a PAC file works, you can head over to, which shows the structure of a PAC file and some of the instructions that can be used.  You can also download the PacParser tool from, which you can use to validate this (or any other) PAC file.


You can download the full script below over at the TN Gallery.  If you'd like some information on how to distribute the PAC file, please see my other blog post, "Deploying of Office 365 Proxy PAC to Manage Your Users."

Check out for the latest version of this tool.