OMA & ActiveSync after Configuring RPC/HTTPS and Forms-Based Authentication
Originally published June 17, 2004
Just got off the telephone with PSS.
We recently configured RPC/HTTPS and started moving clients over to using it on our new Exchange 2003 servers (it's really helped business to not require a VPN). How RPC/HTTPS scales for service providers is a topic for another (long) article, when I have a few hours to put it together.
Anyway, configuring RPC/HTTPS and turning on Forms-Based Authentication on the Default Web Site suddenly broke OMA and ActiveSync.
What specifically broke it was requiring HTTPS on the Default Web Site for OWA. But this was non-obvious (to me).
Just following KB 817379 didn't work (and why is this required, anyway? - this is a bug, IMO). I fiddled around with it “in my spare time“ for a couple of days until the uproar from it not working made me call PSS.
After reviewing a whole passel of SO's (solution objects), the tech finally hit on the right solutions:
1) Enable Integrated Windows Authentication on the new Exchange virtual directory created when following KB 817379, and
2) Change the default website IP address to “all unassigned”.
I'm not really thrilled about (2) -- historically, I've always limited the Default Web Site to a single IP address and host header - but I might be overly paranoid. And it's likely that adding all the server IP addresses (including 127.0.0.1) would've also fixed the problem. Apparently OMA and ActiveSync throw messages around to each other and other Exchange web service extensions pretty indiscriminately in terms of IP address...
I'm not a mobile devices expert (I rather like my laptops and desktops), but this just seems weird to me.
Other stuff I did to minimize the end-user pain in installing HTTPS for OWA was to put in a “Default.asp” redirect in the default website (KB 839357), and remap the 403.4 “SSL Required“ error to a redirect (KB 268822 updated for Exchange 200x).