Tag Archives: Autodiscover

Autodiscover in Exchange

Autodiscover is a feature in Exchange Server 2010 and higher which is being used by Outlook 2007 or higher. Due to the number of question I get on Autodiscover I’ve created a number of blog posts that explain the Autodiscover functionality:

Introduction

Autodiscover is a very useful feature in Exchange 2007 and Exchange 2010 that makes it possible to automatically create Outlook 2007 and Outlook 2010 profiles.

Continue reading Autodiscover in Exchange

Autodiscoverredirect and TMG

In my blogpost Autodiscover Redirect and SRV option I explained how to use the AutodiscoverRedirect or the SRV records method to use Autodiscover when using multiple primary SMTP addresses in an Exchange 2010 environment.

This works fine as long as your Exchange server is connected directly to the Internet (behind a firewall of course) and you have the possibility to add public IP addresses to your Exchange Server. When using a reverse proxy solution like Threat Management (TMG) Server in front of the Exchange 2010 Client Access Server, all Exchange services are published to the Internet, and this requires a different approach for the AutodiscoverRedirect method.

First thing, the Client Access Server no longer needs to the autodiscoverredirect website since this is now handled by the TMG Server. So the Client Access Server can be used in a default configuration. In this environment a certificate with two FQDNs are used: webmail.exchange14.nl and autodiscover.exchange14.nl but now this environment is published using TMG 2010 SP1.

The TMG Server now intercepts all autodiscoverredirect traffic so a new rule with a new listener (on a separate IP address) needs to be created. Please note that this traffic is unencrypted, so HTTP (port 80) needs to be used for this listener. For the Client Authentication Method when creating the Web Listener select No Authentication.

image

The next step is to create a web publishing rule that uses this listener. This rule should deny all traffic and redirect it to the ‘normal’ autodiscover URL on the TMG Server, i.e. https://autodiscover.exchange14.nl/autodiscover/autodiscover.xml.

image

One thing to notice though, after creation of the web publishing rule you can select whether this rule listens to all requests or only for specific websites (select the Public Name tab). Also, don’t forget to change the redirection (select the Bridging tab) to port 80. Like the previous blog post you have to enter the autodiscoverredirect.exchange14.nl in the public DNS, and for other domain create a CNAME autodiscover record (again in public DNS) and point this to the autodiscoverredirect.exchange14.nl FQDN.

Now when you go to the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) and test using another domain you’ll see that it again works, but now via the TMG Server.

image

The warnings in this screenshot is about root certificate not being able to verify. Also note that in this example the RCA doesn’t even try the SRV method since the redirect method is successful.

SRV Records

The autodiscover SRV records option I explained in my previous article works immediately through the TMG Server. This makes sense since the information is taken from public DNS directly and the autodiscover service is accessed directly without any redirection.

image

One thing I would like to mention. Quite a lot of people think that autodiscover fails because of the 3 failing attempts (in the above screenshot). While this is true autodiscover successfully finishes the fourth option so autodiscover is considered to be successful.

Now combine the autodiscover redirect and the SRV method with the Address Book Policies that will be available in Exchange 2010 Service Pack 2 and you’re one step closer to your own Exchange 2010 hosting solution.

To be continued, stay tuned…

Error 600 Invalid Request

It is possible to test the autodiscover configuration using a browser. But when navigating to the autodiscover URL https://autodiscover.contoso.com/autodiscover/autodiscover.xml you’ll see a 600 Invalid Request error message.

image

When you click the Show All content button the entire XML package is shown:

image

When you see this message your autodiscover configuration is absolutely fine! The reason you see this message is that the autodiscover service expects an HTTP POST command from Outlook, and not an HTTP GET command from Internet Explorer.

So, the service is good but the actual request that’s send to the autodiscover service is not good and therefore autodiscover returns the Error 600 Invalid Request message. So this error is good 🙂

Autodiscover Redirect & SRV Record

