How to Enable Exchange 2007 Autodiscover in EBS 2008
[Today’s post comes to us courtesy of Shawn Sullivan]
[Updated Content on 7/8/2010]
The Autodiscover service, which allows Outlook 2007 and Windows Mobile 6.1 ActiveSync clients to obtain mailbox connection settings with little user intervention, is not configured by default in EBS 2008. In order to open the Autodiscover service to both internal and external clients, you must follow several steps on both the Messaging and Security servers:
- Configure the correct DNS records that will point external clients to the proper URL for the autodiscover service.
- Install a trusted SSL certificate on the Forefront TMG web listener or distribute the default EBS certificate.
- Create a Web Publishing rule in Forefront TMG to allow the autodiscover requests from your external clients to reach the Messaging server.
- Add the proper internal and external URL parameters to the Autodiscover virtual directory on the Messaging server.
This post will cover each step in detail, covering several common configurations mistakes.
Public DNS and Certificates
In order to know how you should configure your external DNS records for autodiscover, you must understand how Outlook 2007 and Windows Mobile 6.1 clients will attempt to locate it. In the following example, user@contoso.com is creating a new Outlook 2007 SP1 profile from their brand new laptop connected to their home network. Outlook will take the second half of their email address, contoso.com, and do the following:
- Attempt to resolve and connect to https://contoso.com/autodiscover/autodiscover.xml. If it cannot, it will then:
- Attempt to resolve and connect to https://autodiscover.contoso.com/autodiscover/autodiscover.xml . If it cannot, it will then:
- Attempt to resolve the SRV record for _autodisover._tcp.contoso.com and get a hostname in return, such as remote.contoso.com. It will then attempt to resolve and connect to https://remote.contoso.com/autodiscover/autodiscover.xml . If it cannot, then at this point your connection has failed and you would have to configure Outlook Anywhere manually.
For the connection to be successful, the URL that Outlook chooses must be tied to a valid certificate that Outlook trusts with a subject name that matches the URL. To test this, browse either OWA or RWW from your client machine using the Security server’s public URL. If you receive one or all of the following warnings, then Autodiscover will fail on this client (as well as Outlook Anywhere, ActiveSync, and Connect to computer through RWW).
During the Security server setup, you are asked to specify the name of the remote web portal that TMG will use to publish your Exchange virtual directories and Remote Web Workplace.
A certificate is then created by the Enterprise Root CA using this name that you specify as the Subject Name. The certificate is then placed in the External Web Listener in ForeFront TMG (not IIS on the Management server). This configuration can result in a failure on the client for one or more of the following reasons:
- Client machines who are not joined to the domain will not trust this certificate
- You have entered a domain prefix during setup, such as remote. contoso.com, that contradicts the autodiscover ‘A’ record that you have registered publicly. In this case, Outlook resolves autodiscover.contoso.com, connects to your site, and receives certificate error because remote.contoso.com is presented instead.
- An SRV record has not been created which points to the FQDN, including the prefix.
For EBS, we recommend creating an SRV record for your domain. This will require Outlook 2007 SP1 or later to take advantage of the record:
Service |
_autodiscover |
Protocol |
_tcp |
Port |
443 |
Host |
RemoteName (for example, remote.contoso.com) |
In this example, you must have a public ‘A’ record for “remote” that resolves to your Security server’s public IP address.
Internal Clients
[This section is included for reference only. No action is normally needed: Autodiscover works out of the box in EBS.]
All internal Outlook 2007 clients who access the Autodiscover service should be first joined to the domain. Then, instead of using DNS directly, they will query Active Directory for the Service Connection Point object that will return the proper URL:
CN=ServerName,CN=Autodiscover,CN=Protocols,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local
NOTE: The URL will point to your Messaging server’s internal Fully Qualified Domain Name. This will match the Subject Alternative Name of the Exchange certificate installed on the Default Website of the Messaging server. This is why your internal domain clients will not receive a certificate warning when they connect. You do not need to make any changes in your EBS environment for this to work.
Create the Autodiscover Web Publishing Rule
You must manually create a rule to allow Forefront TMG to Web Publish the Autodiscover traffic from external clients to your Messaging server (including traffic to the Offline Address Book and Exchange Web Services directories). Unlike OWA, RWW, and ActiveSync, this is not configured for you by default. Like the other virtual directories that we publish through TMG, the rule that we will create uses SSL bridging to connect the external client to the Autodiscover service; meaning that the client will make one SSL connection to TMG while TMG makes its own SSL connection to the Messaging server. This will utilize the same ports, IP addresses, and certificates that we already have in place.
Open the Forefront TMG console, right-click on Firewall Policy, choose New > Web Site Publishing Rule
Choose Allow for Select Rule Action
Choose Publish a single Web site or load balancer for Publishing Type
Choose Use SSL to connect to the published Web server or server farm. The Messaging server already has an SSL certificate installed on the Default Website that hosts the Autodiscover virtual directory.
For Internal Publishing Details, enter the hostname of the Messaging server. Do not enter the fully qualified domain name.
Enter /autodiscover/* for the website path and check the box for forward the original host header.
For Public Name Details, leave This domain name (type below) selected. Enter the public FQDN that you registered in the Public Name field. Do not change the path.
Click the drop-down menu, select External Web Listener, and click Next.
Select Basic Authentication in the drop-down menu for Authentication Delegation.
Select No delegation, but client may authenticate directly in the drop-down menu for Authentication Delegation.
Accept the default All Authenticated Users selection for User Sets.
Change User Sets to include All Users.
You can ignore the following warning. It simply tells you that you can override this setting at the web listener level to prohibit anonymous users from accessing this site, which we do not want to do here:
Click OK, click Next and then Finish. Right-click on the rule that you just created and choose Properties. Open the Paths tab and add the /oab/* and /ews/* paths.
Click OK and Apply the changes.
On the left pane, click on Monitoring and click on the Configuration tab. Refresh the screen until you see that the status is Synced. Once it is, the rule that you just created is now in place.
Configure the URLs for Autodiscover, OAB, and EWS on Messaging
You must manually assign the proper internal and external URL configuration to the Autodiscover virtual directory on the Messaging server. As mentioned before, both external and internal Outlook 2007 clients use the Autodiscover service, so these URLs must be browsable from their respective network locations. Specify the public FQDN for ExternalURL and the internal FQDN for InternalURL.
For example, your external FQDN is remote.contoso.com and your internal FQDN for the Messaging server is msg.contoso.local. In this case, open the Exchange Management shell and run the following command:
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory –ExternalURL https://remote.contoso.com/autodiscover/autodiscover.xml -InternalURL https://msg.contoso.local/autodiscover/autodiscover.xml
You can verify that the settings are correct by running the command:
Get-AutodiscoverVirtualDirectory | ft *url*
NOTE: Replace the ExternalURL and InternalURL in this command with the actual ones you want to use. Do not copy and paste the command from this blog post into PowerShell.
For the OAB and EWS virtual directories, you will need to populate the ExternalUrl parameters. Using the same domain name from our example above, we would run the following commands:
Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalUrl https://remote.contoso.com/oab Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalUrl https://remote.contoso.com/ews/Exchange.asmx
Comments
Anonymous
January 01, 2003
Michael, There are a couple issues with using wildcard certs, but they are fully supported by Exchange. Check out the following documentation: http://technet.microsoft.com/en-us/library/cc535023.aspx http://support.microsoft.com/kb/948896 (This was fixed in UR 4) Auth delegation for Basic is secure, it is encrypted within the SSL connection. Basic authentication is enabled on the Autodiscover v-dir by default.Anonymous
November 04, 2009
This would of came in handy a couple months ago ;) The first time I had to do this was tricky finding the correct way without messing anything up. I was used to setting it up but never had to set it up along with forefront TMG before. In the few deployments I have done, instead of creating a different web publishing rule, i've just added the autodiscover ews oab folders to the already created "Microsoft Exchange Outlook Anywhere and Terminal services gateway" rule. I had a support call with microsoft one day and the tech said thats what he recommends. Just thought I would add my 2 cents. thanks!Anonymous
November 04, 2009
Yes, I struggled with this for a while and had a support case with EBS team, too. Still, it is a great article: it has very precise instructions and easy to follow. Thank you, Shawn! Keep making out life easier! I have 2 questions:
- In my case, I use a wild card certificate. Should I be doing anything differently? I have seen messages in Firefox warning that remote.mycompany.org site uses an untrusted certificate, *.mycompanyname.org
- About authentication Delegation. Is Basic Secure? Or SSL takes care of encryption? And, to follow the instruction from the wizard, check if the autodiscover has basic authentication enabled? (I did, and it is set up but, may have been during my support case). Thanks in advance!
- Anonymous
November 05, 2009
The comment has been removed