Should You Upgrade a Hybrid Exchange Configuration to Exchange 2016?

A few weeks ago, Microsoft released Exchange 2016 to the public. By now, some of you will have had the chance to play with the latest member in the Exchange Server family and perhaps have formed an opinion on whether it’s something you are willing to consider upgrading to now, or after few more Cumulative Updates have been released.

Earlier this week, I received an email from one of our customers asking me if they should upgrade their existing Exchange 2010 hybrid deployment to Exchange 2016. Although I like Exchange 2016 and it looks like a pretty stable release, the answer is not as straightforward as one might expect.

Those who attended Microsoft’s Ignite conference earlier this year in Chicago might remember the session Timothy Heeney and I presented on Hybrid Exchange deployments. During that session we tackled the same question, albeit for Exchange 2013. The answer we gave back then is pretty much the same as it is now: “It depends.” I do realize this is the typical consultant’s answer, but allow me to elaborate.

Key Considerations to Make Before Upgrading

There are many elements that influence the decision to upgrade to a newer version of Exchange for your hybrid deployment or not. Assuming you already have an Exchange 2010 hybrid deployment, ask yourself this: What is the purpose of your hybrid configuration? If you are using your hybrid server just for management purposes, there is little value in upgrading to Exchange 2016. Other than the fact that Exchange 2016 will give you a nice management interface, you will not gain any new functionality from moving to it.

On the other hand, you should not be blind to the fact that Exchange 2010 is now in extended support and, as Steve Goodman stated earlier, is edging closer to the end of life. So, from a supportability and product lifecycle point of view, it actually does make sense to upgrade to Exchange 2016. This is even more so the case if your on-premises Exchange server(s) are not processing any Exchange-related workloads anymore. This would be the case when all your users are hosted in Office 365 and you have switched your Autodiscover record to point directly to Exchange Online. In such case, upgrading to Exchange 2016 will be a trivial task – one you should consider in my opinion. There’s no rush, though. This is something you can plan to do in the next few weeks or months – whenever best suits you.

If you are running an Exchange 2010 hybrid configuration and you are hosting active mailboxes both on-premises and in Office 365, upgrading to Exchange 2016 will require a little more effort and planning. In fact, you are going through a full on-premises migration before you can “upgrade” the hybrid configuration. From a hybrid connectivity point-of-view, you are not getting any new features by upgrading to Exchange 2016. You’re only substituting your 2010 servers with a new version. Of course, the same supportability and product lifecycle argument applies. The question is whether this really drives your decision at this time. Unless Microsoft changes its support statement and moves an Exchange 2010 hybrid deployment out of the scope of supported topologies, you are not in a rush to upgrade.

The new Exchange 2016 Hybrid Configuration Wizard could be a herald that Microsoft might make that decision in the future, though. One of the reasons Microsoft developed the new “hosted” wizard is to gain more control over the customer experience when it runs the Hybrid Configuration Wizard. It allows the company to decouple the experience from whatever Exchange version you are running. The new wizard allows Microsoft to ensure that you always use the latest bits and get the best possible experience - something that caused some problems in the past. We also know that this new wizard will not be made available for Exchange 2010. As such, it’s not unthinkable that at some point in the (near?) future, the Exchange 2010 Hybrid Configuration Wizard will not be able to finish successfully because of some change Microsoft makes in its datacenters. At the speed with which Microsoft makes updates to Office 365, this is bound to happen sooner than later. Food for thought!

If you are not yet in a hybrid state, but you are looking to configure a hybrid connection, I like to use the following workflow to decide whether or not to upgrade to 2016:

In the end, if you need a long-term coexistence, in my opinion, it is better to go with a newer version of Exchange for your hybrid deployment. If you only want to use hybrid for migration purposes, even if it is for several weeks, it is definitely OK to use Exchange 2010 – provided that your intention is to move all mailboxes to Office 365 and keep the on-premises server(s) for management purposes only. In the latter case, I would even suggest switching Autodiscover and your MX records to Exchange Online after the migration. That puts you in a great spot to easily upgrade your remaining on-premises server(s) to Exchange 2016 with little to no hassle.

If you have made the decision to upgrade to Exchange 2016 for your hybrid deployment, I suggest that you first perform the on-premises migration before setting up hybrid. This might save you some work having to re-run the HCW afterwards and, more importantly, you get to enjoy the new HCW experience from the start.

Another question I regularly hear is whether or not it’s possible to avoid going through a full on-premises migration if you want to use a newer version of Exchange for hybrid migrations. While it is technically possible, I’m not a big fan of doing it that way because there can be some repercussions in the long run. I do understand that upgrading to Exchange 2013 or 2016 from Exchange 2010 will have a significant impact on your users, but that’s just the way it is. If you plan it right, the impact can be dramatically reduced. Moving forward, this automatically becomes less of a problem as Exchange 2013 and Exchange 2016 happily coexist and you can gradually move client traffic over to the newest Exchange version, instead of switching everything over at once.

First of all, when referring to a full on-premises migration in a hybrid scenario, I am more talking about switching the namespace from Exchange 2010 to Exchange 2013/2016 rather than moving mailboxes on-premises. The latter has limited – if any – impact whereas switching the namespace usually does.

If you want to prevent a namespace switchover, you need to introduce a new “hybrid” namespace next to the namespaces that already exist in your environment. For example, if you currently use autodiscover.domain.com and mail.domain.com, the new “hybrid” namespace might be hybrid.domain.com. That namespace is then configured to point to the newest Exchange version in the environment, along with the Autodiscover service. The other preexisting namespace continues to point to the older Exchange version in the environment (which usually is 2007 or 2010).

By doing so, you ‘trick’ Autodiscover into handing out the existing URLs for mailboxes that are hosted on the older Exchange version while you can configure mailbox moves to Office 365 to connect to the new hybrid namespace – this, of course, provided you have configured the URLs on all servers accordingly. While this approach works, there are some severe drawbacks I would like you to be aware of:

1. It’s unsupported. Microsoft does not test this scenario and cannot guarantee that it will continue to work in the future.
2. If you decide to upgrade, you will have to go through the namespace switchover, anyway.  I’ve seen many organizations make the decision after a few months. Contrary to what you may think now, don’t bank on the fact that you won’t change your mind!

Furthermore, this approach adds a layer of complexity to your deployment. And, as we all know, complexity always leads to more problems in the end. Making configuration changes, whether they are planned or accidental, can have a significant impact on your on-premises or hybrid deployment and cause all sorts of connectivity issues. Proper configuration and change management is definitely a must!

If you are 100% conscious of how to deal with such a scenario and you are confident that you have the right skill set and operational maturity, you might rule that this approach is worth the risk. While I understand the reasoning for that decision, I have rarely seen a customer able to pull this off without running into issues at some point. Forewarned is forearmed!