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.
Post a Comment