Exchange Server 2010 Best Practices: Namespace Planning

Editor’s Note: This article is an excerpt from Siegfried Jagott and Joel Stidley, Microsoft Exchange Server 2010 Best Practices (Microsoft Press, 2010) and is reprinted with the publisher’s permission.

Before you set up your Microsoft Exchange Server 2010 organization, one of the most important areas that needs to be planned is your internal (organization-facing) and external (Internet-facing) namespace. A namespace is a logical structure commonly represented by one or more domain names in DNS.

Namespace planning is most important for the Client Access Server role. However, many considerations are also needed for the Hub Transport and Edge Transport roles. This article should provide the general basis for understanding the importance for namespace planning. During migration or transitions, you also might need to consider special namespace requirements. Those topics are discussed in more detail in Siegfried Jagott and Joel Stidley, Microsoft Exchange Server 2010 Best Practices (Microsoft Press, 2010).

The official Microsoft support statement for Exchange 2010 and SLD/Disjoint/Non-contiguous Namespaces can be found at http://msexchangeteam.com/archive/2009/10/27/452969.aspx.

Namespace Scenarios

When you implement your Exchange 2010 organization, you need to decide how your internal and external namespace will be defined. This is important because it affects the following areas:

If you have multiple data centers available where your Exchange 2010 servers are located, consider the following general advice for namespace planning:

To start planning your namespace, you need to consider the various locations of clients and servers and the physical connections they have to the Exchange servers. Typically the namespaces align with your DNS configuration.

You can choose from the following namespace-planning options:

Consolidated Data Center

This namespace scenario is the simplest one and includes a single namespace to access a single physical site where all the Exchange servers are hosted. This scenario has the following advantages:

This namespace scenario is configured by providing Internet access to the Client Access server by opening the relevant ports by a firewall or implementing an application layer firewall such as Forefront Threat Management Gateway (TMG) in the perimeter network.

If you want to provide POP3/IMAP4, you need also to consider how the clients will send their messages using SMTP. To overcome this easily, you can configure the Hub Transport role on each Client Access server. Otherwise, you need to plan separately for message sending and message receiving namespaces.

Single Namespace with Proxy Sites

This model is based on the consolidated data center model but proxies the requests to the physical Mailbox server located at another site. One of the sites has one or more Internet-facing Client Access servers that proxy the requests.

This scenario has the following advantages:

The disadvantage of this model is that most users will access their mailboxes using proxying, thus accessing their data might be slower across latent WAN links.

To configure this namespace model, you need to configure the ExternalURL option of the Client Access server(s) at one site, and make sure that the ExternalURL settings on all the other sites are configured to $Null. This configuration ensures that the Client Access server does not redirect the connection to the target Client Access server, but instead proxies it. Redirect means that the Client Access server forwards the connection to the target Client Access server; proxy means that the Client Access server contacts the target Client Access server and retrieves the data for the connection.

Single Namespace with Multiple Sites

This model uses a single namespace for an organization that has multiple sites. A possible candidate for this approach would be a company that has multiple physical sites and wants to use a single namespace. The two possible approaches to implementing a single namespace with multiple sites are with a Client Access server proxy site or an intelligent firewall:

This scenario has the following advantages:

The disadvantage of this model is that you must either have an application-layer firewall that is capable of forwarding the traffic to the correct physical sites like Microsoft Forefront TMG or a Client Access server proxy site.

Regional Namespaces

This model uses one namespace for each region or site. The users will use their regional namespace to access their messages.

This scenario has the following advantages:

The disadvantage of this model is that you need to manage multiple DNS records as well as multiple certificates. Additionally you have multiple Internet entry points that require a firewall.

Note: The regional namespaces model is recommended if your topology includes multiple sites that have their own Internet connectivity.

Multiple Forests

