If you would like to read the first part in this article series please go to Exchange Autodiscover.
Introduction
In my previous article of this series, I explained the autodiscover functionality in Exchange Server 2010. Having received an overwhelming amount of questions on this first article, I guess its time for a second one, this time taking a closer look at more configuration information.
Security Alert
In the previous article I explained that during installation of the Client Access Server a Service Connection Point (SCP) in created in Active Directory. For every Client Access Server in your Exchange organization an SCP is created in Active Directory. When you have a client with Outlook 2007 or Outlook 2010 that’s a domain member then the client checks the SCP for configuration information.
Using the Exchange Management Console you configure the Client Access Server, or you use the Exchange Management Shell using the following commands.
Set-OWAVirtualDirectory –Identity X2007SRV\OWA (default web site) -ExternalURL https://webmail.inframan.nl/OWA
Set-OABVirtualDirectory –Identity X2007SRV\OAB (default web site) -ExternalURL https://webmail.inframan.nl/OAB
Set-WebServicesVirtualDirectory –Identity X2007SRV\EWS (default web site) -ExternalURL https://webmail.inframan.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity X2007SRV\Microsoft-Server-ActiveSync (default web site) -ExternalURL https://webmail.inframan.nl/Microsoft-Server-ActiveSync
If you are running Exchange Server 2010, this setting is needed as well:
Set-ECPVirtualDirectory –Identity 2010CAS\ECP (default web site) -ExternalURLhttps://webmail.inframan.nl/ECP
Now these are for the External URL. When Outlook connects to the Client Access Server it determines whether it is an internal or an external connection. So we also have to configure the internalURL property. By default the internalURL is configured with the local servername, like https://X2007SRV.e2010.local/OAB, for example.
When you choose not to include the internal server name in the certificate on the Client Access Server you will see an error message like this:
Figure 1: Certificate error message in Outlook 2007 and Outlook 2010 and an Exchange Server 2007 CAS Server
This is caused by the fact that the internal server name is returned from the SCP. The Outlook client tries to access this internal servername using HTTPS (remember it is a web service after all) but the internal name is not in the certificate.
You can solve this by changing the internalURL property with the value of the externalURL. You can do this using the Exchange Management Console and changing the properties of the Client Access Server:
Figure 2: Changing the InternalURL of the Client Access Server (2007 in this example)
You can also use the Exchange Management Shell to change these settings by entering the following commands:
Set-OWAVirtualDirectory –Identity X2007SRV\OWA (default web site) -InternalURL https://webmail.inframan.nl/OWA
Set-OABVirtualDirectory –Identity X2007SRV\OAB (default web site) -InternalURL https://webmail.inframan.nl/OAB
Set-WebServicesVirtualDirectory –Identity X2007SRV\EWS (default web site) -InternalURL https://webmail.inframan.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity X2007SRV\Microsoft-Server-ActiveSync (default web site) -InternalURL https://webmail.inframan.nl/Microsoft-Server-ActiveSync
And again, this setting is only valid for Exchange Server 2010:
Set-ECPVirtualDirectory –Identity 2010CAS\ECP (default web site) -InternalURLhttps://webmail.inframan.nl/ECP
Now the Client Access Server will always use the external URL webmail.inframan.nl, whether the request comes from the internal network or from the outside (the Internet).
Split DNS
How do you prevent internal Outlook clients to connect to the Internet (i.e. webmail.inframan.nl) instead of the internal side of the Client Access Server? Normally webmail.inframan.nl resolves to 83.161.229.15, but internally you want it to resolve to internal address, for example to 10.0.0.207 which is the internal IP address of the Client Access Server.
To accomplish this you have to implement something which is known as ‘split DNS’. Besides the external DNS, you create an internal DNS zone named ‘inframan.nl’ and point the servers to the internal servers. In this case both the webmail.inframan.nl and the autodiscover.inframan.nl are resolved to 10.0.0.207 instead of 83.161.220.15
Figure 3: Split DNS by implementing an additional DNS zone for internal name resolution
So, you have configured everything the way you want it to be, but still you get this error message as shown in Figure 1. It is a certificate warning, so you can check the IIS Log File on the Client Access Server. Outlook 2007/2010 checks the autodiscover configuration every 15 minutes for changes in the infrastructure. And again you have the InternalURL property. But this time it’s not on the Autodiscover Virtual Directory. When you check the Autodiscover Virtual Directory details you’ll see that both the InternalURL as well as the ExternalURL property are empty:
Figure 4
Changing these properties doesn’t have the desired effect. For changing the internalURL settings you have to modify the Client Access Server properties. Enter the following command in an Exchange Management Shell:
Get-ClientAccessServer –Identity X2007SRV | Set-ClientAccessServer
–AutodiscoverServiceInternalUrihttps://autodiscover.inframan.nl/autodiscover/autodiscover.xml
Everything should be fine now.
CAS Array
And what role does the CAS Array play in the Autodiscover story? The CAS Array is implemented when you have multiple Client Access Servers in a load balanced scenario. Outlook clients connect to a Client Access Server instead of a Mailbox Server for retrieving Mailbox information. This is achieved using the RPC protocol and not using the HTTPS protocol. Think about Outlook 2003 which doesn’t use HTTPS at all. The CAS Array is also used as a ‘backlink’ from the Mailbox Databases to the Client Access Servers. Mailbox Databases have a RPCClientAccessServer property which links a Mailbox Database to a CAS Server. This is also based on the RPC protocol.
The first step is to create a NLB cluster on your Client Access Server and give the cluster a name, for example nlb.labs.local. If you are using Client Access Servers running on Hyper-V (or VMWare) you have to be aware of the MAC address issue. Hyper-V has a range of MAC addresses being used by Virtual Machine. When you create an NLB cluster a random MAC address for the NLB address is generated, and this MAC address is not recognized by the Hyper-V Servers. More information on how to configure this can be found in Microsoft knowledge base article 953828.
Now you can add the CAS Array to the Exchange configuration, and the only option is to use the Exchange Management Shell. Enter the following command:
New-ClientAccessArray -FQDN webmail.inframan.nl -Name CAS_Arrary
The CAS Array will be added to the Exchange configuration, and it Fully Qualified Domain Name is “webmail.inframan.nl”. Your Outlook clients can now use “webmail.inframan.nl” as the Exchange Server using RPC.
Newly created Mailbox Databases will use the CAS Array as the RPC Proxy, but existing Mailbox Database will use the individual Client Access Servers as the RPC Proxy. To change the –RPCClientAccessServer property on all Mailbox Database in one time, open the Exchange Management Shell and enter the following command:
Get-MailboxDatabase | Set-MailboxDatabase –RPCClientAccessServer “webmail.inframan.nl”
Certificates
A lot of questions are also related to the certificates that need to be used on the Client Access Server. The best option (in my opinion) is to use a Unified Communications certificate from a third party vendor. These are listed in the Microsoft knowledge base article 929395. In Exchange Server 2010 it is also supported to use a wildcard certificate. When you use a 3rd party vendor that’s not listed in the knowledge base article it will probably still work. For cheaper certificates there’s a risk however you’ll run into issues with older versions of Windows Mobile for example.
You can also implement your own Certificate Authority, especially the Windows 2008 PKI works very well. This only works fine on domain joined clients. If you have clients that are not domain joined you have to add the CA’s root certificate in the certificate store of the client. This is true for both Windows clients as well as Windows Mobile clients.
Conclusion
For the autodiscover functionality to work properly these points are important:
- Both the internalURL and externalURL need to point to your Client Access Server, preferably to the external name since this one is in your certificate;
- If you have the internalURL and externalURL pointing to the same external name you have to implement split DNS;
- To make the configuration less complex, use the same name for the CAS Array;
- Use a 3rd party Unified Communications certificate or your own (Windows 2008 PKI) certificate.
If you would like to read the first part in this article series please go to Exchange Autodiscover.
