Professional Documents
Culture Documents
Home
NamespacePlanninginExchange2016ExchangeTeamBlogSiteHomeTechNetBlogs
Library
Forums
Wiki
TechCenter
138
Tw eet
33
If you are like the vast majority of our customers, you already have some versions of Exchange deployed in your environment. Depending on the version, you
Like
may have different namespace requirements today.
Exchange 2010
Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.
Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient
solutions:
1.
2.
3.
4.
5.
6.
7.
Out of these seven namespaces, five of them were required on certificates. The RPC Client Access namespaces were not required on the certificate because
they were accessed via RPC connectivity and not via an Internetbased protocol, like HTTP.
Exchange 2016
One of the benefits of the Exchange 2016 architecture first introduced in Exchange 2013 is that the namespace model can be simplified, when compared to
Exchange 2010.
An example of how it can be simplified can be seen when thinking about a site resilience scenario. If you have two datacenters participating in a site resilient
architecture, by replacing the Exchange 2010 infrastructure with Exchange 2016, five namespaces could potentially be removed:
1.
2.
3.
4.
5.
http://blogs.technet.com/b/exchange/archive/2015/10/06/namespaceplanninginexchange2016.aspx
1/5
10/12/2015
NamespacePlanninginExchange2016ExchangeTeamBlogSiteHomeTechNetBlogs
Figure 1: Client Access services on MBX Server 1 proxying traffic to the Mailbox server hosting the active database copy on MBX Server 3
This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2016 does not require the client namespaces to move with
the DAG during an activation event a Mailbox server in one Active Directory site can proxy a session to a Mailbox server that is located in another Active
Directory site. This means that unique namespaces are no longer required for each datacenter mail.contoso.com and mail2.contoso.com; instead, only a
single namespace is needed for the datacenter pair mail.contoso.com. This also means failback namespaces are also not required during DAG activation
scenarios, so mailpri.contoso.com and mailsec.contoso.com are removed.
Namespace Models
Depending on your architecture and infrastructure you have two choices:
1. Deploy a unified namespace for the site resilient datacenter pair unbound model.
2. Deploy a dedicated namespace for each datacenter in the site resilient pair bound model.
Its also worth mentioning that these choices are also tied to the DAG architecture.
Unbound Model
In an unbound model, you have a single DAG deployed across the datacenter pair. This DAG has Mailbox servers in each datacenter typically all Mailbox
servers are active and host active database copies, however you could deploy all active copies in a single datacenter. Mailboxes for both datacenters are
dispersed across the mailbox databases within this DAG. In this model, clients can connect to both datacenters in the event there is a WAN failure neither
datacenters connectivity is a boundary, hence the term unbound. It does not guarantee, however, the connectivity provides users an equal experience; meaning
one connection may provide a better user experience because it has lower latency or more bandwidth.
In an unbound model, a single namespace is preferred because either datacenter can service the user request. This means that from a load balancing
perspective, the Exchange 2016 Mailbox servers in both datacenters participate in handling traffic, as seen in the following diagram, where VIP virtual IP
address is the load balanced IP address associated with the namespace:
Figure 2: Single Namespace used across Site Resilient Datacenter Pair Unbound Model
http://blogs.technet.com/b/exchange/archive/2015/10/06/namespaceplanninginexchange2016.aspx
2/5
10/12/2015
NamespacePlanninginExchange2016ExchangeTeamBlogSiteHomeTechNetBlogs
As a result, for a given datacenter, the expectation is that 50% of the traffic will be proxied from the other datacenter.
Bound Model
As its name implies, in a bound model, users are associated or bound to a specific datacenter. In other words, there is preference to have the users operate
out of one datacenter during normal operations and only have the users operate out of the second datacenter during failure events. There is also a possibility
that users do not have equal connectivity to both datacenters. Typically, in a bound model, there are two DAGs deployed in the datacenter pair. Each DAG
contains a set of mailbox databases for a particular datacenter; by controlling where the databases are mounted, you control connectivity.
In a bound model, multiple namespaces are preferred, two per datacenter primary and failback namespaces, to prevent clients trying to connect to the
datacenter where they may have no connectivity. Switchover to the other datacenter is a controlled event.
Figure 3: Multiple Namespaces used across Site Resilient Datacenter Pair Bound Model
Autodiscover Namespace
Exchange 2016 takes advantage of the Autodiscover service for client profile configuration; so the autodiscover.contoso.com namespace remains in place.
Figure 4: Office Online Server Namespaces Bound Model w ith an Exchange Unbound Model Namespace
As all the data serviced by Office Online Server is either stored in Exchange or SharePoint, during a datacenter outage, namespace manipulation steps are not
http://blogs.technet.com/b/exchange/archive/2015/10/06/namespaceplanninginexchange2016.aspx
3/5
10/12/2015
NamespacePlanninginExchange2016ExchangeTeamBlogSiteHomeTechNetBlogs
required. For example, if we refer to the previous diagram if the West datacenter fails, you dont need to change the DNS record for the Office Online Server
namespace in West and point it to the load balancer in East. This is due to the architecture of Exchange and Office Online Server. Any Exchange 2016 Mailbox
server will always proxy the clients request to the Mailbox server that hosts the users mailbox database. The Mailbox server hosting the users mailbox is
responsible for generating the Office Online Server URL that is used by OWA. This URL is defined perMailbox server, thereby ensuring that any Office Online
Server interactions are always local to the Mailbox server.
Regional Namespace
The concept of regional namespaces has existed since OWA debuted in 1997. A regional namespace is a way for clients to connect to the client access
endpoint that is closest to the Mailbox servers hosting the data.
Use of a regional namespace does not necessarily mean you are restricted to a bound model, either. This is because depending on your infrastructure and
network capabilities, you may choose to have a dedicated namespace for each datacenter pair. For example, your company may have a set of datacenters in
North America and in Europe, and due to a desire to reduce crossregion network traffic, you deploy a dedicated namespace for each region notice that
within a region, the unbound model is used:
Figure 5: : Regional Namespaces coupled w ith GeoDNS to RoundRobin betw een Datacenters w ithin a Region
Conclusion
Exchange 2016 introduces significant flexibility in your namespace architecture, enabling deployment of a single unified namespace for a site resilient
datacenter pair or worldwide, or deployment of multiple namespaces. As we delve into the intricacies surrounding load balancing principles and client
connectivity, you will understand hopefully how to choose the best namespace model.
Ross Smith IV
Comments
StephenKCEE #
http://blogs.technet.com/b/exchange/archive/2015/10/06/namespaceplanninginexchange2016.aspx
4/5
10/12/2015
NamespacePlanninginExchange2016ExchangeTeamBlogSiteHomeTechNetBlogs
Thanks Ross for keeping us up to date with Namespace planning, always fun!
Jetze Mellema #
Great article! So basically nothing changes from Exchange 2013 to 2016, except for the introduction of Office Online Server namespaces. Thanks for the
reminder of the authentication settings for Outlook Anywhere because Outlook will try the Internal settings first.
"The concept of regional namespaces has existed since OWA debuted in 1997." Shouldn't that read EWA? :
Exchange TechNet
Resources
Exchange TechCenter
Exchange Server 2010
Exchange Server 2007
TechNet Library
Forums
Quick Links
Support
Exchange Development
Blog
Buy Now
MSExchange.org
Exchange Online
MSExchangeGuru's Blog
Ask Perry
More...
Terms of Use
Trademarks
http://blogs.technet.com/b/exchange/archive/2015/10/06/namespaceplanninginexchange2016.aspx
Privacy Statement
Report Abuse
5/5