Namespace Planning in Exchange 2013
Published Feb 28 2014 06:00 AM 115K Views
Microsoft

A while back we promised an article on namespace planning and load balancing principles with Exchange 2013. We’re finally going to fulfill that promise as a series of articles.  The articles will span several topics, including namespace planning, load balancing, client connectivity coexistence, and certificate planning.  As the title suggests, this first article will cover namespace planning principles.

Namespace Planning

If you are like the vast majority of our customers, you already have some version(s) of Exchange deployed in your environment. Depending on the version, you may have different namespace requirements today.

Exchange 2007

In Exchange 2007 environments, at a minimum, you had two namespace scenarios:

  1. An Autodiscover namespace – autodiscover.contoso.com.
  2. One or more protocol-based namespaces – mail.contoso.com (for OWA, EAS, etc.); imap.contoso.com (for POP/IMAP clients); smtp.contoso.com (for SMTP client submissions, ad-hoc encryption or partner-to-partner encryption).

In addition, if you deployed in a multi-datacenter environment, you most likely had additional protocol-based namespaces for each region.

Exchange 2010

Like Exchange 2007, Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.

For customers that upgraded from Exchange 2007 (or Exchange 2003), a new namespace requirement was introduced for coexistence – the legacy namespace, legacy.contoso.com. Though it is important to note that the legacy namespace can be called anything you choose, alderaan.contoso.com for example.

Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient solutions:

  1. Primary datacenter Internet protocol namespace (mail.contoso.com)
  2. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
  3. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
  4. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
  5. Transport namespace (smtp.contoso.com)
  6. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
  7. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

Out of these nine namespaces, seven 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 Internet-based protocol, like HTTP.

Exchange 2013

One of the benefits of the Exchange 2013 architecture 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 2013, five namespaces could potentially be removed:

  1. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
  2. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
  3. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
  4. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
  5. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

There’s two reasons for this.

First, Exchange 2013 no longer leverages an RPC Client Access namespace. This is due to the architectural changes within the product - for a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. In other words, the RPC Client Access service is no longer decoupled from the store, like it was in Exchange 2010.

Second, as mentioned, CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2013 does not require the client namespaces to move with the DAG during an activation event – a CAS2013 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).

It’s 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 datacenter’s 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 CAS infrastructure in both datacenters participate in handling traffic, as seen in the following diagram:

Unbound Model
Figure 1: Single Namespace used across Site Resilient Datacenter Pair (Unbound Model)

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.

boundedmodel
Figure 2: Multiple Namespaces used across Site Resilient Datacenter Pair (bound Model)

Other Namespaces

Other namespaces are still required. Exchange 2013 takes advantage of the Autodiscover service for client profile manipulation; so the autodiscover.contoso.com namespace remains in place.

If you are planning to upgrade from Exchange 2007, a legacy namespace is required for connectivity. The legacy namespace provides connectivity for OWA, is the namespace returned in Autodiscover responses (e.g., Exchange Web Services URL), and provides access to Exchange 2007 mailboxes that exist in non-Internet facing Active Directory sites.

Internal vs. External Namespaces

Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces. A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.

This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of Client Access server virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.

In the event that you do not deploy a split-brain DNS (also known as split-DNS) infrastructure, Exchange 2013 has introduced one improvement in this area – Outlook Anywhere now supports separate internal and external namespaces.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings.

Regional Namespaces

The concept of regional namespaces has existed since OWA debuted in 1997 (can you believe OWA is almost 17 years old!?!). 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 cross-region network traffic, you deploy a dedicated namespace for each region (notice that within a region, the unbound model is used):

Regional Namespaces
Figure 3: Regional Namespaces

Conclusion

Exchange 2013 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, client connectivity, and certificate planning, you will understand (hopefully) how to choose the best namespace model.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Updates

  • 3/10/2014: Added note regarding the impact to Outlook Anywhere with respect to namespaces and authentication settings used.

25 Comments
Not applicable
Namespace Planning in Exchange 2013
Thank you
Not applicable
Thanks for the article Ross, it is very informative. I do have a question on legacy URL regarding Outlook connectivity to non-Internet facing Exchange 2007 site.

You stated this in the article: "The legacy namespace provides connectivity for OWA, is the namespace returned in Autodiscover responses (e.g., Exchange Web Services URL), and provides access to Exchange 2007 mailboxes that exist in non-Internet facing Active Directory sites."

I actually thought that legacy namespace is only needed for OWA and EWS and not for Outlook Anywhere Exchange 2007 clients because these connections are proxied from EX2013 CAS to EX2007 CAS. In fact, we are in the middle of a migration right now and I can confirm that it does work this way because Outlook Anywhere clients that have mailboxes on EX2007 in non-Internet facing site can successfully access their mailboxes through EX2013 CAS and we do not have legacy namespace configured. However, EWS is not working and some functionality in Outlook clients is not available (Out-of-office for example, but Availability is working nicely).

Sorry If I misinterpreted your wording.

Regards,
Dinko
Not applicable

@ConfusedAboutDAGActive/ActiveHA - If there is a concern about maintaining service when WAN connectivity is lost between datacenters, then the only solution is to place the FSW in a third site. I didn't want to bog this article down in those intricacies since it is not directly tied to namespace planning.

