My Experience Migrating to Exchange 2016

If you have ever taken the time to read my blog you would probably know by now that I am the IT director for a mid sized accounting firm in NJ. One project on my docket this year is to migrate from Exchange 2010 to Exchange 2016. This post is just going to be a basic log of what I encountered during my install. If you take the time to read this maybe you can find a useful tip to aid in your migration woes.

Having a small shop and wearing a lot of hats here in the office tends to create a slew of challenges. Most of the time I have a ton of projects brewing so focusing on one can be difficult at times. My migration to a new Exchange 2016 server will be gradual taking about 2 to 3 weeks to complete. During the initial setup I like to let certain steps “stew” overnight to make sure there are no disruptions. I also like to be sure I have a contingency plan to undo any unforeseen issues.

Is your directory active enough?

One of the first issues encountered was AD forest level. My AD was still sitting at 2003 and needed to be promoted to at least 2008. Since my oldest domain controller was at 2008R2 I proceeded to push the AD forest to that level. No issues were encountered.

Is the old Exchange server ready to upgrade?

You have to be on at least Exchange 2010 to migrate to 2016 and your existing server needs to be at service pack 3, roll up 11. My server was at SP2, so an after hours patch and reboot brought it up to speed. No issues were encountered. You will need to reboot the old server after this step.

Exchange 2016 Pre-flight checks

The new server already has Windows 2016 on it and my hard drives were provisioned accordingly. Now it was time to do the actual server installation.  When the installer ran the pre-flight checks it determined their were a few items that were necessary for exchange to run that were not already previously installed and it took care of them (or at least pointed me in the proper direction to download and install on my own)

Exchange 2003 Must be gone!

Back in the day we had an Exchange 2003 server and I had migrated everyone and everything to Exchange 2010 (or so I thought) Being the cautious and sometimes lazy IT guy I never fully decommissioned the old 2003 Exchange server, but rather shut down all the services and left the machine in limbo. We were still using that box for Microsoft Office Communicator 2005 (Yes I know its old, but I work for a small company and I have to pick and choose my budget battles).

Now that I want to install Exchange 2016 the installer will not let me proceed until 2003 is gone. I fired up all the old 2003 services and ran the uninstaller on the old server and it failed, claiming a public folder database was still replicating with the 2010 server. I attempted to disconnect the replication and the server told me it would take “several hours”

Several hours later and no JOY! Using ADSI Edit (ADSIEDIT.MSC) I was able to “backdoor” the removal of the old public folder database. ** Side note: be super careful with ADSI edit as you can do some serious damage to your Active Directory.

The next step was to run the Exchange uninstaller again, and guess what. It went about 90% through the process and failed yet again. Since this old server is to be finally decommissioned for good, I went back to the ADSIEDIT and completely removed all traces of the old 2003 server from Active Directory.

We now met all the Pre-Flight   checks for 2016 and the software installed properly

Hello Exchange 2016, Nice to Meet You!

The new server is up and running and to my surprise has already made friends with the existing 2010 server. Remember Exchange 2010 had an application based management console and Exchange 2013 & 2016 have a web based ECP  (Exchange Control Panel). Normally you would access the ECP by going to this URL https://<localhost>/ecp however if you have Exchange 2010 in your environment and have  not moved the admin mailbox you will be directed to the old OWA. to avoid this access the ECP with this URL https://localhost/ecp/?ExchClientVer=15

Do yourself a favor and buy an SSL certificate!

Another issue I ran into was regarding self signed certificates. Yes the encryption is good, probably even better than buying a cert (my theory is if you generate the cert the government can’t get the keys from godaddy, netsol and the like) However, you run into a world of browser popups and iPhone and Android warnings because self signed certificates are not universally trusted! For years I worked around this by publishing my self signed certificates via Active Directory, but this go round I used NAME CHEAP to provide a Comodo SSL certificate for 3 years for $113 <– REALLY CHEAP!

Make sure you purchase enough sub domains to cover your naming conventions, for example

  • <server name>.Domain.Com
  • <webmail address>.Domain.com
  • <smtp name>.Domain.com

