In December 2014, I started my new job as the Director of Computer Services at St. Andrews University (www.sa.edu). They were in the process of re-branding themselves from St. Andrews Presbyterian College to St. Andrews University. Part of this re-branding process included the migration of the web and E-Mail services. The following post chronicles my journey in migrating the Exchange 2013 E-Mail server from hosting only the old domain, sapc.edu, to hosting both domains, sapc.edu and sa.edu, to the final removal of the old domain, sapc.edu, and having only the new domain, sa.edu, left.

I began by doing the normal searches on the net of anyone else who had done this and what errors they ran into. Mostly no help as everyone had 1 error and either no fix or a poor work-around. So, I winged this a bit and fixed the problems properly as they came up.

First thing that needed to be done was to setup the new DNS records for the sa.edu domain. We host our website on a Rackspace cloud server. It gives us an Ubuntu server with Apache and MySQL to host on and does our DNS tables using their spiffy interface. I created the new domain and in the span of an hour so two re-entered the large number of DNS records we had in our old domain listing. After this I created a new Forward Lookup zone in my AD system for the new domain and copied only the required external names that would be used on campus and put in their local/remote IPs.

Once this was done I needed to setup the mail server to accept the new domain. Below are the steps I took to make sure that our new domain, sa.edu, would be accepted.

1. Login to ECP
2. Open Mail Flow -> Accepted Domains, add SA.EDU to accepted list as authoritative

Now I just needed to wait a couple of hours for the outside world to update. The next day I added a new alias to my account only to test getting mail received on the SA.EDU domain. To do this, I followed the below steps.

1. Login to ECP
2. Open Recipients and search for the address to test
3. Click on it and click edit
4. Under the Email Address section click the plus/add sign and enter in the new address [USER]@sa.edu
5. Save

Once it was saved I sent myself a few test mails from my personal Google account. Luckily it tested out fine and I didn’t have any problems. Next I needed to get the webmail working properly. At this point, the system, when browsed to via mail.sa.edu, is giving me terrible SSL warnings. We use GoDaddy as our SSL certificate site. The previous certificate was a normal SSL certificate with about 5 names on it all to address the mail server. To cut costs as a new website was coming and a few other projects would all need SSL certificates as well, I purchased a Wildcard Certificate. This was extremely useful across all systems as it could be imported to each server and we only needed to pay about $250 per year for the certificate. This also turned out to be a point of pain in Exchange. It accepts wildcards, but is not very happy about it. Once uploaded to the server using the steps below, I temporarily enabled it as a test for the new webmail.

1. Login to ECP
2. Open Servers -> Certificates
3. Then click the plus/add button to great a new certificate request. This will work if you want to do either a specific domain or a wildcard. It can later be exported out of Windows and into Linux/Mac systems for services. I generated my request on my Website server and imported into Windows using the Certificates Plug-in in a Windows MMC window.

Just enabling the certificate only for a moment to test cause a few problems. It broke all of my Windows XP clients. None were able to access to mail server on campus locally, even when the certificate was set back to the currently in use one. This resulted in a lot of digging to resolve. After extensive searching on the subject I was forced to call Microsoft and get a tech to help. The article I read on Microsoft’s Technet site did leave off the step to restart the Exchange services by hand, not just a reboot. Reboots did not fix the issue. When the tech finally got into the system, it just turned out he needed to only restart the services manually to fix the problem. Below are the commands used to reset the internal OutlookProvider which fixed the connection issue with my Windows XP clients.

Set-OutlookProvider -Identity exch -CertPrincipalName msstd:mail.sa.edu
Set-OutlookProvider -Identity expr -CertPrincipalName msstd:mail.sa.edu

With that tested, I then worked with my staff to break up the 1,600+ E-Mail accounts into manageable chunks. We then each went one-by-one updating each mailbox’s alias. Now this could be done with a little scripting using the Exchange Management Console, but I’m more of a linux guy when it comes to shell scripting and know almost nothing of the new PowerShell commands.  Next, we needed to do the domain switch. The day where we no longer are known to the outside world as SAPC.EDU but as SA.EDU. Below is my verbatim copied crib sheet I made so that each step would be handled perfectly. When the official change-over day came. We ran the commands and dealt with the fall out.

1. Login to ECP
2. Open Mail Flow -> Accepted Domains, set SA.EDU as default domain
3. Open Mail Flow -> Email Address Policy, change default policy email address format to @sa.edu
4. Open Servers -> Servers, edit SAPC-MAIL02 -> Outlook Anywhere settings. Set both to mail.sa.edu
5. Open Servers -> Certificates, set SA.EDU Wildcard as the cert for SMTP and IIS
6. System will kick you and you will get no access to ECP until you restart IIS services. Localhost connection only.

Now step 5 of the above is where my heart dropped. Immediately upon setting the certificate I was kicked out of all ECP windows and could not access them at all. As stated in step 6, the resolution was to simply manually restart the IIS services. When I came in the next day, again we had broken ALL Windows XP clients. A fast fix for this was to run the below command. It turns off SSL on the internal clients and is was a very useful quick fix.

Set-OutlookAnywhere -Identity "SAPC-MAIL02\Rpc (Default Web Site)" 
    -InternalHostname mail.sa.edu -InternalClientsRequireSSL $false

This also resulted in my clients not being as secure as I’d like for them to be. So digging through my list of notes I had made during the project and reading a few sites on why Wildcard certificates didn’t work right with Exchange, it came back to running these commands to force a specific name for the Wildcard to use. Exchange will not imply this, it must be set explicitly and only from the PowerShell console.

Set-OutlookProvider -Identity exch -CertPrincipalName msstd:mail.sa.edu
Set-OutlookProvider -Identity expr -CertPrincipalName msstd:mail.sa.edu

Once that was done I was able to re-enable SSL internally.

Set-OutlookAnywhere -Identity "SAPC-MAIL02\Rpc (Default Web Site)" 
    -InternalHostname mail.sa.edu -InternalClientsRequireSSL $true

But, within 48 hours, we had yet again broken more Windows XP clients. After reading many forums and Technet docs, I finally gave in and called Microsoft on this one. As per normal, they said they couldn’t even fix it because it’s Windows XP which is no longer supported, but they eventually decided to help. The TLDR of it is that once we changed the paths to the services using the ECP, we still had to manually set them in the PowerShell console. Below are the commands we ran.

Set-ClientAccessServer -Identity SAPC-MAIL02 -AutoDiscoverServiceInternalURI https://mail.sa.edu/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity “SAPC-MAIL02\EWS (Default Web Site)” -InternalURL https://mail.sa.edu/autodiscover/ews/exchange.asmx

Set-OABVirtualDirectory -Identity “SAPC-MAIL02\oab (Default Web Site)” -InternalURL https://mail.sa.edu/oab

This fixed all my Windows XP clients, after removing their mail account from their local machine and having it setup again using the new autodiscover settings. To ensure Autodiscover worked, I added and additional autodiscover.sa.edu DNS entry to my local AD forward lookup zone.

Currently we have resolved all issues with the exception of one.

I’ve been looking into the error and it seems it is simply an error with IIS but I have yet to be able to resolve it. This message usually pops up once per day around 1pm, I assume when some update process is ran. It does not cause any issues with clients expect for a 1 to 5 minute period starting at 1pm exactly.

I will update this post once I resolve this final mail server migration issue.