This post is an excerpt from the Exchange Server 2003 to 2010 Migration Guide.
We are approaching the stage of the migration project where the Exchange 2010 servers begin to perform production roles, such as message routing, remote access, and hosting mailboxes.
This period is referred to as the “co-existence” period.
For some organizations a co-existence period is not necessary, because they are small enough that 100% of the services and data on Exchange 2003 can be migrated across to Exchange 2010 within a single outage window.
For example a small business with just a few dozen, small mailboxes could perform the entire migration in a single weekend with no business hours impact. Such organizations can skip the co-existence phase if they wish to, which reduces the amount of configuration work required.
However for the rest of us a co-existence period is required, which means there are some necessary configurations to put in place first before any production services or data are migrated to Exchange 2010.
Establishing the Legacy Namespace
The legacy namespace is the name that will be used by Exchange 2003 mailbox users to access Outlook Web Access after the remote access namespace is transitioned to the internet-facing Exchange 2010 Client Access server.
What this means is that Outlook Web Access/App connections are first made to the Client Access server. Exchange 2010 mailbox users are proxied as normal to the appropriate Mailbox server. However Exchange 2003 mailbox users are redirected to the legacy namespace instead.
Some people find the legacy namespace to be a confusing topic. In effect the legacy namespace is simply another DNS name, published with ISA Server or another firewall, that legacy (Exchange 2003) mailbox users are redirected to for Outlook Web Access.
Creating the Legacy DNS Record
The legacy name can be anything you like however the name that is commonly chosen is simply “legacy”, or in this example scenario “legacy.exchangeserverpro.net”.
This legacy name should be included in your Exchange 2010 SSL certificate when it is provisioned.
Create a DNS record for the legacy name in your public DNS zone. If you are using split DNS you should also create the record in your internal DNS zone.
The public IP address that the DNS record is created for can be the same as the public IP address of your primary remote access name (e.g. mail.exchangeserverpro.net) if you are using ISA Server 2006 to publish Exchange remote access. ISA Server is capable of publishing the different names to different internal servers using the same web listener.
If you are using a different firewall or a simple NAT router then you may need to configure the legacy namespace on a separate public IP address.
Tip: If you are using split DNS take a look at how your existing OWA public name is configured in your internal DNS zone. If it uses the public IP then do the same with your legacy name, however if it uses the internal IP then you should configure the legacy name to the internal IP as well for the internal DNS zone.
Configuring the OWA Virtual Directory for Legacy Redirection
The OWA Virtual Directory on the internet-facing Client Access server must be configured with the legacy URL to redirect users to.
Open the Exchange Management Shell and run the Set-OWAVirtualDirectory cmdlet with the following parameters:
- -Identity is the name of the OWA Virtual Directory being modified
- -Exchange2003URL is the legacy URL to redirect Exchange 2003 mailbox users to
Set-OwaVirtualDirectory -Identity "esp-ho-ex2010aowa (Default Web Site)" -Exchange2003Url https://legacy.exchangeserverpro.net/exchange
Assigning the SSL Certificate to Exchange Server 2003
The Exchange 2003 front end server needs to be configured with the new SAN certificate that was provisioned for Exchange 2010. This is so that remote access connections to the legacy namespace can occur over SSL without any certificate errors or warnings.
To export the certificate from Exchange Server 2010 launch the Exchange Management Shell and run the following commands.
First determine the thumbprint of the SAN certificate that is installed.
Get-ExchangeCertificate Thumbprint Services Subject ---------- -------- ------- 4DE8E0AC4ECB09623645842752FAA80C4160BF0B ...WS. CN=mail.exchangeserverpro.net, OU=IT Department, O=Exchange Ser... F539B9045F765F9F0DFDE1EA9CB4BACAAE2C6C54 IP..S. CN=esp-ho-ex2010a
In this example the thumbprint is “4DE8E0AC4ECB09623645842752FAA80C4160BF0B”.
Next export the certificate to a file by running the following command. Note this is a single-line command.
$file = Export-ExchangeCertificate -Thumbprint 4DE8E0AC4ECB09623645842752FAA80C4160BF0B -BinaryEncoded:$true -Password (Get-Credential).password
A popup dialog appears for you to enter a password to protect the private key. The username field is not important but requires something to be entered in it for the dialog to accept, so just enter “username” and then a strong password.
Next run the following command to generate the file.
Set-Content -Path "C:Adminex2010cert.pfx" -Value $file.FileData -Encoding Byte
Open Windows Explorer and look at the location you specified as the –Path parameter in the above command, and you will now see the exported certificate.
Copy the file to the Exchange Server 2003 front end server.
On the Exchange 2003 front end server launch mmc.exe and add the Certificates snap-in to the console, choosing the Computer account context.
Choose Local Computer and then click Finish, Close, and OK to return to the console.
Right-click Personal and choose All Tasks -> Import. Step through the Certificate Import Wizard choosing the certificate file that was copied from the Exchange Server 2010 server.
Enter the password that you used when the certificate was exported from Exchange Server 2010.
Place the certificate in the Personal certificate store.
Complete the wizard and confirm that the import was successful.
The imported certificate will now appear alongside the existing SSL certificate on the front end server, if you had one installed already.
The certificate now needs to be added to the HTTPS binding for the IIS website on the Exchange 2003 front end server.
Launch IIS Manager from the Administrative Tools menu of the Exchange 2003 front end server.
Right-click the web site that hosts the Exchange 2003 virtual directories, and then choose Properties.
Select the Directory Security tab and click on Server Certificate.
Click Next to step through the welcome page. Choose Replace the current certificate, and then click Next to continue.
Select the SSL certificate that was imported from the Exchange 2010 server and click Next to continue.
Confirm your selection and then click Next again, and then Finish.
Click OK to apply the close the web site properties dialog box.
You should now test your Exchange 2003 remote access (e.g. Outlook Web Access) to verify that the new certificate is working correctly.