The multiple forest model uses one dedicated namespace for each forest. For example if Contoso and Litware merged, Contoso users would need to access mail.contoso.com and Litware users would use mail.litware.com to access their mailboxes. Client Access server proxy redirection between the two forests does not work, so if one forest is not available, no users would be able to access their messages.

In this model, every namespace that is implemented needs its own Internet access point, DNS record, and a certificate. Within each forest, use a regional namespace model to improve customer experience.

Disjoint Namespace

The disjoint namespace model is a special scenario for planning the namespace. You face this scenario when your primary DNS suffix on domain controllers or member servers in the domain is not the same as the DNS domain name of your Active Directory domain.

For example, you have a disjoint namespace when the Exchange server that is part of the Litware.com domain has a primary DNS suffix of Contoso.com. This computer (as the primary DNS suffix that does not match the DNS domain name) is said to be disjoint.

You might require these namespaces to be different for several reasons. For example, if DNS management in your company is split between administrators who manage Active Directory and administrators who manage networks, you may need to have a topology with a disjoint namespace.

Microsoft Exchange 2010 has three supported scenarios for deploying Exchange in a domain that has a disjoint namespace:

In Exchange 2010 you may need to configure the DNS suffix search list to include multiple DNS suffixes if you have a disjoint namespace.

In a disjoint namespace environment, you must configure the following:

As mentioned, it is required to configure every disjoint domain in the msds-allowedDNSSuffixes attribute of your root domain. For example, if you have the disjoint namespace contoso.com that you need to add to the Litware.com forest, configure the settings on the domain level using the Windows Server 2008 Administrative Tool ADSI Edit, as shown in Figure 1.

Figure 1: Configuring a disjoint namespace in the domain

Additionally, make sure that the DNS suffix search list contains all DNS namespaces that are deployed within your organization. To do this, you must configure the DNS search list for each computer in the domain that is disjoint. The list of namespaces should include not only the primary DNS suffix of the disjoint member computer and the DNS domain name, but also any additional namespaces for other servers the Exchange servers may interoperate (such as the monitoring server).

For more information on Exchange 2010 and disjoint namespaces, see “Understanding Disjoint Namespace Scenarios” at technet.microsoft.com/en-us/library/bb676377.aspx.

Single Label Domains

A single label domain (SLD) is basically a DNS domain name set equal to a NetBIOS domain name. It does not contain a suffix such as .com or .org and consists only of a single word, such as LITWARE or CONTOSO.

Before Active Directory, in Windows NT a single label domain was the basis, so some companies have continued to use an SLD in Active Directory. In Windows Server 2008 R2 you can no longer create SLDs—if you find an environment that still has SLDs, consider migrating to a normal namespace to prevent issues in the future.

Exchange Server 2010 supports SLDs; however, the Exchange product team does not recommend this configuration because future versions of Exchange or third-party applications might cause issues in this scenario. For that reason, you should move your organization to a normal namespace scenario.

Non-contiguous Namespaces

A non-contiguous namespace (sometimes referred to as a discontiguous namespace) is a namespace where an Active Directory forest includes multiple domain trees of different names. Thus the forest is not defined hierarchically. A forest can have one or more domain trees, and these trees are defined by the DNS names. For example, contoso.com would be a domain tree in the Litware.com forest.

In Windows Server 2008 R2, you can configure multiple domain trees by using the Advanced Mode Installation in the Active Directory Domain Services Wizard (dcpromo.exe).

Important: If you have similar tree names (such as litware.com and litware.de), be sure to choose different NetBIOS domain names for their respective domains. If you select the same NetBIOS names for both trees, the configuration is not supported. The general rule is that each domain must still register a unique legacy NetBIOS domain name.

If your organization has a non-contiguous namespace scenario, DNS must be configured so that every Exchange server is able to resolve all domain names in the environment. You are also required to configure msDS-AllowedDNSSuffixes within the Active Directory environment for all namespaces used in the forest. For more information on how to configure msDS-AllowedDNSSuffixes refer to the section “Disjoint Namespace” earlier in the article.