PREVIOUS: Migrating Exchange from 2003 to 2010 – Part II
In our previous article we sized and built the base for our multi-role Exchange Server. Then we extended our Active Directory Schema.
In this article we will run through the Exchange Setup Program. We will then design and implement our namespace as well as configure split-brain DNS. We will finish by applying a 3rd-party certificate.
Step 4:
Exchange Server Setup
Installing All Roles
First, we will need to install the Microsoft Office 2010 Filter Pack.
This install is just a series of Next button clicks and you are done. There is nothing to configure.
Microsoft Office 2010 Filter Pack Install
The Filter Pack can be downloaded from here:
http://www.microsoft.com/en-us/download/details.aspx?id=17062
Now lets go to our Exchange DVD. If it doesn’t auto-run, click double click SETUP.EXE on the DVD.
Steps 1 & 2 should already be complete. Click Step 3 to expand it.
Select Install all languages from the language bundle. (You can also pick Install Only Languages from the DVD. Whichever one you pick determines how many language options your users will have when they use tools such as Outlook Web App. If you are an international company I recommend the former option.)
Select Download the latest language pack bundle from the Internet and click Next.
Click Finish.
Click Step 4: Install Microsoft Exchange.
Click Next.
Accept the License Agreement and click Next.
Choose whether or not to send error reports to Microsoft. Click Next.
Pick Typical Installation (this installs all roles).
Based on the planning from our last article we are going to put the Exchange Install on the D: drive. Click the Browse button and change the path to the D: drive. In our example, our file path becomes:
D:\PROGRAM FILES\MICROSOFT\EXCHANGE SERVER\V14
Select Automatically install Windows Server roles and features required for Exchange Server.This completes A LOT of busy work for us!
Click Next.
Check The Client Access Server role will be Internet-facing.
Enter the FQDN you plan to use for Exchange Web Services. EWS includes services such as Outlook Web App, ActiveSync and Outlook Anywhere. It doesn’t matter if this is the same URL you currently use for Exchange 2003. We will discuss namespaces a little later. In our example our external namespace is: mail.daleksofskaro.com
Click Next.
Choose whether you want to join the Customer Experience Improvement Program and click Next.
The Exchange Installation will then perform readiness checks. This determines whether or not all prerequisites and requirements have been met. If everything is good, click Install.
The installation will take some time. Now is a good time to refill that coffee cup! If everything completes successfully, click Finish.
Click Ok to reboot.
Step 5:
Name space Design
and Implementation
While we are waiting for our server to reboot let’s discuss name space.
Name space is very important in Exchange 2010. Not only does name space govern services like Outlook Web App, or, ActiveSync, but it also governs items such as the distribution of the Offline Address Book, or, the Autodiscover service.
A correct namespace design is key.
Currently, our Exchange 2003 box is providing Outlook Web Access, ActiveSync and RPC over HTTPS. It uses a name space of mail.daleksofskaro.com.
It is our plan that Exchange 2010 will use that same namespace. We will also have a period of coexistence.
“How can both servers use the same name?”
Well, they can’t.
We will change the name space (and certificate) on the Exchange 2003 server to legacy.daleksofskaro.com.
We will need a new host record for our Autodiscover service. This will be autodiscover.daleksofskaro.com.
We also need to examine our internal name space. During the install process, setup made all our internal URLs the name of our internal server. In our example this is EXCHANGE.SKARO.LOCAL.
Due to recent restrictions, 3rd-party certificate providers can no longer put internal names on certificates. This is actually a good thing! Otherwise, you are exposing the internal host names of your servers to the internet.
However, if our certificate does not match our internal server name it will give our internal users security warnings.
“So how do we combat this?”
Simple. We make our internal URLs match our external URLs.
Then we use split-brain DNS. So mail.daleksofskaro.com matches the internal IP of exchange.skaro.local. That keeps all the traffic on the local LAN. Without the split-brain DNS all local traffic would try to go out the firewall only to try and come back in later. Most firewalls will block this kind of traffic.
Server rebooted?
Okay, let’s change those Internal URLs.
Open the Exchange Management Console.
Expand Microsoft Exchange On-Premises (server name)
Expand Server Configuration
Select Client Access
In the lower-right pane, under the Outlook Web App tab, double click OWA (Default Web Site).
Under the General tab, copy the contents of the External URL and paste over the content in the Internal URL field.
Click Ok.
Repeat steps 6 and 7 for the Exchange Control Panel, Exchange ActiveSync and Offline Address Book Distribution tabs.
Now is a good time to enable Outlook Anywhere. While still on the Server Configuration >> Client Access, right click on name of the server and select Enable Outlook Anywhere from the context menu.
In the External host name field we will enter mail.daleksofskaro.com.
Keep Basic Authentication checked.
Click Enable.
Click Finish.
We also need to make changes to two additional namespaces. Autodiscover and Exchange Web Services (EWS). These are not in the GUI. For this open the Exchange Management Shell and issue the following commands.
Note: Be sure to change EXCHANGE on both these commands to the host name of your internal server.
Set-WebServicesVirtualDirectory -Identity “EXCHANGE\EWS (Default Web Site)” -InternalUrl https://mail.daleksofskaro.com/EWS/Exchange.asmx -BasicAuthentication:$true
To confirm the change.
Get-WebServicesVirtualDirectory | fl identity,internalurl,ExternalURL
And now for Autodiscover.
Set-ClientAccessServer -Identity EXCHANGE –AutoDiscoverServiceInternalUri https://mail.daleksofskaro.com/Autodiscover/Autodiscover.xml
To confirm this change.
Get-ClientAccessServer |fl identity,autodiscoverserviceinternaluri
Split-Brain DNS
Alright, let’s get our split-brain DNS configured next. Our DNS Servers will hold non-authoritative zones for our external name space. This will only be used by our internal users.
On your DNS server open DNS Manager.
Right click on Forward Lookup Zone and select New Zone… from the context menu.
Click Next.
Keep all the default settings. Click Next.
Keep all the default settings. Click Next.
In the Zone Name field enter your public domain name (in our example daleksofskaro.com).
Keep all the default settings. Click Next.
Click Finish.
Expand Forward Lookup Zones.
In the left pane, right-click on daleksofskaro.com zone and select New Host (A or AAAA) from the context menu.
In the Name field type mail. In the IP address field type the internal IP of your Exchange 2010 Server. (In our example it is 10.15.1.49).
Click Add Host
Repeat Steps 10-12 for autodiscover and legacy. However, with regard to legacy, point it to the internal IP of your Exchange 2003 Server.
The end result should look like this.
Note: You will also need to repeat Steps 10-12 for any resources you have on the Internet. For example, if your website is www.daleksofskaro.com, you will need to create a www host A record and point it to the public IP address of your hosting provider.
Now this takes care of our internal name space but we still need to do some more work on the external name space.
First though we need to open some ports on our firewall. For coexistence we will need two public IPs.
Our first public IP will continue to point to our Exchange 2003 server.
Our second public IP will point to our Exchange 2010 server.
We need to open ports 80 (HTTP) and 443 (HTTPS) to our Exchange 2010 server.
This process will vary based on the firewall you have.
Step 6:
Unified Communications
Certificate (UCC / SAN)
Before we cut over our external DNS records to the second public IP we should get our new certificate in order first. It takes time for a certificate request to be processed by a 3rd-party. That time can vary greatly. I have seen some take an hour. I have seen some take days.
One of the greatest improvements in Exchange 2010 was including a brand new Certificate Generation Request wizard in the EMC.
This wizard takes all the guess work out of what kind of certificate you will need to purchase.
Let’s get started.
Open the Exchange Management Console.
Expand Microsoft Exchange On-Premises (server name)
Select Server Configuration
In the far right Action pane, click the link for New Certificate Request…
In the Enter a friendly name field enter you certificate name. In our example we will make this mail.daleksofskaro.com. Click Next.
Do NOT check wildcard. Leave this unchecked and click Next.
This next page will help us determine all the name spaces we need on our new certificate.
Expand Client Access Server (Outlook Web App).
Check Outlook Web App is on the intranet.
Check Outlook Web App is on the internet.
Make sure our external URL is the only address in both Domain name fields. In our case mail.daleksofskaro.com.
Expand Client Access Server (Exchange ActiveSync).
Check Exchange Active Sync is enabled.
Make sure our external URL is the only address in the Domain name field. In our case mail.daleksofskaro.com.
Expand Client Access Server (Web Services, Outlook Anywhere, and Autodiscover):
Check Exchange Web Services is enabled.
Check Outlook Anywhere is enabled.
Make sure our external URL is the only address in the External host name field. In our case mail.daleksofskaro.com.
Check Autodiscover used on the Internet
Check Long URL (Example: autodiscover.contoso.com)
Make sure our autodiscover URL is the only address in the Autodiscover URL to use field. In our case autodiscover.daleksofskaro.com.
Expand Legacy Exchange Server
Check Use legacy domains
Make sure our legacy URL is the only address in the Domain name field. In our case only legacy.daleksofskaro.com.
Click Next.
This should list three Certificate Domains. Make sure mail.daleksofskaro.com is Set as the common name (in bold).
Click Next
Fill out your Organization and Location information.
Click the Browse button and save the Certificate Request file to the Desktop.
Click Next
Click New
Before you click Finish, review the three steps. You will notice in Step 1, it has identified you need a UC certificate. This is also known as a SAN certificate. Click Finish.
This should have created a certificate request file on your desktop. Open this file with Notepad and copy the entire contents, including the BEGIN and END lines.
Now you will need to purchase a UC / SAN certificate from a 3rd party source. There are many out there. But for the best price and quickest turnaround I highly recommend GoDaddy.com.
You can also do a Google search for GoDaddy Promo Codes for additional savings.
Once the certificate has been processed (and you have downloaded and unpacked your ZIP file from GoDaddy) we need to complete the certificate request.
In the lower-right pane, right click on the name of our certificate (mail.daleksofskaro.com) and select Complete Pending Request from the context menu.
Click the Browse button and locate the certificate from GoDaddy.
Click Complete.
Exchange Web Services are still assigned to the self signed certificate. Let’s get these switched over to the 3rd-party certificate.
In the lower-right pane, right click on the name of our certificate (mail.daleksofskaro.com) and select Assign Services to Certificate from the context menu.
Select Internet Information Service (IIS).
Click Assign
Click Finish
Also, be sure to import this certificate on the Exchange 2003 server as well. You do this in IIS Manager. Go to the Properties of the Default Web Site. Then from the Directory Security tab click Server Certificateand do an Import (.pfx) from the wizard.
Now that we have our certificate installed, we need to test to make sure it is working properly.
The easiest way to check is to enter your external URLs (mail.daleksofskaro.com and legacy.daleksofskaro.com) into the web browser of an internal PC.
Make sure you can get to OWA on both servers and that there are no certificate errors.
Also, check from an external source as well, using the public IP address of the 2010 server (for example, https://123.123.123.123/owa). This will generate a certificate error but you should have access.
If all looks good then now is a good time to cut over the external DNS records. Remember that:
mail.daleksofskaro.com will point to the public IP of our 2010 server.
autodiscover.daleksofskaro.com will point to the public IP of our 2010 server.
legacy.daleksofskaro.com will point to the public IP of our 2003 server.
Note: DNS changes can take anywhere from 24-72 hours to propagate through the internet. I always recommend making DNS changes over a weekend, or, during times of low service usage.
Now that we have made these DNS changes we need to set up a forward for Outlook Web App. During coexistence we will have users on both mailbox servers. The DNS changes will direct everyone to the 2010 OWA login page. What this forward does is redirect users still on the 2003 mailbox to legacy.daleksofskaro.com instead.
To execute this forward open the Exchange Management Shell and issue the following command. Replace EXCHANGE with the internal name of your 2010 server.
Set-OWAVirtualDirectory EXCHANGE\OWA -ExternalURL https://mail.daleksofskaro.com/OWA-Exchange2003URL https://legacy.daleksofskaro.com/exchange
Once the DNS propagation completes, retest OWA from a browser using an external source. Use the external URL rather than the public IP this time. Make sure you don’t get any certificate errors.
I highly recommend testing with the Exchange Remote Connectivity Analyzer.
https://testconnectivity.microsoft.com/
Phew!
That was a lot of content for one article. We got a lot of good stuff covered though!
In our next article we will move our databases and logs to their dedicated disks. We will configure Public Folder replication. We will move test users and confirm mail flow to the new server. We will also discuss backing up Exchange 2010 and finally move production users.
NEXT: Migrating Exchange from 2003 to 2010 – Part IV
Signup: Super-Tek-Tips
For more great tips be sure to subscribe to our newsletter. We will never share your email. We hate spam too! (Unless it's fried in a pan - yummy!)
The post Migrating Exchange from 2003 to 2010 – Part III appeared first on SUPER-TEK-BOY.