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:
- DNS configuration of your Exchange servers
- How your certificates are created and what names they include
- Client Access (Outlook Anywhere—OA, Outlook Web App—OWA, POP3 and IMAP4, SMTP)
If you have multiple data centers available where your Exchange 2010 servers are located, consider the following general advice for namespace planning:
- Plan your namespaces such that both data centers can be active.
• This still allows for incremental deployment.
• You provide failover capabilities or can manually switch over a data center. - Each data center needs the following namespaces, depending on your client connectivity capabilities:
• Outlook Web App/OA/Exchange Web Services (EWS)/Exchange ActiveSync (EAS) namespace
• POP3/IMAP4 namespace
• RPC Client Access namespace
• SMTP namespace - Consider which data center will maintain the Autodiscover namespace.
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
- Single namespace with proxy sites
- Single namespace with multiple sites
- Regional namespaces
- Multiple forests
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:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access the Exchange server.
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:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access Exchange server.
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:
- The Client Access server proxy site approach includes Client Access servers based in a separate Active Directory site that is used to proxy the traffic to the site where the user’s mailbox is located. To configure this namespace model, you need to configure the ExternalURL option to the single namespace of the Client Access servers at all sites.
- The intelligent firewall approach uses an application-layer firewall such as Forefront TMG and decides during client authentication that the traffic is forwarded to the correct target site based on configured rules. To configure this namespace model, you need to configure the ExternalURL option to the single namespace of the Client Access servers at all sites.
This scenario has the following advantages:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access Exchange server.
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 client traffic is automatically optimized based on the region or site level. (For example, if you implement a namespace based on a city, all users of that city will use the local access.)
- Performance and end-user experience are optimized.
- Failover is provided if the regional namespace is unavailable by using a different namespace (if the Mailbox server of the site is still available).
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:
- Scenario 1—The primary DNS suffix of the domain controller is not the same as the DNS domain name. Computers that are members of the domain can be either disjoint or not disjoint.
- Scenario 2—The Exchange servers in an Active Directory domain are disjoint, even though the domain controller is not disjoint.
- Scenario 3—The NetBIOS domain name of the domain controller is not the same as the subdomain of the DNS domain name of that domain controller.
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:
- All disjoint domains need to be added to the msds-allowedDNSSuffixes attribute of your root domain.
- The DNS suffix search list must include all DNS suffixes, including the disjoint DNS suffixes.
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.
