ActiveSync and front-end DNS aliases

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 our tip contest and you could win a prize.

Microsoft recommends having a front-end/back-end server configuration when using Exchange's mobile access features.

The front-end server should handle static content (such as Outlook Web Access pages), and the back-end server should do the actual LDAP and Exchange work. This reduces the overall load on each server, especially when you have many clients connecting at once.

In a front-end/back-end scenario, the client connects with the front-end server over an HTTPS connection, which requires a Secure Sockets Layer (SSL) certificate to encrypt the data.

The connection from the front-end server to the back-end server is done through regular HTTP, but with "integrated" authentication to ensure the HTTP request is coming from a machine with the right credentials. Because of this, the certificate credentials for SSL need to be correctly assigned.

Sometimes ActiveSync will not work if an SSL certificate is using the front-end server's DNS alias. The DNS alias will not be recognized as the appropriate Service Principle Name (SPN), which in turn causes Kerberos authentication (and SSL) to be disabled.

This can happen if you've set up DNS aliases for the servers after they've been moved into your production environment. It's usually easier to change credentials for DNS aliases on the back end than it is to revoke and generate new certificates based on the new DNS aliases.

To fix the issue, use the Setspn tool to add the front-end server's DNS alias as a valid SPN for the HTTP service (which was invoking SSL and Kerberos).

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter and a regular contributor to SearchExchange.com.