Using features of Azure to quickly fault find problems with ActiveSync

Colin Chaplin is a freelance Infrastructure Architect who helps large organisations transform Microsoft-based infrastructure.

Even if you’ve not used Azure before, you’ll be familiar with its ability to spin up virtual machines in minutes. What’s less publicised is the incredible flexibility in networking operations. Here’s a real-world example of how to use it to fault find ActiveSync issues.

The trouble with ActiveSync – and indeed most modern communication protocols – is that they are encrypted. So when you’ve got a problem and server-side logs are just not providing the answer, it can be incredibly useful to see communication ‘in the clear’. With production environments it’s often not possible to change the server end, so the following is how to read encrypted ActiveSync traffic (for debugging purposes only).

Step by step

Firstly, spin up a VM in Azure – it doesn’t really matter what OS, but since we’re on-trend we’ll use 2012 R2.

Let’s pick some details, in particular we need to assign a TCP port for Fiddler.

Go fetch a cup of tea whilst the machine is spun up for us...

If you’re a seasoned techie, you’ve probably already used Fiddler for troubleshooting IE and internet issues. We’re going to use it here, as a man-in-the-middle proxy. For this to work you will need to download it here.

You will also need to download the ActiveSync inspector for Fiddler.

This drops into the Inspectors folder.

Run Fiddler. In Fiddler Options >  HTTPS >  tick ‘Decrypt HTTPS traffic’ and select Yes to trust the root CA.

Click Export Root Certificate to desktop. We’re going to use that later to make phones trust the ‘fake’ certificates that fiddler generates.

Go to connections tab and tick ‘Allow remote Computer to connect’. Note that Fiddler connects on port number, this must be set the same as the private port on our Azure endpoint.

Restart Fiddler as prompted.

We now need to take the certificate generated and distribute it to the phones we wish to debug. The most straight forward way to do this is via an MDM solution (especially if you have multiple phones to test) - alternatively you can email the user of the phone and ask them to install.

We can confirm installation by looking at the certificates on the phone. In the case of Windows Phone, installing the Certificates app (I’ve installed two Fiddler Root certs here)

Finally, we need to configure the WiFi that we’re using to use a proxy. In this case it’s the name of our Azure VM, and the public port we cunningly selected earlier.

Now let’s create some traffic and look at our VM…

BOOM. ActiveSync Traffic in the clear. To see a definition of ‘good’ here’s a trace running to Office 365. We can see the connections, HTTP status codes and content of messages.

In the screenshot above, we can see connection 217 is an open connection; this is how ActiveSync seemingly instantly delivers an email to your phone, a long-running TCP connection between the phone and the ActiveSync server which is closed when the ActiveSync server has data for the device.

The fault I was troubleshooting was slow delivery to the phone. What was very clear in Wireshark was the long running connection closing after exactly 5 minutes; this was due to a misconfigured load balancer.

Standing up a server, configuring NAT and firewall rules could take days in a traditional corporate setup; here we’ve stood up a solid testing environment (and, torn it down) in minutes.