In response to customer feedback, the Exchange team has updated their testing matrix and has determined that Exchange Server 2010 will be supported on Single Label Domains (SLD), Disjoint Namespaces, and Discontiguous Namespaces. This post contains a brief description of each of these scenarios and special considerations. If you intend to install Exchange 2010 into one of these environments you need to read the documentation about the applicable subject.
In adding support for these types of topologies, there is an underlying requirement for DNS to be properly installed and configured. Before proceeding with any deployment defined here, clients and servers must be able to reliably resolve DNS queries for a given resource in the appropriate namespace.
Single Label Domains
Single-label DNS names are DNS names that do not contain a suffix such as .com, .corp, .net, or .org. For example contoso would be an SLD while contoso.com, contoso.net, or contoso.local would not be an SLD.
Not a recommended configuration
While Exchange 2010 is supported with SLDs, the Exchange product team's view is that SLDs are not a recommended configuration, and may not be supported by future Exchange versions. Other Microsoft or third party applications that you want to run in your environment may not be supported on an SLD. This could have an adverse effect on your environment. While we will allow installation of Exchange 2010 in an SLD, we strongly recommend that you take steps to move your organization out of this configuration.
A disjoint namespace scenario is one in which the primary DNS suffix of a computer does not match the DNS domain name where that computer resides. The computer with the primary DNS suffix that does not match is said to be disjoint. Another disjoint namespace scenario occurs if the NetBIOS domain name of a domain controller does not match the DNS domain name.
Exchange 2010 and Disjoint Namespaces
In Microsoft Exchange 2010, there are three supported scenarios for deploying Exchange in a domain that has a disjoint namespace. The supported scenarios are as follows:
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 A member computer in an Active Directory domain is 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.
A discontiguous namespace, also referred to as non-contiguous namespace, is one in which the domains in a forest are not defined hierarchically. If the domains in a forest have discontiguous DNS names, they form separate domain trees within the forest. An Active Directory forest can have one or more domain trees. An example of a multi-tree forest would be a forest containing the domains, contoso.com and fabrikam.net. Note: contoso.com and contoso.net in the same forest would be an invalid configuration. This is because they would both be using a NetBIOS name of contoso in their respective domains. In the case of discontiguous DNS namespaces, each domain must still register a unique legacy NetBIOS domain name.
For discontiguous namespaces, DNS must be configured such that Exchange servers are able to resolve all domain names in the environment. It is also a requirement that msds-allowedDNSSuffixes be configured within the Active Directory environment for all namespaces used within the forest. For instructions on configuring this, please see the Tech Net article "Understanding DNS Client Settings."