How to Test and Monitor Zscaler Proxies for Office 365

March 27, 2018
Team Exoprise
Blog Posts

Recently, Zscaler had a very successful IPO after a meteoric rise. Exoprise has witnessed, first hand, this rise in usage and adoption of Zscaler especially for Office 365 and other cloud apps. Many mutual customers use CloudReady to test, monitor and compare Zscaler for Office 365 within their environments. Exoprise’s biggest customers monitor Zscaler access to their cloud services with Exoprise CloudReady ensuring their own network and egress points are performing well 24×7 across their branch offices and more.

Zscaler Growth in Adoption / Traffic for Office 365

Last fall, Zscaler published traffic statistics for proxying Office 365. With over 700+ customers (over 70% of the Fortune 500) they were processing over 3000 Terabytes / Month from 100 different datacenters, serving over 180 different countries. That’s a lot of Office 365 proxying.

Capacity Planning & Test Required

If you plan to leverage cloud services through proxies of any type – whether premise or cloud-based proxies, then you must test for capacity and performance before, during, and after cloud migrations. Exoprise has worked with numerous customers who have not properly planned large scale roll outs and then forced to scramble and isolate proxy problems due to capacity, routing and ISP/MPLS capacity. This is common because when all the Windows services traffic was behind the firewall, the proxies weren’t taxed, but once you move all of the services like Exchange, SharePoint, OneDrive, Azure outside the proxies, the infrastructure will require tuning and expansion. That’s why many customers look at new solutions from Zscaler, Palo Alto networks, Cisco and others during the migration.

Other issues contribute to proxy problems when moving to Office 365. Protocols like MAPI-over-HTTP or Onedrive and SharePoint synchronization require more long-lived sessions that may quickly exhaust existing proxies and firewalls. Routed MPLS and Hub-n-Spoke network/branch-office configurations can introduce unnecessary network latencies across a variety of applications and use cases.

Continuous Monitoring/Test Designed for Dealing with Proxies

Exoprise CloudReady was designed to fully support testing and monitoring through proxied environments – just like your real users. Most CloudReady sensors are designed to operate thorough proxy configurations of any kind, regardless of whether you deliver them through complicated PAC (Proxy Access Config) files, WPAD (Web-Proxy Auto Discovery Protocol) or transparently. CloudReady private sites, which run sensors that emulate user behavior and experience, can also be installed to bypass the proxies. This gives customers the opportunity to test out their access with and without the proxies for benchmarking proxy solutions like Zscaler. Lastly, Exoprise has its own cloud hosted public sites that enable customers to compare their own network performance, behind-the-firewall, with pure cloud networking environments. This is Network Intelligence.

How To Setup a CloudReady Private Site with Proxy PAC or WPAD configuration

By default, the Exoprise Management Client is designed to work with your existing Proxy configuration detected during installation. This works well, up until you want to install a service (a CloudReady Private Site) as Local System and have complicated PAC files because, typically, most environments don’t manage proxies for their Local System account. The Exoprise Management Client will copy the current fixed proxy settings from the desktop to the Private Site setup during installation. But this has limitations for Proxy PAC or WPAD configurations.

Currently, to utilize a Proxy PAC or WPAD delivered PAC file, you must install the CloudReady Private Site as a User Account as opposed to Local System. This ensures that the Proxy PAC file is the same one that you’ve configured your users to use. And for that user account, configure the Proxy PAC through Group or Local Policy. You can also configure it within the Internet Explorer settings for that user account local to the machine.

Zscaler Proxy PAC Configuration

The same procedure works for setting up Private Sites against a Zscaler proxy configuration with PAC file. There are various notes and walk-throughs about how to setup Zscaler proxy PAC configurations with Hosted PAC files, here’s a few of them:

Here’s some sample screens illustrating the step-by-step process of configuring the Private Site with a user account. Access to CloudReady will be tested through the PAC rules during installation as well:

Start a Trial Today and See for Yourself

Every day we have customers start and deploy sensors in under 5 minutes. Give it a try for complete end-to-end visibility, SLA compliance and real-time diagnostics.

START FOR FREE

Analysis & Monitoring With CloudReady

So what can you do with a CloudReady Private Site now that you have it configured behind a Proxy PAC or Zscaler cloud-based proxy? You can deploy lots of sensors to emulate and benchmark the end-user experience. We’ll highlight some of the sensors that can be deployed and some elements that are relevant to Proxy support. We’re always adding new elements to each sensor and enhancing support of the sensors to support better telemetry into proxy configurations.

CloudReady Sensors With Proxy Connect Times

The SharePoint sensors operate against SharePoint online through any proxied environment including Zscaler and also perform an out-of-band test against the configured proxy so that you can understand how much latency is being introduced by the proxy. We have to perform this out-of-band TCP/IP connect to the proxy because all HTTP/HTTPS proxies are transparent in their nature. All proxy vendors, including Zscaler, don’t include any additional headers that throw off timings or latency metrics are part of their normal transactions.

Example Showing SharePoint Proxy Connect Times vs Time to First Byte and TCP/IP Connect across the page transactions