Exchange.
Owa.
2 separate sites.
2 separate internet connections.
Site A has the mailboxes.
Site A's internet connection goes down.
Site B's internet connection is fine, and the ds-3 between the sites is fine.
I try to connect to OWA in Site B and I get...
"For best performance, connect to https://SiteA.mydomain.com/owa"
YOU HAVE GOT TO BE FREAKING KIDDING ME! ARGH!
Ok. A google search and check the Exchange Blog comes up with this link.
Understanding Proxying and Redirection According to this paper a couple of things are at work. First off, Exchange is trying "Redirection" to send me to the OWA host in my active directory site. You can disable redirection by removing the "External Url" from the OWA service in Exchange manager.
Click webmail. Username/password. Does it work?
... Nope, same results.
(Wait for Active directory replication....)
Testing again. Click webmail. Username/password. Does it work?
... Nope. New Results. A great two line error message that tells the user to tell their Exchange administrator that there is no available OWA server in the same site as the mailbox. Also, an event is logged in the event viewer.
(OMG! A descriptive error and an event gets logged?! Obviously this part of the code was outsourced. ;) )
Anyway, back to the paper again. Exchange Owa won't access a mailbox in another AD site. It just won't do it and there is no convincing it otherwise.
The options are:
1. Setup an ISA server to intelligently load balance Owa access. (no.)
2. Move the Servers into the same AD site. (no.)
3. Enable "Proxying". (this sounds promising.)
OWA Proxying takes the request from SiteB's owa server and relays it internally to SiteA's owa server. That is great if SiteA's internet connection goes down, but does jack-diddly-squat for our availability if SiteA's OWA server goes kaput.
Some redundancy is better than none, right? Let's configure proxying.
Here are the Gotchas.
1. Redirection has to be disabled. (Remove those ExternalURL's)
2. Communication is via https. (This is okay, I put the internal names on our UCC ssl cert.)
3. Authentication for the OWA sites has to be set to Windows integrated.
WTH?! The users just got used to pretty forms based authentication. You go to all the trouble of building a proxy subsystem and you can't relay the credentials?! Another show stopper. Grr.
So my options are to setup 2 more owa servers with integrated authentication. Get 2 more names on our ssl cert, and set it up. That's great and all, but exchange licenses don't grow on trees.
Solution!
I played with it for a while and came up with this solution. It is functional, but not really elegant in my opinion.
In both sites, I opened IIS and created a new website called OwaProxy. I set the site to use the same ssl certificate as the "real" OWA sites, but bind to port 444 instead of 443. In the powershell console, I created a new \owa directory with Integrated Authentication.
(here is the command)
New-OwaVirtualDirectory -Name "OwaProxy" -ExternalAuthenticationMethods WindowsIntegrated -ExternalUrl $null -Internalurl https://sitea.mydomain.local:444/owa -Owaversion exchange2007 -websitename "OwaProxy"
After the OWA Websites/virtual directories are created in both sites, there are two more gotchas. First, it still didn't work until I opened the Exchange Management console and changed the authentication type from forms to WindowsIntegrated. This is a bug, Imho, as we explicitly set the authenticationmethod to integrated in powershell. It gets configured properly in IIS too, but here you have to change it with the GUI.
The second gotcha is an easy one. Any of this cross-site stuff is dependent on Active Directory, so you have to wait for (or force) ad replication before your changes take effect.
That solved it. I could now access my 1GB SiteA mailbox from SiteA or SiteB. We have a 45mbps ds-3 between sites, and there was a 2-3 second pause after logging in to SiteB's owa server. I can live with that.
Please leave a comment if this helps.
Thanks,
Ellie