When you have multiple primary SMTP domains in your Exchange 2010 environment you have to come up with a solution for autodiscover. Suppose we have an Exchange 2010 environment called exchange14.nl. The external URL would be something like webmail.exchange14.nl and the autodiscover FQDN would be autodiscover.exchange14.nl. In this you would need a UC certificate with both these names in it.

image

When there’s another (primary) SMTP domain in use in this Exchange 2010 environment we have to come up with something for the corresponding autodiscover record. When the SMTP domain called inframan.nl is also hosted in this environment, Outlook would look for a DNS record autodiscover.inframan.nl when Active Directory is not available, like on the Internet. Since this FQDN is not available in the SAN field of the certificate this would generate a client side certificate error, like “The name of the security certificate is invalid or does not match the name of the site.

To avoid this there are two options that let Outlook redirect its autodiscover traffic. The first option is to use an HTTP redirection method; the second option is to use SRV records in the public DNS.

HTTP Redirection

When Outlook cannot find its corresponding autodiscover record, like autodiscover.inframan.nl in this example, Outlook will start looking for a redirection option. You can create an additional website in the Client Access Server that listens on port 80, intercepts redirection traffic and sends it to the original autodiscover URL. This 2nd website has an additional FQDN, using an additional IP address. For example, for autodiscover.exchange14.nl and webmail.exchange14.nl the IP address 178.251.192.9 is used. The 2nd website will be autodiscoverredirect.exchange14.nl and its IP address will be 178.251.192.12. Do not forget to add this FQDN and IP address to the public DNS!

On the Client Access Server open the Internet Information Server (IIS) Manager and create an additional website called autodiscoverredirect. Use a physical directory like c:\inetpub\autodiscoverredirect for this website and bind the website to the additional IP address.

image

In this website create a new Virtual Directory called autodiscover. Use Autodiscover for the alias and use a physical directory like c:\inetpub\autodiscoverredirect\autodiscover for this Virtual Directory.

image

Open the properties of the new Vdir and configure HTTP Redirect. Select the Redirect requests to this destination and enter https://autodiscover.exchange14.nl/autodiscover as the destination of the redirect.

image

The last step is to configure external DNS. Create a DNS entry for autodiscover.inframan.nl, but instead of assigning it an IP address create a CNAME record and point it to autodiscoverredirect.exchange14.nl

image

When testing with the Remote Connectivity Analyzer (http://www.testexchangeconnectivity.com) with a username called John Doe (john@inframan.nl) you’ll see the the autodiscover request originally destined for autodiscover.inframan.nl is redirected to autodiscover.exchange14.nl and the correct results are returned.

image

SRV Records in DNS

Instead of using the HTTP redirect option as described earlier it is also possible to use service records (SRV records) in the public DNS to access the autodiscover virtual directory when using another primary SMTP address.

Looking at the test environment there’s still a UC certificate on the Client Access Server with the FQDN’s webmail.exchange14.nl and autodiscover.exchange14.nl.

But instead of using an additional autodiscover entry in the SAN field of the certificate or creating an additional autodiscover redirect website it is also possible to use a service record. In this scenario, a service record in for inframan.nl needs to be created, pointing to the autodiscover FQDN for the original domain. This service record will be _autodiscover._tcp.inframan.nl and it points to autodiscover.exchange14.nl on port 443.

Entering the SRV record in public DNS can be a bit difficult, depending on the hosting provider you are using. In my case it is something like this:

image

When using NSLOOKUP (on the client) to check the SRV entry you’ll see that it looks good:

image

Now when checking with the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) you’ll see that the autodiscover redirect options fails, but that the SRV option succeeds:

image

It is even more interesting, instead of using the autodiscover.exchange14.nl it is now possible to use the webmail.exchange14.nl FQDN in the SRV record. This way autodiscover no longer uses the autodiscover.exchange14.nl entry and it is now possible to use a standard SSL certificate and NOT a Unified Communications certificate. This standard certificate only contains the name webmail.exchange14.nl.

image

And testing with the Remote Connectivity Analyzer:

image

More information regarding the SRV option with autodiscover can be found on the Microsoft website: http://support.microsoft.com/kb/940881