Community Pick: Many members of our community have endorsed this article.

Exchange Autodiscover and Web Services (OOF and OAB)

endital1097Customer Engineer
Published:
One of the most commonly seen question/issue around Exchange 2007 and 2010 is the AutoDiscover service and the Exchange Web Services. These two components of Exchange must be configured properly, otherwise many features within Outlook 2007 or later clients will not function properly (Out of office, free/busy information, etc). The goal of this article is to give you a better understanding of how to design and configure Exchange for your environment. It is not possible to cover every possible scenario, but this should provide a baseline for your decisions.

The most critical piece of deploying Exchange is DNS. I know you’ve heard a countless number of times how important DNS is for deploying Microsoft products, but it is the truth. Without knowledge of how your DNS zones are configured both internally and externally, you cannot successfully deploy Exchange. You must decide what FQDN(s) your Exchange environment utilizes based on the DNS configuration. You must decide upon the URL(s) that your environment will utilize so that you can request the proper certificate for your Client Access Server.

Before we begin looking at possible design configurations, let’s quickly review how these two features are integrated and why DNS is so important:

When the Outlook client is started it will query for a service connection point for the AutoDiscover service. The AutoDiscover service will provide the Outlook client with the URL values for the Exchange Web Services. These web service URL values provide the Outlook client access to the Out of Office scheduler, Offline Address Book download, and free/busy information.

Internally the client randomly select this SCP within the Configuration container in Active Directory
(CN=Configuration,CN=Services,CN=Microsoft Exchange,CN=ExOrgName,CN=Administrative Groups,CN=Exchange Administrative Group,CN=Servers,CN=ExServerName,CN=Protocols,CN=Autodiscover).

This piece is important when you have CAS servers in multiple Active Directory sites. You do have some control into which SCP is used by setting the AutoDiscoverSiteScope value for the CAS server. Clients within the site specified by the AutoDiscoverSiteScope will default to using one or more of those SCPs. (Note: When all CAS servers are configured with the same URL the AutoDiscoverSiteScope value becomes dependent on your DNS configuration).

Right now you might be thinking “what is this service connection point” and “how do you configure it”. The SCP is the AutoDiscover URL for the Client Access Server. The default value for this URL is https://servername.contoso.com/Autodiscover/Autodiscover.xml. You can modify this default value by using the Set-ClientAccessServer -AutoDiscoverServiceInternalURI.

The Outlook client’s behavior is different when it is located outside the local network. In this scenario it will attempt to contact the AutoDiscover service by using the URLs https://contoso.com/Autodiscover/Autodiscover.xml and https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml.

Let’s look at the possible DNS configurations that you may encounter and how you can deploy the Autodiscover service accordingly.

External DNS = Internal DNS
In this configuration both your external DNS server(s) and internal DNS server(s) have a forward lookup zone for your domain (contoso.com). This does not mean that your Active Directory domain name matches your public domain name. It simply means your internal DNS server contains a forward lookup zone that matches your public domain name. Typically the external DNS server contains only records for external resources and the internal DNS server contains records for both internal and external resources. There are a couple deployment scenarios with this DNS setup and they are dependent on the type of certificate you choose to obtain.

Single name certificate (mail.contoso.com)
Yes, you can use a single name certificate with Exchange 2007/2010.  In this deployment you utilize a single URL for the entire Exchange configuration. Your users will utilize this URL for Outlook Web Access/App (internally and externally) and for ActiveSync. This scenario utilizes either:

1.  An Outlook Anywhere configuration that uses an SSL certificate with redirection
... or ...
2.  If your external DNS server is capable of hosting SRV records you can create an SRV record
     for autodiscover that points to your FQDN of mail.contoso.com (http://support.microsoft.com/kb/940881).

The following example provides the powershell cmdlets that can be used to configure a client access server in this deployment:
##Enable Outlook Anywhere for your CAS server 
                      Enable-OutlookAnywhere EXCAS -ExternalHostname mail.contoso.com -ClientAuthenticationMethod Basic -SSLOffloading:$False 
                      
                      ##Configure the SCP for internal Outlook clients 
                      Set-ClientAccessServer EXCAS –AutoDiscoverServiceInternalUri https://mail.contoso.com/Autodiscover/Autodiscover.xml 
                      
                      ##Configure the offline address book settings 
                      Set-OabVirtualDirectory EXCAS\OAB* -ExternalUrl https://mail.contoso.com/OAB -InternalUrl https://mail.contoso.com/OAB 
                      
                      ##Configure the web services which include OOF and free/busy information 
                      Set-WebServicesVirtualDirectory EXCAS\EWS* -ExternalUrl https://mail.contoso.com/EWS/Exchange.asmx -InternalUrl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True-WindowsAuthentication:$True 
                      
                      ##Configure the unified messaging settings 
                      Set-UMVirtualDirectory EXCAS\Unified* -ExternalUrl https://mail.contoso.com/UnifiedMessaging/Service.asmx -InternalUrl https://mail.contoso.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True -WindowAuthentication:$True 

Open in new window

The DNS configuration for this scenario is shown in the following table:
Hostname                          Record   Internal DNS       External DNS
                      mail.contoso.com                  A        10.1.1.100         66.55.44.33
                      autodiscover.contoso.com          A        10.1.1.200         66.55.44.32
                      _autodiscover._tcp.contoso.com    SRV      mail.contoso.com   mail.contoso.com

Open in new window

Note: The A record is using an SSL certificate with redirection.

SAN certificate (mail.contoso.com and autodiscover.contoso.com)
This deployment is almost exactly the same as the single name certificate scenario. Once again your users will be required to know only a single URL to access their mail. Only the CAS server will utilize a the second subject name for the SCP used by Outlook.  Your SAN certificate can also include the FQDN of your CAS servers which would reduce the number of settings you would need to update.

The following cmdlets can be used to configure a client access server in this deployment:
##Enable Outlook Anywhere for your CAS server 
                      Enable-OutlookAnywhere EXCAS -ExternalHostname mail.contoso.com -ClientAuthenticationMethod Basic -SSLOffloading:$False 
                      
                      ##Configure the SCP for internal Outlook clients 
                      Set-ClientAccessServer EXCAS –AutoDiscoverServiceInternalUri https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml 
                      
                      ##Configure the offline address book settings 
                      Set-OabVirtualDirectory EXCAS\OAB* -ExternalUrl https://mail.contoso.com/OAB -InternalUrl https://mail.contoso.com/OAB 
                      
                      ##Configure the web services which include OOF and free/busy information 
                      Set-WebServicesVirtualDirectory EXCAS\EWS* -ExternalUrl https://mail.contoso.com/EWS/Exchange.asmx -InternalUrl https://mail.contoso.com/EWS/Exchange.asmx -BasicAuthentication:$True-WindowsAuthentication:$True 
                      
                      ##Configure the unified messaging settings 
                      Set-UMVirtualDirectory EXCAS\Unified* -ExternalUrl https://mail.contoso.com/UnifiedMessaging/Service.asmx -InternalUrl https://mail.contoso.com/UnifiedMessaging/Service.asmx -BasicAuthentication:$True -WindowAuthentication:$True 

Open in new window

The DNS configuration for this scenario is shown in the following table:
Hostname                          Record   Internal DNS       External DNS
                      mail.contoso.com                  A        10.1.1.100         66.55.44.33
                      autodiscover.contoso.com          A        10.1.1.100         66.55.44.33
                      cassrv.contoso.com                A        10.1.1.100         N/A

Open in new window

External DNS <> Internal DNS
In this configuration your external DNS server is configured with a forward lookup zone for your public domain name (contoso.com) and your internal DNS server is configured with a forward lookup zone for your internal domain name (contoso.local). With this type of DNS configuration you only have one option (without the use of a reverse proxy such as Forefront Threat Management Gateway) and that is to use a SAN certificate. The reason you need a SAN certificate is because your DNS requires unique URLs for external and internal access.

At a minimum your certificate will require the following subject names:
    Mail.contoso.com
    Autodiscover.contoso.com
    Mail.contoso.local

Right now you might be looking at the above list and thinking, wait… you forgot autodiscover.contoso.local.  Remember, this is the minimal names required to make this configuration work. You can add autodiscover.contoso.local and values for your CAS servers (excas.contoso.local), but they are not needed and may only add cost to your certificate.

Now that we know what the minimum certificate requirements are, let’s look at the cmdlets for configuring the CAS server:
##Enable Outlook Anywhere for your CAS server 
                      Enable-OutlookAnywhere EXCAS -ExternalHostname mail.contoso.com -ClientAuthenticationMethod Basic -SSLOffloading:$False 
                      
                      ##Configure the SCP for internal Outlook clients 
                      Set-ClientAccessServer EXCAS –AutoDiscoverServiceInternalUri https://mail.contoso.local/Autodiscover/Autodiscover.xml
                      
                      ##Configure the offline address book settings 
                      Set-OabVirtualDirectory EXCAS\OAB* -ExternalUrl https://mail.contoso.com/OAB -InternalUrl https://mail.contoso.local/OAB 
                      
                      ##Configure the web services which include OOF and free/busy information 
                      Set-WebServicesVirtualDirectory EXCAS\EWS* -ExternalUrl https://mail.contoso.com/EWS/Exchange.asmx -InternalUrl https://mail.contoso.local/EWS/Exchange.asmx -BasicAuthentication:$True-WindowsAuthentication:$True 
                      
                      ##Configure the unified messaging settings 
                      Set-UMVirtualDirectory EXCAS\Unified* -ExternalUrl https://mail.contoso.com/UnifiedMessaging/Service.asmx -InternalUrl https://mail.contoso.local/UnifiedMessaging/Service.asmx -BasicAuthentication:$True -WindowAuthentication:$True 

Open in new window

The DNS configuration for this scenario is shown in the following table:
Hostname                          Record   Internal DNS      External DNS
                      mail.contoso.com                  A        N/A               66.55.44.33
                      autodiscover.contoso.com          A        N/A               66.55.44.33
                      mail.contoso.local                A        10.1.1.100        N/A

Open in new window

Internal DNS Only
It is a possible to deploy Exchange for internal access only, but this is not a common scenario. Deployments that meet this DNS design can utilize the same configuration steps as the Single name certificate (External DNS = Internal DNS). This design allows you to deploy an internal certificate authority and acquire your certificate through it. You can create a group policy object that adds your internal CA to the Trusted Root Certificate Authorities for all machines in the domain.

Multiple Domain Names
At this point we have covered the simplest of scenarios where your organization only has one external facing domain name. Now we need to consider environments that have multiple domain names (ex. contoso.com and fabrikam.com). These scenarios must still use the same concepts discussed earlier regarding DNS, then you mist decide what the user experience will be.

In the situation where contoso.com is the parent company and fabrikam.com was an acquisition, you may want all users to utilize a single URL (single-name certificate). Or these might be two unique business units within your organization and you need each business unit to use a separate URL (SAN certificate). In the end it all comes down to how your DNS is configured and what URL(s) you users will use that determine your certificate requirements and your Exchange configuration.

Non-Internet Facing Client Access Server
The last topic we should consider is the configuration on a CAS server that is non-internet facing, or a CAS server that cannot be directly accessed via the Internet. The first thing you must note for this type of CAS server is that the ExternalUrl values for the virtual directories will be blank. This is required so that the Internet facing CAS server can proxy the request appropriately. (Note: The owa and ActiveSync virtual directories on the non-Internet facing CAS must have Windows Integrated authentication enabled as well for the proxy to work)

Now we need to determine our certificate needs for this configuration. This is once again determined by the DNS design, but the non-Internet facing CAS server throws a wrench into it. Yes, it isn't that simple, but it isn't that much more complex either. There are two easy solutions:
 
1. Utilize a SAN certificate and include the FQDN of the non-Internet facing server
...or...  
2. Utilize two certificates where the certificate installed on the Internet facing server(s) is from the
    third-pary CA and the other is from an internal CA and only has the FQDN of you non-Internet
    facing CAS server.

Either way, your users could remember a single URL and be directed to the appropriate CAS server.

For more information on Client Access proxy and redirection check out this article by Microsoft. (http://technet.microsoft.com/en-us/library/bb310763.aspx)

Conclusion
It is important to understand how the Outlook client connects to the AutoDiscover service and what URL values Outlook uses for the Web Services. Knowing that allows you to ensure you have the proper DNS configuration for Exchange and the correct domain names associated with your Exchange certificate.  In this article, I provided a few possible deployment scenarios and how you can configure Exchange for each one. These are not the only possible configuration methods, but are basic scenarios that should give you a roadmap to your solution.

Key points to remember:

The ExternalHostname value from Get-OutlookAnywhere is the URL used by the Autodiscover service to autoconfigure an Outlook profile
The AutoDiscoverServiceInternalURI value is the service connection point used by Outlook
External clients will attempt to connect to the Autodiscover service using contoso.com and autodiscover.contoso.com by default
Internal clients should not get any certificate warnings/errors or be prompted for a password when browsing to an InternalURL value for the web services
Please feel free to post comments here and/or ask questions at Experts-Exchange in the Exchange Zone.

For more detailed information on the Autodiscover service please visit the Whitepaper on Microsoft's site (http://technet.microsoft.com/en-us/library/bb332063(EXCHG.80).aspx)
7
16,425 Views
endital1097Customer Engineer

Comments (2)

good articale

Commented:
It is possible to use a single URL as well as a single IP address?  I noticed the DNS for outside and inside are forwarding to 2 different IP addresses.  My situation involves 1 certificate with 1 name but also only have 1 external and internal IP address for my Exchange Server which hosts all roles except unified messaging and Edge Transport.  I have an Edge transport server in the outer perimeter but that as well uses the 1 outside IP address (Cisco helped me with setting up the DMZ for this situation).

I really wanted to execute all of this this weekend but idk if I will have a resolution by then.  

This is an upgrade from 2003 but I am not going to have both running at the same time.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.