This is the second part of a multi-part blog series on transitioning from Exchange 2007 to Exchange 2010. Our transition assumes a short period of co-existence and therefore requires a new Unified Communications (UC) Subject Alternative Name (SAN) Certificate for backwards compatibility with the Exchange 2007 CAS Role. This is new requirement for all Exchange Administrators to plan for because CAS did not exist in Exchange 2003, and so you cannot simply use your old SAN certificate, but instead, you need to create a new one that contains a reference back to the old CAS server so that both the old and new CAS server can coexist.
For example, the Exchange Server Deployment Assistant states “We recommend you procure, import, and enable a Subject Alternative Name (SAN) certificate that contains the names for the current namespace, a legacy namespace, and the Autodiscover namespace.”
I had to read that about three times. A legacy namespace, what do you mean? For example, legacy.contoso.com. “This name is used to maintain Internet access to an older version of Exchange while you transition to Exchange 2010. This is necessary during transition because some Exchange services (for example, Outlook Web App, Exchange ActiveSync, and services that send configuration information through Autodiscover) tell clients to connect directly with the old Exchange servers if they see requests to access a mailbox on an older version of Exchange.” For a more detailed explanation about planning the CAS transition, read about it on the Microsoft Exchange Team blog here.
So you will need to plan on changing DNS to support the new alias legacy.contoso.com (or whatever you want to call it in your organization,ex: legacyowa.mycorp.com). I think it is worth pointing out that you only need this Subject Alternative Name for the length of time that you intend to keep your Exchange 2007 environment around, and because the end user never has to interact with it, you can go ahead and safely choose a name such as legacy or legacyowa to keep things simple. Your coworkers will only ridicule you if you try to buy a SAN cert with contoso in the name somewhere =) Other organizations have gone ahead and selected a name like ‘mail’ if they were using webmail, or owa if they were previously using mail.
So the UC SAN Certificate needs to be requested for mail.contoso.com, legacy.contoso.com, autodiscover.contoso.com, the root domain, ex: contoso.com (The root domain is used by the Hub/Transport role for email encryption with internet smtp servers) *and* the internal fqdn hostname of the CAS server. While this Technet article states that it is best practice is to avoid having the internal server names added to the UC SAN Certificate, in reality you need to have the internal FQDN hostnames of your CAS servers in the SAN otherwise internal users will get prompted about a certificate mismatch error every time they launch Outlook.
Also, it is best practice to make the common name the one used by OWA so that Outlook on Windows XP and older mobile phones do not have issues. This is because the Windows RPC over HTTP component used for Outlook Anywhere requires that the SAN or common name of the certificate must match the Certificate Principal Name configured for Outlook Anywhere. Outlook 2007 and later versions use Autodiscover to obtain this Certificate Principal Name, so they do not have this problem. So if you have older clients in your environment, you would need to configure this value on your Exchange 2010 Client Access server, by using the Set-OutlookProvider command with the -CertPrincipalName parameter. Set this parameter to the external host name that older Outlook clients use to connect to Outlook Anywhere, ex: webmail.contoso.com.
There are three steps to adding certificates to your Client Access server(s):
1. If you don't already have a digital certificate, you can use the Certificate Request Wizard in Exchange 2010 to generate a certificate request file, which you can then submit to your selected Certification Authority.
From an ease of use perspective, this wizard is a welcome improvement over Exchange 2007, which only offered the powershell commands to work with certificates.
Here is a link to a video walkthrough of this new wizard in Exchange 2010.
The most important thing you can do in this first step is to make sure that you right-click on the CAS server and not the Mailbox server when selecting ‘New Exchange Certificate.’ This will insure that when you go to complete the request later that you can bind it to the CAS server.
2. After you have the digital certificate from your Certification Authority, you then complete the certificate request process by importing the certificate into your Client Access server.
A note about selecting Certificate Authorities. Not all Certificate Authorities are created equal when it comes to mobile devices in particular. If you need to make sure that Windows Mobile devices trust the certificate that you purchase, make sure you purchase it from a company listed in MS KB 915840. Ironically, if you were to purchase a certificate from Digicert, it would not be trusted by Windows Mobile 5 even though they are listed as a UC SAN certified partner in MS KB 929395. We ended up purchasing our SSL Certificate from Thawte and during the automated order confirmation process, they attempt to call your number in addition to the main number of the company, and you are prompted to enter a code into the phone that is displayed on their web page. I found that it would not work on IE 8 (Windows 7) so I had to launch up a Windows XP Mode virtual machine with IE6 to complete the authorization process, otherwise the confirmation code I was asked to enter would not render in the IE window.
Follow the questions in the wizard to come up with your CSR file that you will use to submit to the Certificate Authority.
3. After the certificate has been imported, you assign one or more client access services to it.
You can now enable Outlook Anywhere
There is a warning that will appear that the configuration will become active in 15 minutes.
Now it is time to set the Offline Address Book URL in powershell. I set both the internal and external URLs because my UC SAN certificate does not have the internal host name of the CAS server in the SAN attribute.
set-oabvirtualdirectory -Identity "CATINEXC05\OAB (Default Web Site)" -InternalUrl:https://webmail.catapultsystems.com
set-oabvirtualdirectory -Identity "CATINEXC05\OAB (Default Web Site)" -ExternalUrl:https://webmail.catapultsystems.com
It is then on to setting the Web Services virtual directory URL in powershell. Again, I set both internal and external URLs to the same name as my owa common name in the certificate.
Set-WebServicesVirtualDirectory -Identity "CATINEXC05\EWS (Default Web Site)" -ExternalUrl http
s://webmail.catapultsystems.com/ews/exchange.asmx -BasicAuthentication:$true
Set-WebServicesVirtualDirectory -Identity "CATINEXC05\EWS (Default Web Site)" -InternalUrl http
s://webmail.catapultsystems.com/ews/exchange.asmx -BasicAuthentication:$true
Now comes the work. You need to do a role swap between the legacy CAS (2007) and the new CAS (2010). This is implied by the Exchange Server Deployment Assistant. The benefit of this approach is that your users do not need to learn a new URL for OWA or their Activesync devices.
In our environment, we use split dns (two zones for the same domain, one to be used by the internal network, the other used by the external network).
Up until this point, everything has been performed during business hours without the possibility of a service interruption. The following steps were performed after hours to reduce impact to our end users.
Step 1 – Update DNS
Hostname: webmail.catapultsystems.com
internal dns zone has an A record with an IP address of the old Exchange 2007 CAS Server: 172.16.83.31 - change the DNS alias to the IP address of the new Exchange 2010 CAS Server: 172.16.83.62
external dns zone has an A record with 65.44.71.85. (This A record will remain unchanged, we will simply update the Firewall NAT rule to point to the new Exchange 2010 server in the next step).
Hostname: legacy.catapultsystems.com (the two internal and external records that follow can be created during business hours and even tested with a local host file)
internally points to the IP address of the old Exchange 2007 CAS Server: 172.16.83.31
externally points to an IP address 65.44.71.10 that NATS port 443 to the old Exchange 2007 CAS Server.
Hostname: autodiscover.catapultsystems.com
internally routes to 172.16.83.36 - change the DNS alias to the IP address of the new Exchange 2010 CAS Server: 172.16.83.62
externally routes to 65.44.71.84 - (This A record will remain unchanged, we will simply update the Firewall NAT rule to point to the new Exchange 2010 server in the next step).
After you update DNS, you can force replication on a domain controller with the repadmin /syncall /APed command.
Step 2 – Update Firewall NAT Rules
Hostname: webmail.catapultsystems.com
65.44.71.85 NAT rule for 80 and 443 will need to be changed to point to 172.16.83.62 instead of 172.16.83.31
Hostname: legacy.catapultsystems.com
65.44.71.10 NATS 80,443 and Secure IMAP to 172.16.83.31
Hostname: autodiscover.catapultsystems.com
65.44.71.84 NATS 80,443 to 172.16.83.36 (change to 172.16.83.62)
Step 3 – SSL
Now that DNS and NAT have been taken care of for the role swap, the next step is to apply the new UC SAN certificate containing the new legacy namespace to the old Exchange 2007 Server so that it can respond to client traffic.
1. Apply the UC SAN cert to the Exchange 2007 CAS server so that it can encrypt traffic
2. Update the Exchange EWS/OAB/Virtul Directories to use legacy.catapultsystems.com
I did not have to perform an IIS Reset in my environment.
Step 4 – SPN
Kerberos uses Service Principal Names for authenticating end-users, so you’ll need to role-swap those too, similar to how you had to update DNS. So before we do that, let’s take a look at what the SPN records look like before we make any changes:
setspn -L catinexc02 (This is the 2007 CAS server)
Registered ServicePrincipalNames for CN=CATINEXC02...
WSMAN/catinexc02.catapultsystems.com
WSMAN/catinexc02
HTTP/webmail.catapultsystems.com
HOST/webmail.catapultsystems.com
HOST/autodiscover.catapultsystems.com
HOST/autodiscover
HTTP/autodiscover.catapultsystems.com
POP3/CATINEXC02
POP3/catinexc02.catapultsystems.com
IMAP/catinexc02.catapultsystems.com
IMAP/CATINEXC02
IMAP4/catinexc02.catapultsystems.com
IMAP4/CATINEXC02
HOST/CATINEXC02
HOST/catinexc02.catapultsystems.com
setspn -L catinexc05 (This is the 2010 CAS server)
Registered ServicePrincipalNames for CN=CATINEXC05...
ExchangeMDB/CATINEXC05.catapultsystems.com
ExchangeMDB/CATINEXC05
exchangeAB/CATINEXC05.catapultsystems.com
exchangeAB/CATINEXC05
exchangeRFR/CATINEXC05.catapultsystems.com
exchangeRFR/CATINEXC05
WSMAN/CATINEXC05
WSMAN/CATINEXC05.catapultsystems.com
TERMSRV/CATINEXC05
TERMSRV/CATINEXC05.catapultsystems.com
RestrictedKrbHost/CATINEXC05
HOST/CATINEXC05
RestrictedKrbHost/CATINEXC05.catapultsystems.com
HOST/CATINEXC05.catapultsystems.com
Run these commands from cmd prompt to perform the role swap:
setspn -D HOST/webmail.catapultsystems.com catinexc02
setspn -D HTTP/webmail.catapultsystems.com catinexc02
setspn -D HOST/autodiscover.catapultsystems.com catinexc02
setspn -D HOST/autodiscover catinexc02
setspn -D HTTP/autodiscover.catapultsystems.com catinexc02
setspn -A HOST/legacy.catapultsystems.com catinexc02
setspn -A HTTP/legacy.catapultsystems.com catinexc02
setspn -A HOST/webmail.catapultsystems.com catinexc05
setspn -A HTTP/webmail.catapultsystems.com catinexc05
setspn -A HOST/autodiscover.catapultsystems.com catinexc05
setspn -A HOST/autodiscover catinexc05
setspn -A HTTP/autodiscover.catapultsystems.com catinexc05
Now let’s take a look at the after changes:
setspn -L catinexc02
Registered ServicePrincipalNames for CN=CATINEXC02...
HTTP/legacy.catapultsystems.com
HOST/legacy.catapultsystems.com
WSMAN/catinexc02
WSMAN/catinexc02.catapultsystems.com
POP3/catinexc02.catapultsystems.com
POP3/CATINEXC02
IMAP4/CATINEXC02
IMAP4/catinexc02.catapultsystems.com
IMAP/catinexc02.catapultsystems.com
IMAP/CATINEXC02
HOST/CATINEXC02
HOST/catinexc02.catapultsystems.com
setspn -L catinexc05
Registered ServicePrincipalNames for CN=CATINEXC05...
HTTP/autodiscover.catapultsystems.com
HOST/autodiscover
HOST/autodiscover.catapultsystems.com
HTTP/webmail.catapultsystems.com
HOST/webmail.catapultsystems.com
exchangeRFR/CATINEXC05
exchangeRFR/CATINEXC05.catapultsystems.com
exchangeAB/CATINEXC05
exchangeAB/CATINEXC05.catapultsystems.com
ExchangeMDB/CATINEXC05
ExchangeMDB/CATINEXC05.catapultsystems.com
WSMAN/CATINEXC05.catapultsystems.com
WSMAN/CATINEXC05
TERMSRV/CATINEXC05
TERMSRV/CATINEXC05.catapultsystems.com
RestrictedKrbHost/CATINEXC05
HOST/CATINEXC05
RestrictedKrbHost/CATINEXC05.catapultsystems.com
HOST/CATINEXC05.catapultsystems.com
You can now start testing Outlook and it should connect fine without prompting you for authentication. If Outlook Web App works correctly, it should refer you to the old 2007 CAS Server because your mailboxes have not yet been moved to the Exchange 2010 server and so they must still be served by the 2007 CAS Server. But now that you have it setup in parallel, you can take your time with the mailbox migration.
One of the most useful ways to test is to right-click on the Outlook icon in the notification area of the toolbar and select Test Email-Auto configuration.
You can also use the Exchange Server Remote Connectivity Analyzer to verify connectivity for the legacy namespace.
You'll find ExRCA at: https://www.testexchangeconnectivity.com
If all goes well the Autodiscover should provide your client with an xml file containing the URL of the legacy namespace which by now you have properly setup with the DNS and NAT rules to forward your client to the 2007 CAS Server.
Phase 5- Setup Redirect Web site
The last step is optional. For example, if you are kind to your users and you want to give them a redirection so that they don’t have to type in https and the /owa in the URL, then the easiest way to make that happen is to open IIS Manager on the Exchange 2010 CAS, modify the default website, and click on the error pages and create a 403 redirect to the actual page.
That’s it - the 2010 CAS Server has successfully been positioned in the place of the old CAS server and you can now proceed on to the other steps including installing and configuring the Hub/Transport, Mailbox and UM Roles and then perform the actual mailbox moves.