Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to SearchExchange.com. If we publish it, we'll send you a nifty thank-you gift.
VIEW MEMBER FEEDACK TO THIS TIP
You may experience several Event ID errors when using forms-based authentication with Exchange Server 2003 ActiveSync and Outlook Mobile Access (OMA). The errors on the client side usually consist of one of the following:
Unable to connect to your mailbox on server <server name>.
Please try again later. If the problem persists contact your administrator.
---------------------------------------------
A System error has occurred while processing your request.
Please try again. If the problem persists, contact your administrator.
---------------------------------------------
Synchronization failed due to an error on the server. Try again.
Error code: HTTP_500
The last error occurs if a user tries to run Exchange Server ActiveSync. The others are also accompanied by Event IDs 1805 and 1507, respectively, in the Exchange server's event logs. The Exchange server may also log Event IDs 3029, 3030 and 3031 as well.
This particular annoyance buzzes out whenever you have the following conditions:
- Exchange OMA is hosted on the back-end server of a front-end/back-end Exchange Server configuration.
- The back-end /Exchange virtual directory in Internet Information Server (IIS) is configured to use Secure Sockets Layer (SSL).
- Forms-based authentication is enabled -- this is when you enter your username and password via a Web form with several logon options, instead of through the pop-up dialog that is typically used for integrated user validation across a Web connection.
The /Exchange virtual directory can't be accessed by OMA and ActiveSync if it's hosted in this fashion. Forms-based authentication can only work through the Basic authentication method (the security for the process is supplied by the SSL connection itself); but ActiveSync's virtual directory can only connect to the Exchange Server virtual directory via Kerberos (NTLM) authentication.
NTLM authentications cannot work over more than one system "hop." If you have a front-end to back-end connection with NTLM authentication somewhere in the chain, it'll only work if the front end does the actual authentication.
This is due to limitations in the way Kerberos tokens can be honored from machine to machine. So for front-end/back-end setups, the easiest and most "portable" authentication methods involve Basic authentication via SSL, which have no such restrictions. This particular problem is one of a number of different manifestations of this whole issue.
The most basic workaround is to place the /Exchange virtual directory on the front-end server, or disable forms-based authentication. If this isn't practical, there is another solution -- a detailed registry-change process documented in Microsoft Knowledge Base article 817379.
In the long run, though, it's best to use a properly planned front-end/back-end topology whenever possible.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter.
MEMBER FEEDBACK TO THIS TIP
I have had trouble with OMA and ActiveSync when running forms-based authentication (FBA) on ISA Server 2004. After changing FBA from ISA Server back to Exchange 2003 SP2, I haven't had any issues.
Do you know of a procedure or fix available to allow OMA and ActiveSync to work with Exchange when FBA is done on ISA Server?
—Todd R.
******************************************
I did a little digging and found a tutorial on ISAserver.org, "ISA Server 2004: Supporting Both Basic and Forms-based Authentication with a Single External IP Address and Web Listener," that talks about using forms-based authentication with ISA Server.
The single biggest problem appears to be that you cannot bind both a basic and FBA listener to the single IP address that ISA Server presents to the world at large. However, this article describes a clever workaround (essentially, creating a listener on the localhost address). It's implemented for OWA, but it might also work for OMA -- in fact, it should work with only minimal changes to the configutation, based on a read of the instructions.
Good luck, and if it works for you please let us know. It would be worth passing this on to others if it turns out to be what you need.
—Serdar Yegulalp, tip author
Do you have comments on this tip? Let us know.
Related information from SearchExchange.com:
Exchange Admin 101: Configuring OMA and ActiveSync
Tip: Issue with Outlook Mobile Access and certificate authorities
Tip: Problem with ActiveSync and front-end DNS aliases
Step-by-Step Guide: How to repair Exchange-related IIS virtual directories
Reference Center: Exchange mobile and wireless tips
