Get started Bring yourself up to speed with our introductory content.

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 webmail.company.com for OA, OWA, ECP, AS, EWS, OAB and possibly even for POP and IMAP, then autodiscover.company.com 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

This was last published in May 2016

Dig Deeper on Exchange Server Deployment and Migration Advice

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

7 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which area of concern most affects your organization's decision to upgrade to Exchange 2013 or 2016?
Cancel
In load balancing you mention that L7 load balancing is no longer recommended for Exchange 2016. That is completely opposite of what Microsoft Exchange team recommends per Reference Architecture, which states L7 isn't required but is highly recommended for Exchange 2016 to leverage managed availability information.
Cancel
Thank you for finding that. You are absolutely correct and I made a typo in the article and we are changing it immediately. I meant to say Layer 4 is no longer needed. In other words, the LB vendor no longer needs to look deep in the packet (up to Layer 4) to inspect the nature of the request.
Cancel
Thanks Stephen. In your comment, you mean Layer 7 and not Layer 4, I assume?
Cancel
Which, BTW, is still incorrect! For Exchange 2016, it is highly recommended to use L7 to benefit from managed availability and maximizing resource consumption on servers.

Your following bullet in section 5 is misleading IMO:
"Layer 7 load balancing is no longer required or recommended for newer versions of Exchange. This means the NLB solution no longer requires a deep packet inspection."
Cancel
We've adjusted the article. Thank you!
Cancel
Thanks again! We are going to make one more edit to make sure we are 100% clear and I'm putting a reference link to the Exchange Team's article for further reading. The take away is Layer 4 is not required and Layer 7 is preferred.
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close