Changing Namespaces During an Exchange Migration

Joey asks:

“Do you have any recommendation on how to handle cutting clients over to a new namespace (from mail.domain1.org to mail.domain2.org) in conjunction with Exchange 2010/2016 coexistence?”

The short answer is that I recommend you do one of the following:

Change the namespaces before beginning the migration to a new Exchange version
Change the namespaces during the migration only if the new Exchange server is being installed into a different Active Directory site
Change the namespaces after the migration to a new Exchange server has been completed

In the past I’ve generally found it easiest to change the namespaces before beginning the migration. Your circumstances might be different though, so I’ll elaborate on the reasons why I make those recommendations.

But first, why change the namespaces at all? Most of the time customers want to change the Exchange namespaces to align with a new company name or brand, for example rebranding from globomantics.biz to wiredbraincoffee.biz. In those cases it’s important to remember that the only namespace that your end users need to know is the Outlook Web App (OWA) URL that is used to access webmail (and even then, a lot of users don’t remember it and just go to an extranet portal to click through to their webmail). The rest of the namespaces, even those that are visible to users in places such as their mobile device’s email configuration, are configured using Autodiscover. So it might not be necessary to change every namespace. That said, for the sake of consistency and keeping business managers happy, we usually end up changing them all.

The other namespace change scenario that I encounter is when a customer needs to correct a namespace design problem, such as changing from a namespace that contains a server’s real name (e.g. SF-EXCH01.globomantics.biz) to one that uses an alias so that load balancing can be implemented (e.g. mail.globomantics.biz). In either case, the overall change is very similar.

When changing namespaces you’ll need to consider:

Autodiscover caching on Exchange servers – you can cycle the MSExchangeAutodiscoverAppPool in IIS to clear this.
Autodiscover caching on Outlook clients – a local XML file is used to cache information. Client behavior is a good reason to schedule namespace changes for non-business hours, such as over a weekend, to increase the likelihood that clients will perform a fresh Autodiscover the next time they connect.
DNS caching – servers and clients will cache DNS entries depending on the TTL configured on the DNS records. Lowering the TTL to 1 minute in advance of the changes is recommended to avoid DNS caching issues.
SSL certificates – a new certificate for the new namespace(s) will be required. You can pre-provision the certificate, but Exchange can only have one SSL certificate bound to IIS for HTTPS services at any given time, so you’ll need to coordinate the switchover to the new certificate as part of your change. If clients connect to a load balancer that can simplify matters, because a new VIP with the new SSL cert can be pre-configured and ready to go, and all that is necessary then is a DNS change.

Changing Namespaces Before a Migration

Changing namespaces before a migration avoids any situation in which you’re trying to run multiple namespaces within the same Active Directory site. In summary, this won’t work, and you’ll get all kinds of client connectivity issues because clients will discover multiple Autodiscover namespaces for their site, and connect to each in what is supposed to be a predictable manner but rarely behaves that way.

Making the namespace changes before migration also allows the change to be implemented, tested, and all issues remediated, so that there’s no confusion over whether problems during or after a migration are due to the namespace change or due to some other factor that the migration project has caused.

Changing Namespaces During a Migration

You can change namespaces during a migration if the new Exchange servers are being deployed to a different Active Directory site that contains no other servers. This avoids the issues with trying to run multiple namespaces within the same Active Directory site.

Microsoft does recommend you deploy new servers into a separate Active Directory site, but that recommendation is for provisioning purposes, and the new server is typically moved to the existing Active Directory site after initial configuration is complete. You could use the separate AD site as a way to achieve the namespace changing during the migration, and then move the new server to the existing AD site after the migration is complete.

However in reality many customers don’t have the infrastructure available to provision a temporary AD site for this purpose, so changing namespaces during a migration is primarily used by customers who are relocating Exchange to a new datacenter.

Changing Namespaces After a Migration

Waiting until you’ve completed your Exchange migration before you change the namespaces has the same benefit as changing before the migration, in that you are not running multiple namespaces within the same Active Directory site.

However on the downside it does mean that you’ll be messing with the configuration of your nice new server right after you’ve completed the migration. This might mask latent issues that were caused by the migration, making it difficult to track down a root cause.

Summary

There are multiple ways that you can approach the problem of changing Exchange namespaces. In my experience, changing the namespaces before the migration works best. However, there will be factors that are unique to your scenario that will influence the decision, so don’t feel like there is only one correct answer. Most importantly, make sure you’ve planned out the change and if possible tested it in a separate lab environment, and ensure that you have a rollback plan ready in case the changes to badly for you.

Additional Reading:

More information about Exchange Server namespace configuration: