Random error of the day – Office 365 OWA URL change

7612.Office-365-logo_thumb_58DAF1E4

This post is another heads-up for Office 365 admins behind proxy servers as we had an odd issue last week that’s an easy fix but wasn’t so obvious to spot…

OWA loading error

In Chrome some of our users were reporting that Chrome returned an ERR_CONNECTION_RESET page when trying to load Outlook from the Office 365 apps tray. It only affected a couple of users and the link was working OK in Internet Explorer.

After a bit of playing with various ways to get to OWA I found that if we removed the end of the URL and simplified it to just the “outlook” subdomain everything loaded OK… strange.

We logged a call with our Bloxx proxy support and they responded swiftly, taking some Wireshark captures on both proxy and client. Their analysis helped pinpoint the cause of the issue…

The captures showed that the client did initially talk to the proxy but then decided to continue the next part of the connection directly, which was then blocked by outbound rules on our firewall. In our WPAD file we have a wildcard entry towards the end that returns DIRECT for any in-house servers and it seemed that the “realm=havering-college.ac.uk” part of the OWA URL in the image above was matching the rule and thus trying to bypass the proxy.

What’s changed?

Although the theory made sense on one hand it didn’t on another as we’d never had these issues before. Looking around for what’s changed in our environment put a few culprits in the frame; Google Chrome updates and the Office 365 platform itself.

At this point I went back on my VM, which was now exhibiting the same issue. At one point I had the WPAD file open and the failed web page side by side… then the lightbulb moment!

On one screen I had OWA open with a domain starting https://outlook.office365.com but on my VM it was trying to load https://outlook.office.com – that’s new!

Going back into WPAD I then added another explicit traffic entry:

   /* Send Outlook OWA traffic via proxy here*/
        if (shExpMatch(url, "*outlook.office.com*"))
      { return "PROXY X.X.X.X:8080";}

Immediately OWA started working! It’s bizarre how some applications seem to need these rules in order to route traffic using Auto Detect but it seems to consistently fix issues when they pop up. As for the OWA URL, it seems to be a bit random at present which one gets used, although both are listed in the Office 365 URLs and IP ranges KB article so maybe Microsoft are in the middle of changing them over?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: