Maxim_Kazmin - Fotolia


Exchange 2016 upgrade considerations

Organizations planning an upgrade to Exchange 2013 or Exchange 2016 should focus on five areas to avoid trouble.

It's tough to leave a good thing. Let's face it: Exchange 2010 was a solid release. Not only did it bring native support for public folders but it also had direct Remote Procedure Call connections with the option of HTTPS, built-in antispam tools and great third-party support for just about anything we wanted -- fax, antivirus and even BlackBerry Enterprise Services.

Unfortunately, Exchange 2010 and the organizations that depend on it are on borrowed time. Microsoft ended mainstream support in early 2015 and extended support is not an option for most of us, so it's time to start planning an Exchange 2016 upgrade -- or a move to Exchange 2013.

There are well-known compatibility and migration issues that can be solved in advance. With good preparation and planning, Exchange administrators can make the upgrade to Exchange 2013 or 2016 practically invisible to end users. If you follow my list of top five items to handle, then the switch should be fairly painless.

5. Load balancing

Load balancing is not an issue for smaller shops but there are specific differences between Exchange 2010 and later versions that need attention, depending on whether you use F5, NetScaler, or some other hardware or software options. Exchange 2013 and 2016 do not support Remote Procedure Call (RPC) Client connections so you will only be supporting HTTPS (443) sessions. The number of network load balancing (NLB) profiles to create is determined by the number of HTTPS virtual IP addresses (VIPS) that are needed, but most vendors have new profiles for Exchange 2013 or 2016 services to make this configuration easier.

Some other key points:

  • Session affinity, or sticky sessions, is no longer required or recommended for newer versions of Exchange. The NLB no longer has to maintain the same client session with the same Exchange server and can change the session based on load or connection status. Selection of the target server can therefore be selected entirely on load or even round-robin.
  • Layer 4 load balancing is no longer required for newer versions of Exchange. This means the NLB solution no longer requires a deep packet inspection and Layer 7 is preferred for most environments. For more information, see this excellent article from at the Microsoft Exchange Team blog. 
  • Creating a duplicate NLB VIPS and application profile will give you more options during the transition. Plus, this allows you to test clients with the host files after standing up new servers without affecting Exchange 2010 users. For example:
    • MAIL.COMPANY.COM could remain the entry for your Exchange 2010 Outlook Anywhere, Address Book and Exchange Web Services (EWS) VIP.
    • EMAIL.COMPANY.COM could be used for your new Exchange 2013 or 2016 Outlook Anywhere, EWS and Address Book VIP.

4. DNS namespaces and certificate planning

What we are really talking about is the names used for Outlook Anywhere (OA), Outlook Web App (OWA), Exchange Control Panel (ECP), ActiveSync (AS), EWS, Offline Address Book (OAB) and Autodiscover. It sounds like a lot but most administrators combine the namespaces for many of these. For example, you may only use two, such as for OA, OWA, ECP, AS, EWS, OAB and possibly even for POP and IMAP, then for Autodiscover.

With good preparation and planning, Exchange administrators can make the upgrade to Exchange 2013 or 2016 practically invisible to end users.

The wrinkle here is if the new Exchange Servers are in the same Active Directory (AD) site, then you will have to inherit these namespaces on the new servers before migrating users. You will need certificates, DNS changes and NLB profiles ready for an overnight change that will affect all clients. The planning for those changes can be done in advance, but you will need to perform an overnight switchover where all HTTPS traffic is changed at once.

Another option that I have used in highly complicated and sensitive environments is to create a new AD site and subnet, and add the new servers and new domain controllers to the site. By doing that, all the administrator needs to change in advance is the Autodiscover, OWA, AS and ECP and optional IMAP and POP records. You can create a new namespace for OA, OAB and EWS. The end result is all Autodiscover, OWA and ECP traffic is affected during the first DNS changeover but OA, EWS and OAB traffic is affected user-by-user when they are moved.

3. Third-party compatibility

An organization that relies heavily on a particular add-on should talk to its vendor as soon as possible to see if it can offer a transition plan. Vendors that provide fax, compliance, e-discovery, mobile synchronization or security services, antivirus, backup and recovery, unified messaging and other services do not always have a clear path to newer versions of Exchange. Not having a vendor transition plan may not be an issue for some organizations, but it has been an absolute show-stopper for others.

The administrator should think about setting up a lab to test the Exchange 2016 upgrade and all Exchange add-ons.

2. Exchange public folders

I have rated public folders so high because I have seen companies struggle with the transition work in this area for more than a year and severely delay the move from Exchange 2010. The process of moving the folders is cumbersome but even more difficult is the effort needed to identify and determine if a folder and its contents can be removed instead of migrated.

I recommend developing a couple of small scripts to see what you have, who owns it and how much there is. Here is one example:

Get-PublicFolder -Identity "\" -Recurse | Get-PublicFolderClientPermission | where{$_.Accessrights -eq "owner"} | export-csv PFOwner.csv

Get-PublicFolder -Identity "\" -Recurse | Get-PublicFolderStatistics | export-csv PFstats.csv

Using the information from the script, work with the users to delete every single public folder if possible. Eliminate as many of them as possible to reduce the complexity of the migration to Exchange 2013 or 2016. There can be migration issues if you are not careful. For file sharing, SharePoint is a far better option.

1. Exchange clients

Client software gets top billing in this list. Exchange 2013 and 2016 do not support direct RPC connections for MAPI so you will have to use Outlook 2007 or newer. Also, make sure the Outlook clients are patched. Here is the short list of supported clients:

  • Outlook 2016
  • Outlook 2013
  • Outlook 2010 SP1 with November 2012 CU
  • Outlook 2007 SP3 with November 2012 CU
  • Entourage 2008 for Mac
  • Outlook 2011 for Mac

There are also new browser requirements for OWA and ECP:

  • Internet Explorer 8 works pretty well and is considered good support from Microsoft.
  • Internet Explorer 9 is a better choice but provides no offline support.
  • Internet Explorer 10 and 11 are the best choices possible with support for all OWA/ECP options.
  • Firefox 17 or later is a great option and provides support for most features.
  • Safari 5.1 or later is an adequate choice and provides support for the OWA light features.
  • Chrome 24 or later is a great choice and provides support for offline access.

Aside from making sure clients are up to date, I recommend making sure existing clients can connect to Exchange 2010 with OA before moving anyone to Exchange 2013 or 2016. If you are not fully deployed with OA, I would spend some time testing -- or even fully deploying OA in the current environment -- to make sure there are no load balancing or certificate problems.

There are other things to consider for an Exchange 2016 upgrade, but these five areas tend to be the most common planning gaps and the biggest hurdles.

Additional information is available

Microsoft offers additional information that can be helpful to prepare for an Exchange 2016 upgrade:

Next Steps

Why organizations should upgrade to Exchange 2013

What to consider before an Exchange 2016 migration

Plan an Exchange 2013 or Exchange 2016 upgrade

Dig Deeper on Exchange Server setup and troubleshooting