Learn about the versions of Exchange supported by coexistence with Exchange 2016. Also learn about server names, namespace requirements, and best practices.
- [Instructor] In this course, we take a look at three different types of Exchange Coexistence. What we're going to look at now is mixing different versions of Exchange in the same Active Directory forest. Exchange 2016 servers can coexist in environments that already have Exchange 2010 or Exchange 2013 servers. This ability is important for two reasons. One is for migration. As you move from an older version of Exchange to a newer, whether it's to pick up new features or because what you have is reaching the end of support life, the ability to install a newer version of Exchange in a functional environment is important, and we'll get into some of those steps later on in the course.
A second reason to consider Coexistence would occur if you have a very large environment with dozens of Exchange Servers in multiple data centers across the country or the world. At some point, you're going to have mixed versions of Exchange. A new site or a new server may be brought online that needs a newer version for licensing or for some other reasons, but migrating the entire network in the same weekend isn't part of the plan. When you want the two versions to coexist, it's important to understand how the two will exchange information.
Can Exchange 2016 proxy client connections to Exchange 2010? Can Exchange 2013 Client Access servers proxy connections to Exchange 2016 mailboxes? And for that reason, the newest version needs to be out front. In a mixed environment, clients need to send their requests to the newest version of Exchange in the organization, and those requests will be proxied or redirected to the appropriate mailbox or Client Access server, which may be an older version.
This means we will have to do some planning with our namespaces. It's common to have at least three separate namespaces in an Exchange organization. One for Autodiscover, one for SMTP, and one for everything else. And it's not unusual to see a namespace on the external network separate from the one used internally. Consider this configuration. We have a Windows 2012 R2 server installed with Exchange 2013 as a Client Access server.
The server name is exch13cas01 and we've been using that namespace internally, but we've configured the external namespace as mail.landonhotels.com. Once we install an Exchange 2016 server, we're going to need to configure its certificate and the external DNS to point mail.landonhotels.com and autodiscover.landonhotels.com to the newer version of Exchange, and this is pretty straight-forward if the two versions of Exchange are in the same Active Directory site and if the namespace is different from the server name.
See how a change could create some confusion as we switch over to a new server name. Let's take a look at this internal namespace. Some organizations will choose to use the same name, such as mail.landonhotels.com, both internally and externally. This makes the introduction of a new version of Exchange easier because the namespace change is actually handled by DNS. It can be problematic though if you're using Outlook Anywhere, a service that allows Outlook to connect to the full Exchange experience both inside and outside the company network.
Those two connections need separate URLs or separate namespaces to cache their separate authentication processes correctly. Creating a fairly general namespace to be used internally, in this case email.landonhotels.com, that is still separate from the one used externally, in this case mail.landonhotels.com, can help keep the two separate and still allow the changes to be made by simply adjusting DNS to point to the IP address of the new server.
Things can get even worse if someone made the mistake of actually naming the servers the same as the client namespaces. Using things like Autodiscover or SMTP, or things less obvious, like the Mail and Email namespaces. Servers should always carry names that have something to do with what that Exchange Server is and/or does. Using server names like this will help avoid confusion later on and that confusion is something you definitely want to avoid.
The process of remaining an Exchange Server involves, one, migrating all mailboxes and installed services and roles to another Exchange Server in the organization. And then two, uninstalling Exchange from that server so that you can, three, change the server's identity and four, reinstall Exchange on that server from scratch and migrate all of the mailboxes and roles back.
And this can take hours, if not days to complete. All to overcome something as simple as the name of the server. Never assign an important name, like Autodiscover or Mail, as a server name. Always plan for the day when that server and its name will need to be retired. To make the migration and retiring of servers as seamless as possible, include names like Mail and Autodiscover as alternative names in your certificates and use DNS host entries to point traffic to servers named Exchange13cas04 or Exchange16mailbox01.
- Preparing for hybrid configuration
- Deploying a hybrid configuration
- Troubleshooting Exchange Online
- Troubleshooting Office 365 clients
- Configuring the gateway
- Managing sharing policies
- Troubleshooting cross-forest availability
- Troubleshooting mail flow
- Migrating from earlier versions