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
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 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
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
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
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
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
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
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 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 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:
1. The ExternalHostname value from Get-OutlookAnywhere is the URL used by the Autodiscover service to autoconfigure an Outlook profile
2. The AutoDiscoverServiceInternalURI value is the service connection point used by Outlook
3. External clients will attempt to connect to the Autodiscover service using contoso.com and autodiscover.contoso.com by default
4. 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 send any questions, comments and/or suggestions to my email address jim at endital dot com. Thanks.
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)
No comments:
Post a Comment