Bound to unbound namespace

%3CLINGO-SUB%20id%3D%22lingo-sub-1645299%22%20slang%3D%22en-US%22%3EBound%20to%20unbound%20namespace%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1645299%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20currently%20have%20exchange%202010%20spread%20across%202%20datacenters%20using%20a%20bound%20namespace.%20Users%20in%20the%20west%20use%20the%20mail-west.domain.com%20namespace%20while%20the%20users%20in%20the%20east%20use%20mail-east.domain.com.%26nbsp%3B%20We%20are%20looking%20to%20upgrade%20to%202016%20and%20follow%20the%20current%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fthe-exchange-2016-preferred-architecture%2Fba-p%2F604024%22%20target%3D%22_self%22%3Epreferred%20architecture%3C%2FA%3E%20utilizing%20an%20unbound%20namespace.%26nbsp%3B%20Since%20our%20existing%20namespaces%20are%20region%20specific%2C%20the%20new%20unbound%20namespace%20would%20be%20something%20generic%20like%20mail.company.com.%26nbsp%3B%20Is%20it%20possible%20to%20migrate%20to%20a%20new%20namespace%20during%20an%20exchange%202010%20to%202016%20upgrade%2C%20and%20if%20so%20how%20does%20this%20change%20the%20upgrade%20process%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1645299%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3E2010%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3E2016%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EExchange%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1645648%22%20slang%3D%22en-US%22%3ERe%3A%20Bound%20to%20unbound%20namespace%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1645648%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F786082%22%20target%3D%22_blank%22%3E%40PlumpJack%3C%2FA%3E%26nbsp%3B%3CBR%20%2F%3EYou%20should%20be%20able%20to%20perform%20this%20if%20you%20follow%20the%20%3CA%20href%3D%22https%3A%2F%2Fassistants.microsoft.com%2F%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EDeployment%20Assistant%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3BAt%20some%20point%20in%20time%20you'll%20be%20required%20to%20adjust%20virtual%20directories%20to%20point%20to%20a%20new%20Exchange%202016%20namespace.%20MS%20recommends%20doing%20it%20as%20soon%20as%20the%20new%20Exchange%20version%20is%20introduced%20into%20the%20Exchange%20Org.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1646154%22%20slang%3D%22en-US%22%3ERe%3A%20Bound%20to%20unbound%20namespace%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1646154%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F436715%22%20target%3D%22_blank%22%3E%40VickVega%3C%2FA%3E%26nbsp%3BThank%20you%20for%20your%20feedback.%26nbsp%3B%20I%20have%20gone%20through%20the%20deployment%20assistant%2C%20but%20it%20is%20not%20very%20clear%20on%20the%20introduction%20of%20a%20new%20namespace.%26nbsp%3B%20It%20makes%20mention%20about%20updating%20the%20exchange%202010%20outlook%20anywhere%20and%20autodiscover%20url%20to%20match%20the%20exchange%202016%20namespace%2C%20but%20does%20that%20mean%20that%20is%20the%20only%20change%20on%202010%3F%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20found%20several%20articles%20that%20mention%20not%20to%20have%20multiple%20namespaces%20in%20the%20same%20AD%20site%20as%20it%20will%20cause%20issues%2C%20as%20well%20as%20others%20that%20mention%20it%20is%20not%20recommended%20to%20change%20the%20namespace%20during%20a%20migration.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fpractical365.com%2Fexchange-server%2Fchanging-namespaces-exchange-migration%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fpractical365.com%2Fexchange-server%2Fchanging-namespaces-exchange-migration%2F%3C%2FA%3E%3C%2FP%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fnamespace-planning-in-exchange-2016%2Fba-p%2F604072%22%20target%3D%22_blank%22%3Ehttps%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fnamespace-planning-in-exchange-2016%2Fba-p%2F604072%3C%2FA%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1646312%22%20slang%3D%22en-US%22%3ERe%3A%20Bound%20to%20unbound%20namespace%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1646312%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F786082%22%20target%3D%22_blank%22%3E%40PlumpJack%3C%2FA%3E%26nbsp%3B%3CBR%20%2F%3EAdjusting%20those%20FQDNs%2C%20basically%20changes%20the%20end-point%20to%20which%20client%20is%20connecting%20for%20the%20provided%20services.%20Adding%20mail.domain.com%20onto%20the%20new%20Exchange%202016%20certificate%20would%20allow%20you%20to%20point%20the%20users%20to%20the%20required%20client%20access%20server%2C%20usually%20the%20latest%20Exchange%20version.%26nbsp%3B%20Depends%20on%20the%20state%20of%20the%20other%20virtual%20directories%20on%20other%20servers%2C%20Exchange%20accepting%20the%20connection%20would%20either%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fexchange-team-blog%2Fclient-connectivity-in-an-exchange-2016-coexistence-environment%2Fba-p%2F603945%23%3A~%3Atext%3DThe%2520Exchange%25202016%2520Client%2520Access%2520component%25E2%2580%2599s%2520RPC%2520proxy%2Cconnect%2520to%2520mail.contoso.com%2520as%2520his%2520RPC%2520proxy%2520endpoint.%22%20target%3D%22_self%22%3Eproxy%20or%20redirect%3C%2FA%3E.%3CBR%20%2F%3EThat's%20your%20name%20space%20change%20%3A).%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1646608%22%20slang%3D%22en-US%22%3ERe%3A%20Bound%20to%20unbound%20namespace%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1646608%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F436715%22%20target%3D%22_blank%22%3E%40VickVega%3C%2FA%3E%26nbsp%3B%20So%20it%20is%20not%20necessary%20to%20update%20the%20remaining%20URLs%20(ECP%2CEWS%2CActiveSync%2COAB)%20on%202010%2C%20to%20the%20new%20namespace%3F%26nbsp%3B%20Won't%202016%20proxy%20the%20autodiscover%20request%20to%20the%20server%20housing%20the%202010%20mailboxes%2C%20so%202010%20would%20return%20the%20old%20URLs%20to%20the%20client%3F%26nbsp%3B%20If%20that%20is%20the%20case%2C%20should%20the%20old%20URLs%20resolve%20to%20the%20exiting%20vip%20load%20balancing%20the%202010%20servers%2C%20or%20the%20new%202016%20vip%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

