When I help my customers upgrade their Exchange environments from Exchange 2003 to Exchange 2010, a key element that I focus on is end user impact. If the upgrade is executed correctly, most end users should never know that an upgrade occurred. In fact, in most instances, the only difference end users will notice is that the OWA interface is greatly enhanced. With this in mind, something I always strive for is to make Exchange 2010 upgrades transparent to end users who use the Outlook Client exclusively. This goal can be difficult to achieve especially when customers use various versions of Outlook ranging from Outlook 2003 to Outlook 2010. The concept of a “transparent upgrade” can fall apart quickly when you introduce the first CAS Server into the environment unless you take a few extra steps to prevent end user confusion.
In this scenario, assume you have an Exchange 2003 environment with the following clients in use:
- Outlook 2003
- Outlook 2007
- Outlook 2010
Now let’s assume that you introduce your first Exchange 2010 CAS Server into the environment. All appears well with your installation so you proceed to add the HUB and Mailbox Roles and begin testing connectivity and mail flow between Exchange 2003 and Exchange 2010. No issues arise. Strangely, the next day you receive reports that end users who use Outlook 2010 are receiving a certificate error similar to the following when they open their Outlook 2010 Clients:
No Outlook clients generated this error message until an Exchange 2010 CAS Server was introduced into the environment. What is going on here?
Discussion
This error is being generated because Outlook 2010 Clients are using the Service Connection Point (SCP) stored in Active Directory to find a valid CAS Server to use for Autodiscover and automatic configuration. Using the SCP, Outlook finds a CAS Server, but the CAS Server does not have a valid SSL certificated. The lack of a valid SSL certificate installed on the CAS Server is the ultimate cause of the error message. If the end users click ‘Yes’ the connection is accepted and the error goes away. However, the fact that the error message pops up at all causes end user confusion, and the concept of a “transparent upgrade” is gone. Outlook 2010 clients search for two things in order to automatically configure themselves:
- An SCP stored in Active Directory (this is a URL to an .xml file on a CAS Server)
- An ‘A’ record in DNS called autodiscover.domainname.com (this is an IP address of a CAS Server that Outlook clients use to find the .xml file mentioned above)
Upon finding either item listed above, Outlook 2010 will try to connect to the specified URL and use the .xml file to automatically configure itself. There are a few things to keep in mind to avoid being caught off guard by this behavior:
- Installing an Exchange 2010 SP1 CAS Server automatically creates an SCP entry in Active Directory (Exchange 2007 did not do this)
- Even though Outlook 2010 clients may already be connected to an Exchange 2003 Server, introducing an SCP or creating an autodiscover ‘A’ record changes Outlook 2010’s behavior – even if the user’s mailbox still resides on an Exchange 2003 Mailbox Server
- Even though Outlook 2007 uses SCP or an autodiscover ‘A’ record, Outlook 2007 does not generate the SSL Security Alert listed above if a CAS Server does not have a valid SSL Certificate
Resolution
The easiest way to avoid receiving the SSL Security Alert displayed above is to ensure that a valid SSL Certificate is installed on the CAS Server shortly after it is installed. However, the problem is that the certificate request cannot be generated until Exchange 2010 is installed. (This is because the certificate request must be generated using the Exchange Management Console or the Exchange Management Shell.) After the certificate request is generated, it may take a few days to actually receive and install the certificate. During this window, end users running Outlook 2010 will receive the SSL Security Alert displayed above. The following tips can be used to prevent autodiscover from functioning correctly, which in a roundabout way, disables autodiscover ensuring that Outlook 2010 clients will not display the SSL Security Alert. Until you install a valid SSL certificate on your CAS Server perform the following:
-
Remove the SCP entry in Active Directory. Use a Management Shell command similar to the following:
- Set-ClientAccessServer -Identity “CAS01” -AutoDiscoverServiceInternalUri $NULL
- Repeat the command above changing the -Identity parameter for each CAS Server installed in the environment
- Do not create an autodiscover ‘A’ record in DNS
With no SCP defined within Active Directory, and with no autodiscover ‘A’ record, Outlook 2010 will fall back to manual configuration; and no SSL Security Alerts will be seen by end users. After receiving and installing a valid SSL Certificate on all CAS Severs, remember to add an autodiscover ‘A’ record and update the SCP in Active Directory. The following commands will help identify and update SCP information:
-
Show SCP information:
- Get-ClientAccessServer | Select Name, AutoDiscoverServiceInternalUri
-
Update SCP information
- Set-ClientAccessServer -Identity “CAS01” -AutoDiscoverServiceInternalUri https://CAS01.domainname.com/Autodiscover/Autodiscover.xml
