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:
i have a complex configuration as following
two domains ( xxxx.net and the other one is xxxx.edu,kw ) the AD domain name is xxxx.net and i’ve exchange 2013 with it, in order to migrate to O365 i’ve added the other domain as alternative xxxx.edu.kw and configure the DNS so now all the mailboxes are in the cloud ( xxxx.net and xxx.edu.kw ) and has the same mailbox synced with the ADconnect, now they need to cancel xxxx.net at all and keep only xxx.edu.kw
what i did is i created a new AD with the new domain name xxx.edu.kw and move all the users and groups using ADMT.
my question do i install a new exchange server with the new domain and then install a new ADconnect or what’s the best solution for this ?
Hi Paul. I have a 2010 being migrated to 2016 and the namespaces do all point to the fqdn internally (exchange.xxx.local), while externally they point to a webfacing domain (mail.xxxxx.com) that funnels through a barracuda and then into the server. My hunch is the internal one needs to be changed to an alias in DNS for coexistence and for the migration in general to continue? This would be the first time i ‘ve needed to do this… would i point the alias at the existing hostname of the 2010 exchange, and then change all the internal namespace entries to point to the new alias? When the 2016 comes online i would point it at the new alias as well?
Hi Paul, a question around introducing new namespace when introducing Exchange 2013 in an Exchange 2010 environment.
In our environment, we are looking to introduce Exchange 2013/2016 to stand up a new platform to consolidate 3-4 Exchange orgs (read M&A). The Exchange 2013/2016 is to have a new namespace as the old one does not reflect the new business. The new platform will be across 2 regions and in their own AD sites
Will this be any connectivity issues when migrating users from Exchange 2010 to Exchange 2013/2016 because the namespace will be different? Anything else that we need to look out for certificates, etc?
Thanks.
Regards
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
The servers using the new namespace will need to be in a new/separate AD site than the existing servers. Other than that, as long as you get your certificates in place correctly, there should be no issues.
Paul thanks as always for the wisdom. I have an interesting situation. I am installing 3 exchange 2016 servers for a customer of mine. 2 in the primary site and 1 in the remote (colo) site. My customer currently has 2 exchange 2010 servers in a DAG across the two sites. The problem is that they do not use Split DNS.
They only have the publicly hosted DNS externally, and a matching external zone that is published internally on their domain controllers. They don’t and are not getting a load balancer. All of their internal virtual directories point directly to the server FQDN’s as well as the SCP records. They have an external name space (SMTP.domain.com) that they use for OWA.
My question is this. Should I create a new namespace internally for them? Or is there a way that I could configure the records on the internal DNS servers to use SMTP properly? Thanks again as always sir.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
You say they aren’t using split DNS but then say they have a public DNS zone and the same zone hosted internally on their DCs? That means they are using split DNS.
You can use any namespace you want to configure on the Exchange virtual directories. Just add the appropriate records to DNS for that namespace.
No namespaces/vdirs, should point to the servers FQDNs.
So I’m in this situation now. I have an Exchange 2013 server, migrating to an Exchange 2016 server. All URIs for the Exchange 2013 server are named after the server (ex2013.contoso.com). All of the Exchange 2016 URIs are named mail.contoso.com. Except for Autodiscover.contoso.com; that URI is the same at both servers, and autodiscover.contoso.com resolves to the Exchange 2016 server in DNS.
Even though all mailboxes have been moved to Exchange 2016, some clients are still connecting to Exchange 2013.
Before I remove Exchange 2013, I need to get everyone pointed at mail.contoso.com. To do so, do I just change all of the URIs on Exchange 2013 to mail.contoso.com?
Thanks!
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Yes. Ideally you’d fix that before introducing the 2016 server, but the second best time to fix it is now 😉
Great! I’ll do so tonight while everybody is out.
Do you know if this will also cause ActiveSync/Mobile devices to automatically update their connection point to mail.contoso.com? Or will I have to touch all of those?
Thanks so much for your quick reply.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I think they won’t update. But as long as the old name still resolves in DNS and the SSL cert if still valid for that name (as well as the new name obviously) then it should be okay.
I’ll update DNS internal and external once Exchange 2013 is gone. Got a wildcard cert on Exchange 2016, so that should be fine…. hopefully.
Thanks again. You’re the man!
Thanks a lot Paul! I saw many of your trainings on pluralsight in the past and its awesome to get your input.
Your comment is very helpful and puts me at ease with some of these key decisions.
Hi Paul,
I am migrating from Exchange 2010 to 2016. 2010 is using namespace A and is in a single AD site A with stretched VLAN.
Exchange 2016 will be in AD Site A and B with HA DAG.
I have 2 questions:
1. What would be preferred as safest way to introduce Exchange 2016? Same namespace 2010 uses or a new namespace for 2016?
With current namespace that 2010 uses, I would have to switch the DNS records that point at load balancing for 2010 to the load balancing for Exchange 2016 and then all the 2010 users would have to be proxied via Exchange 2016 (the LB VIPs would not be used anymore). I dont know how Exchange 2016 would properly spread the load and maintain the source sticky persistence that the current LB VIP provide.
With New namespace, I could have 2010 clients connect via old namespace to Exchange 2010 LB VIP –> Exchange 2010 and as I migrate users, they would connect via new namespace to Exchange 2016 VIP –> Exchange 2016 servers.
I tested this in the lab and did not see any issues with this solution yet, but of course, lab is never like production.
2. OutlookAnywhere confused me a bit. I see some recommendations where if you dont use it now, dont worry about it (dont configure it and dont patch Exchange 2010 servers). Some others recommend that its configured for Coexistence as Outlook clients that have mailbox on Exchange 2010 will proxy via Exchange 2016 and use OutlookAnywhere to connect – is this true? We dont use OutlookAnywhere for Exchange 2010 right now, so would rather keep it off if its not needed.
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
You’re installing Exchange 2016 into the same site as 2010, so to me that says your only option is to use the same namespace for 2016.
Yes, during co-existence the namespaces need to be pointed to 2016. That excludes the Exchange 2010 CAS Array/RPCClientAccessServer namespace though.
Not sure what you mean about Exchange 2016 spreading the load. Isn’t that what your load balancer is doing? Once a connection hits the Exchange 2016 server, Exchange 2016 proxies that connection to the mailbox server hosting the user’s mailbox.
For Outlook Anywhere I’ve always configured it because I prefer to just have everything working the way I expect it to work and not run into any weirdo issues that might be caused by not having it enabled. It’s up to you.
I am confused. Is this where I rename the 2010 URLs to a legacy name?
Then move the production URL “mail.contoso.com” to the 2016 server URLs at mailflow cutover time?
This is what we did from 2007 to 2010 coexistence.
Or, do i just switch the client connections to hit the new load balanced 2016 servers, and then they will route mail to both 2016 and 2010 mailboxes in coexistence?
Josh
Hello,
Thanks for sharing.
I currently migrating an Exchange 2013 infrastructure to a 2016 one in a new AD site (same namespace).
I would like to change the namespace after the migration, any recommendation ? I suppose I’d need a certificate with the new namespace name and the old one too. About Outlook Anywhere, does the Outlook client profile will be updated automatically if I change the OA hostname ?
Thanks!
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
If you’re migrating to a new AD site you could set up the new namespace from the beginning, that gives you the opportunity to test it thoroughly before doing the bulk of the migrations.
Actually it’s too late, migration has stared few weeks ago. So my plan is to decomission old Exchange 2013 servers after all users/datas was migrated and pointer DNS/LB to the new infrastructure.
Then, change the namespace. Like I ask before, did you have any recommendation about that ? Specially for Outlook anywhere ?
Thanks
The Real Person!
Author Paul Cunningham acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Plan, test, have a roll back plan.
Ok but does the Outlook Profile will be updated automatically without any intervention after I change the Outlook Anywhere hostname namespace ?