We currently have exchange 2010 spread across 2 datacenters using a bound namespace. Users in the west use the mail-west.domain.com namespace while the users in the east use mail-east.domain.com.  We are looking to upgrade to 2016 and follow the current preferred architecture utilizing an unbound namespace.  Since our existing namespaces are region specific, the new unbound namespace would be something generic like mail.company.com.  Is it possible to migrate to a new namespace during an exchange 2010 to 2016 upgrade, and if so how does this change the upgrade process?

5 Replies
Highlighted

@PlumpJack 
You should be able to perform this if you follow the Deployment Assistant

 At some point in time you'll be required to adjust virtual directories to point to a new Exchange 2016 namespace. MS recommends doing it as soon as the new Exchange version is introduced into the Exchange Org.

Highlighted

@VickVega Thank you for your feedback.  I have gone through the deployment assistant, but it is not very clear on the introduction of a new namespace.  It makes mention about updating the exchange 2010 outlook anywhere and autodiscover url to match the exchange 2016 namespace, but does that mean that is the only change on 2010? 

 

I have found several articles that mention not to have multiple namespaces in the same AD site as it will cause issues, as well as others that mention it is not recommended to change the namespace during a migration.

 

https://practical365.com/exchange-server/changing-namespaces-exchange-migration/

https://techcommunity.microsoft.com/t5/exchange-team-blog/namespace-planning-in-exchange-2016/ba-p/6...

 

 

Highlighted

@PlumpJack 
Adjusting those FQDNs, basically changes the end-point to which client is connecting for the provided services. Adding mail.domain.com onto the new Exchange 2016 certificate would allow you to point the users to the required client access server, usually the latest Exchange version.  Depends on the state of the other virtual directories on other servers, Exchange accepting the connection would either proxy or redirect.
That's your name space change :).

Highlighted

@VickVega  So it is not necessary to update the remaining URLs (ECP,EWS,ActiveSync,OAB) on 2010, to the new namespace?  Won't 2016 proxy the autodiscover request to the server housing the 2010 mailboxes, so 2010 would return the old URLs to the client?  If that is the case, should the old URLs resolve to the exiting vip load balancing the 2010 servers, or the new 2016 vip?

Highlighted

@PlumpJack 

All URLs during co-existence would point to 2016 end-point/s, this was way all the traffic would be proxied through to backend 2010.