Critical namespace configurations in Exchange Server 2013

It's important to get namespace planning right the first time. Otherwise, it's difficult -- or even impossible -- to change later.

One of the main considerations when installing Exchange Server 2013 is the namespace configuration. The namespace is one of those things you need to get right the first time because it can be difficult or impossible to change later.

The amount of work you have to put into namespace planning for Exchange 2013 is based on two factors. First, namespace planning involves less work if you perform a clean deployment as opposed to migrating from Exchange Server 2007. Second, simple, small-scale Exchange deployments require less work than those that span multiple locations or require load balancing.

In a large-scale Exchange Server deployment that spans multiple data centers and uses load balancing, there are six main namespaces to plan for; there may be others, depending on how your environment is configured:

  • The primary data center's IP namespace
  • The secondary data center's IP namespace
  • The primary data center's Outlook Web App (OWA) failback namespace
  • The secondary data center's OWA failback namespace
  • The legacy namespace, assuming the environment has been migrated from Exchange 2007
  • The Autodiscover namespace

For this discussion, I'll focus on the IP namespaces within the primary and secondary data centers. These namespaces are generally tied to geographic location. For example, suppose you have two data centers in North America -- one in Miami and another in Seattle. In this situation, you might use names such as Miami.contoso.com or Seattle.contoso.com.

This approach initially seems straightforward; but things get more complicated when you consider that one of the benefits to using multiple data centers is being able to place database availability group members in both locations. As such, a user's mailbox could be located in either location, depending on which database copy is active at any given moment.

You need to make things easy on your users. You don't want to tell a user in Miami to go to Miami.contoso.com, and if that doesn't work, to try Seattle.contoso.com. Fortunately, you don't have to. With proper planning, it's possible to use a single namespace configuration for all mailbox access and let Exchange Server sort out the details.

Remember: Everything depends on having reliable, high-speed connectivity between the two data centers. Things work differently if low-latency connectivity isn't available.

With that said, let's assume that both the Miami and the Seattle data centers contain Client Access Server arrays that handle load balancing for the respective data centers -- and that each array consists of three CASes. We could create a public domain name system (DNS) namespace configuration for Miami.contoso.com and Seattle.contoso.com, but it's easier to create a single, generic namespace.

In this situation, we might use something like mail.contoso.com. It doesn't matter that this Internet namespace doesn't match any of our data centers; the DNS record can contain the virtual IP addresses of our CAS arrays; this means inbound requests will be distributed between the two data centers in a round-robin fashion.

There are two things you need to know about Exchange 2013 CAS. First, CAS no longer performs any sort of data rendering -- a CAS handles only authentication and proxy or redirection logic. It doesn't try to do any type of data transformation. Second, load balancing now occurs at Layer 4 instead of Layer 7, so session affinity is no longer required for load balancing.

With those two points in mind, let's go back to our example. Since DNS is distributing requests evenly to the two data centers, it's possible that a Miami user's request could get sent to Seattle. When the Seattle data center receives the request, the load balancer assigns the request to one of the CASes in the CAS array. That CAS authenticates the request, then determines which mailbox database the user's mailbox is in.

At this point, the CAS must make a decision about whether to proxy the request to the mailbox server or to redirect the request to another CAS array. Redirection occurs only when the request is related to telephony or in special circumstances pertaining to OWA requests for mailboxes located in other Active Directory sites. In most cases, the CAS will query the Active Manager to determine where the active database copy is located and will then proxy the request to that mailbox server.

About the author:
Brien Posey is an eight-time Microsoft MVP for his work with Windows Server, IIS, Exchange Server and file system storage technologies. Brien has served as CIO for a nationwide chain of hospitals and healthcare facilities and was once responsible for IT operations at Fort Knox. He has also served as a network administrator for some of the nation's largest insurance companies.

Dig Deeper on Exchange Server setup and troubleshooting