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.
- Users are directed to webmail.example.com to access OWA.
- 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).
- 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:
- Sign out of Outlook Web App
- Clear the browser's cache and "offline data"/"offline websites"/etc (cache alone is not sufficient)
- Close the browser completely
- 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?
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
We faced this error also when updated Exchange 2013 from SP1 to CU9. And found out that error isn't reproduced in IE11 "real" browser not a desktop one. Desctop IE gets the same error. Verified on win 7,8.1,10. So users can set any options there and then use any other browsers, just for regular mailflow operations. May be this adjustments also will be needed, but we didn't use it:
https://social.technet.microsoft.com/Forums/ie/en-US/26653190-2c27-4da8-a9a9-614b2b5fd41c/internet-explorer-11-owa-2013-cu2-automatic-replies-critical-error?forum=ieitprocurrentver
Thanks.