@Petri X - Yes, we recommend multi-role deployments. These examples just highlight the specific function each role has, and does not imply we recommend dedicated role deployments. Yes the unbound model can have more than 1 DAG - I used 1 to highlight the differences between unbounded and bounded; obviously, if you have more mailboxes or servers that can be instantiated in a single DAG, you will need to create more. However, the difference between unbounded and bounded still exists - one is used to control connectivity, while the other is not.

Ross

Not applicable
It is informative & Thanks!
Not applicable
If possible, I would like to see some clarifications for this article...
Microsoft currently recommend to use Exchange servers having all roles, but all of these examples are having dedicated CAS and MBX servers. Is there any reasons for this? When you are using combined server roles, how that affect for the namespace?

Also I would like to see the unbound model where you have two DAGs deployed (across two data centers). Some how I feel that would suits quite many companies with two data centers. And will it change, if you are deploying more than two DAGs across two data centers? (if the DAG goes down, less users are affected).

And big hand for OWA ! That has went log journey with Exchange :D It has been wonderful to see how it has been grown :)
Not applicable
Great Explanation with options for onpremise deployments
Not applicable
Very well done. Thanks for the informative post.
Not applicable
Awesome explanation Ross. Just shared with some friends in Australia who are planning for Exchange 2013 migration and had concerns with namespace....
Not applicable
@Kris - Stay tuned for the next article in the series that will touch upon that subject. However, ultimately session affinity impacts ultimately have to be provided by the load balancer vendor.

@Dinko - the third article in the series will cover this in more detail.

@Pete - legacy coexistence will be covered in the third article. Ultimately, I am not sure what issues exist that you are referring to, so a detailed example will be helpful.

@Pesos - that is fine. you are basically doing a bounded model (with an active and passive datacenter pair).

Ross
Not applicable
Good stuff, Ross. Looking forward to rest of this series.
Not applicable
A Great Exchange Server 2013 Article, Thanks :)
Not applicable
Ross,

Any plans on providing guidance re: NLB persistence vs no-persistence and the associated performance overhead?
Not applicable
Great subject matter that is not written about enough. You addressed the issue with the Internal versus External namespace matter, and while your recommendations are sound (single namespace, split-brain DNS), one of the challenges is that recommendation is great for green-field deployments, but does not help the organization that has an existing namespace topology that doesn't fall under the single namespace, subdomain approach. There are a ton of .Loc or other internal TLDs that are not owned by the organization, or was an artifact of some earlier acquisition, or just reflecting practices in the late 1990's. Many of these folks feel stuck as to how to approach. I would love to hear your comments on the strategies not for greenfield environments, but legacy environments that have to deal with these matters.

Thanks,
http://vmpete.com
@vmpete
Not applicable
Very good Exchange Server 2013 Article, Thanks
Not applicable
Nice post ! Waiting for the rest
Not applicable
Great Exchange On-Premises article, Thanks
Not applicable
Awesome, thanks Ross.

Question: we have two datacenters and no "internal" clients - everyone around the country connects via Outlook Anywhere. So our internal and external URLs are the same - mail.domain.com

We also only utilize this single namespace, and in the event of a failover we'd simply repoint this DNS name to the backup datacenter's ip address.

Is there any reason not to use this simple approach?
Not applicable
Very good Exchange 2013 On-Premises article, Thanks. :)
Not applicable
@Kris Smith I think the MSFT answer will be don't do it same as 2010. Even with no requirement for persistence and L4 Load Balancing now, NLB is not service aware. Plus you would need to split out your server roles CAS and MBX as Windows Clustering and NLB are't supported on the same box. The encouraged best practice of course being multi-role servers now since Exchange 2010. Plus NLB just doesn't scale well for large deployments.
Not applicable
In your recommended Unbounded model, you show a single DAG in an Active/Active configuration. Since there is only 1 File Share Witness active at a time, how are you ensuring the DAG servers in the datacenter w/o the FSW are able to maintain quorum in the event of WAN communication issues? It seems to me that any time the WAN goes out for more than a few seconds the DAG nodes in the non-FSW datacenter will go terminate Exchange (to prevent an Exchange split-brain scenario).

At the moment that's why a single Active/Passive DAG is more attractive to me, with the "bound" model where all client requests go to the Active datacenter. I'm hoping there is something new in Exchange 2013 that allows a DAG to run Active/Active w/o having the cluster service bring down Exchange on the DAG nodes in the non-FSW datacenter just because of WAN connectivity issues. Otherwise I'm having a hard time understanding how this model can provide the HA an Active/Passive model can.
Not applicable
Awesome explanation! Thanks Ross.
Not applicable
Great article!
But hope that part 3 will be following very soon because, as Dinko, I'm also in testing phase of E2007-E2013 transition :)
Not applicable
Fantastic article Ross. Love the diagrams.
Not applicable
Ross,

Great article. Very detailed. Thank you. I have a question regarding the autodiscover namespace. For Exchange 2013, would you need an additional name for autodiscover?
Not applicable
Ross,

I reread the article ... saw "Other Namespaces" D'oh!!. Thanks again for this fantastic article.
Version history
Last update:
‎Jul 01 2019 04:18 PM
Updated by: