O365: CDN Change Causes OWA Client Error

Recently, we've seen a pattern of escalations wherein users are no longer able to access OWA. Specifically, the error will be similar to the following:

In the details, we'll see the error we're concerned with:

X-OQA-Error: ClientError;exMsg=’_g’ is undefined; file=https://pod51048.outlook.com/owa/:362

If we use Network Tracing (F12 in Internet Explorer) [or Fiddler] we'll see a failure to connect to the CDN:

The connection to 'r1.res.office365.com' failed. <br />Error: ConnectionRefused (0x274d). <br />System.Net.Sockets.SocketException No connection could be made because the target machine actively refused it 23.221.8.9:443

Using ARIN, we can check to make sure that the CDN (Content Delivery Network) we're trying to hit is owned by Akamai.

The return we're receiving, highlighted, is because the client cannot load 'boot.worldwide.0.mouse.js' from the CDN. This is evidenced by the refusal to connect to the RES server, highlighted.

The root cause of this issue is the configuration of the customer-owned firewall. This is evidenced by the client's inability to connect to specific CDN and other users are able to use OWA sans issue; notably, because they are connecting to another CDN ('r4.res.office365.com', for example).

Since the CDN is controlled by a third-party and we have no way to predict which hosts will be up/in use/referred, our recommendation is to use URL-based filtering. You can read the EHLO blog post (written by our very own Tim Heeney) on the recommendation for URL-based filtering, here: https://blogs.technet.com/b/exchange/archive/2013/12/02/office-365-url-based-filtering-is-just-better-and-easier-to-sustain.aspx