OWA users getting "Critical Error" when accessing their Options

Question

I work for a good-sized school district and have just successfully deployed Exchange 2013 and migrated all of our users' mail to the new system over the summer. Been a few bumps along the way, but with school starting up again soon we have a large number of staff now logging in and using the new system for the first time, and unfortunately a small but growing number of them are beginning to encounter the now-dreaded "Critical Error" message when attempting to access their Options:

The full report is thus:

Client Information
------------------
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:39.0) Gecko/20100101 Firefox/39.0
CPU Class: undefined
Platform: Win32
System Language: undefined
User Language: en-US
CookieEnabled: true
-----------------
Exception Details
-----------------
Date: Fri Aug 07 2015 14:38:24 GMT-0800 (Alaskan Standard Time)
Message: Error: Permission denied to access property "frameElement"
Url: https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js
Line: 1

Call Stack
----------
ErrorHandling.$EM@https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js:1:172926
ErrorHandling.showUnhandledException@https://webmail.example.com/ecp/15.0.1104.5/scripts/common.js:1:171997

Detailed Call Stack
-------------------

That's not a typo or omission, the "Detailed Call Stack" really is blank. This happens regardless of browser: I've received reports from users using Firefox, Chrome, Safari, and IE; pretty sure the only reason Opera's not on that list is that no one uses it. Reloading the page (as the message suggests) doesn't help, and the "ok" button is useless. Once the error appears, the user can close and re-open the browser or even go to a completely different browser and get the same results.

This is purely a client-side error: Absolutely nothing relevant shows up in server logs when this occurs.

This seems to me to be obviously the web browser employing its usual anti-XSRF defenses and OWA handling that error "nicely". What I've been unable to figure out for 4 weeks running now is why this is happening.

1. Users are directed to webmail.example.com to access OWA.
2. Every single virtual directory on every single server is configured to use webmail.example.com as both the external and internal hostname (or host part of the external/internal URL).
3. Looking at the Network panel for a web browser exhibiting this error, I see nothing but requests for resources on webmail.example.com -- there's simply no other host involved that I can see.

What's doubly strange is that when this occurs, most users can clear it up by following this procedure:

1. Sign out of Outlook Web App
2. Clear the browser's cache and "offline data"/"offline websites"/etc (cache alone is not sufficient)
3. Close the browser completely​
4. Reopen the browser and sign back in to OWA

It's only a temporary workaround, however, as the issue returns shortly.

How can I figure out what's causing this error, and more to the point how can I fix it?

Solution

We found a fix for Firefox and Chrome, while not breaking the already working IE11. This applies for whenever a user is redirected to OWA from another webapp, which opens OWA in a new tab:

Adding rel="noreferrer" to your html link tag should help: http://blog.chromium.org/2009/12/links-that-open-in-new-processes.html

We are still looking for a fix that works with the Edge browser. Currently our work-around is to CTRL + Left click the link

Comments

[Kromey]

Oops, forgot about this question... we solved it the same way, and additionally added a "landing page" at https://webmail.example.com/ that (via JavaScript) sets window.opener to NULL before redirecting the user to OWA (at /owa/). I also had similar logic being injected (via our load balancer) on the /ecp/ path (where the user lands when accessing their Options; this was in case the user somehow bypassed the landing page), but this was causing intermittent Critical Errors to appear when using the Admin Center, so I took that out.