OWA Redirection Does Not Work for Migrated Mailbox to Exchange Online

So you have migrated a user to Exchange Online (via hybrid configuration). You told the user upfront that they should still be able to use the existing OWA hyperlink and will get a page reminding them that their mailbox has migrated to Exchange Online and bookmark outlook.office365.com instead.

But instead, the user is presented with this page with a sad face instead:

The error message is:

We could not find a mailbox for this user. Either this recipient has not been configured with a user mailbox or does not have a license assigned. Please contact your helpdesk for further assistance.

X-OWA-Error: Microsoft.Exchange.Clients.Owa2.Server.Core.OwaUserHasNoMailboxAndNotLicenseAssignedException

Of course you have assigned Exchange Online licenses (or E3), and the mailbox has obviously moved to Exchange Online.

The resolution is rather simple but rarely documented.

Clear your browser cache, close the browser and login again.

Boom! The error goes away and the correct page showing the correct URL to be bookmarked.

Exchange 2007 OWA not playing nice with Exchange 2013 for redirection

As part of Exchange 2007 & 2013 co-existence, to provide seamless OWA login for both users having mailboxes in either Exchange environment, the typical Microsoft prescribed method of OWA redirection was deployed  - http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

As the customer was using ISA Server 2006, the first thing is to bypass that and change Exchange 2007 OWA into Forms Based Authentication (FBA). It was set to Basic Authentication previously to support ISA 2006 publishing.

Here comes the trouble, after logging in from OWA 2013, the following error message was displayed:

440 Login Timeout

We tried numerous things, including changing the authentication methods in IIS7 for OWA, but none worked.

The only way that we managed to get it working is to re-create the OWA virtual directories following the article (http://support2.microsoft.com/kb/941201). Only trouble is, although all the virtual directories were deleted and recreated successfully, the /OWA virtual directory would not come up! When the PowerShell cmdllet was ran, an obscure error message popped out (sorry I didn't have screenshot), basically saying that is has no access to Active Directory.

Did a few things and none worked (including forceing AD replication "repadmin /syncall"),

More Internet searching came out with this solution  (http://blogs.dirteam.com/blogs/davestork/archive/2010/12/23/fixing-a-broken-owa-2010-virtual-directory.aspx) - but just as I was going to recreate the OWA container, I tried re-running the New-OWAVirtualDirectory cmdlet (not retyping it, just running the command history to repeat the command) and it worked.

I have no idea why only the /OWA virtual directory have this problem (/Exchange, /public/ and /exchweb had no such issue) - but I guess sometime button meshing does make sense.

Oh well, onward we go.

Fido what?

Nope, this has nothing to do with Fido Dido.


I've been working on this Exchange 2013 Hybrid deployment when I came across this when accessing OWA from IE11/Win8.1.

After I sign on (Exchange 2013 FBA), OWA briefly loads and then crashes with the following error message:

X-OWA-Error: ClientError;exMsg='fidoCallback' is undefined;file=https://owa.company.com/owa/:1
X-OWA-Version: 15.0.995.29
X-FEServer: EXCH-SVR
X-BEServer: null

Scouring the Internet, I could not find any reference to "fidoCallback" relating to OWA, but there were some other suggestions relating to Office 365 OWA crashing in similar fashion (but no reference to fidoCallback):

1. Clearing the cache (d'oh - first thing that anyone would try)
2. Reset IE's security setting to default (under Advanced tab, not Security tab)
3. Try InPrivate browsing
4. Make sure "Enable XMLHTTP Support" is enabled

None of them worked. I thought I was going mad as I got some other people to try it out as well, same Win8.1 and IE11. All of them worked.

Then I came across an article that talked about setting IE as the default browser - http://answers.microsoft.com/en-us/ie/forum/ie11-iewindows8_1/office-365-issues-with-ie11/5fb4f186-fdf1-4cde-ab48-b97987306aa6  (I use Chrome almost exclusively - which can access OWA without a problem) and it worked. Bizarre! To set IE as default, Start > Search > Default Programs > Set your default programs > Internet Explore > Set this program as default. Restarted my computer and voila!

I can't understand why this is happening, and I might ring up Microsoft if this persists. Keep posted!