On the Exchange server in the ECP, go to servers, certificates and generate a new certificate request. Upload that request to namecheap (or SSL vendor of your liking) Depending on the level of certificate you require it can take minutes to days to vet your company and make sure you are legit.

Once you are deemed worthy, the cert will be sent back to you for import into the exchange server. For your users NOT to see security warnings you need to at least secure IIS and SMTP. If you are using IMAP or POP you may want to secure that as well.

Migrate some mailboxes!

Migration is a simple , but time consuming task. In the ECP click recipients then migration. At this point you will be able to pick your new servers database and move existing users from the old to the new in batches. The new server synchronizes the data and then does a cut over to the new. Users are prompted to restart Outlook if they are using it during the migration time.

Note – the new server had a default mailbox limit of 2GB. The old server had a default mailbox limit of 4GB, so when I first started moving users it failed. You need to set the default on the new server equal or greater than the old.

Note 2 – If you have public folders users will LOOSE access when migrated over. Exchange 2010 uses a public folder database (legacy public folders) where Exchange 2016 uses a public folder mailbox (modern public folders) the technology is not compatible therefore access is lost (however there is an interim workaround that will help you get access back during the migration process)

Note 3 – Active Sync will fail if you are pointed to the old server, but your mailbox lives on the new server. (see below)

Help – Active Sync is no longer active!

Moving mailboxes to the new Exchange server will break Active Sync, but Microsoft has thought of this. You need to point the Active Sync domain to the new server and ALL users will begin working including users that have not been migrated yet. The simplest way to do this in one shot is to change the A record on your DNS. I use a split DNS (internal and External) so I had to change the IP in both (don’t forget or Active Sync will fail once your users leave the office)

Once the DNS is changed to point to the Exchange 2016 server all users regardless of migration status will continue to enjoy Active Sync.

Public folder interim access

As I mentioned earlier the structure of public folders has changed from a Database to Mailbox. The theory behind the change is databases are difficult to replicate across many sites where as a Mailbox is easier to keep in sync with multiple servers across your organization.

I chose to move all my users from Exchange 2010 to 2016 and keep the public folders on the 2010 server until the end of the migration. Microsoft has a great article with information on allowing newly migrated users access to legacy public folders -> Here’s a LINK

Odd migration behavior

A handful of users were having issues with connectivity or Outlook crashing after their mailbox was migrated. On multiple computers, with different versions of Outlook a crash was encountered. Webmail OWA and Active sync were working fine.  The simple fix to get these users working was to bounce IIS with C:\iisrest command on the exchange server.

Public Folder Migration

Once I had completed moving all my user mail it was time to migrate public folders to the new topology. This project should be completed when you have a maintenance window since there will be a time when public folders will be inaccessible.

I used this TechNet  article:

Use serial migration to migrate public folders to Exchange 2013 from previous versions 

For the most part it worked very well. The way it works is by creating a new public folder mailbox or mailboxes based on your organization size and then creates a migration batch to move the data. One word of caution, this will fail if you have improper folder alias names. My server had quite a few and I believe exchange 2003 may have allowed it and 2010 didn’t care. However 2016 will stop if there are illegal characters. Also, if there are illegal charters in mail enabled folders they will be replaced with “?” question marks.

To prove all my efforts worked I dismounted the old database on the legacy exchange server.

To sum things up:

  • Upgrade AD forest to required level
  • Upgrade legacy exchange serve to the required level
  • Remove all 2003 and older exchange servers
  • Install exchange 2016 and all pre-flight required items
  • Point DNS (internal and external) to the new server (for Active Sync)
  • Configure 3rd party SSL
  • Setup a proxy for legacy public folders
  • Migrate mailboxes (don’t forget arbitration mailboxes)
  • Migrate public folders
  • Make sure send / receive connectors are working on new server.
  • Begin decommission of 2010 server

I’m not an expert with regards to Exchange server, however I have been using and maintaining the software since version 5.5. If you have a question give me a shout.

Thank you for reading my blog,
-Joe

 

 

 

Leave a Reply