Identifying and fixing disjoint namespace issues in Exchange Server

Disjoint namespace issues are complicated, but you can still deploy Exchange servers in this type of environment, if you understand the cause.

Even though Exchange Server deployments are relatively straightforward, the use of disjoint namespaces can complicate

the deployment process. Fortunately, you can configure Exchange to work in a disjoint namespace environment.

There are several different types of disjoint namespaces, but disjoint namespaces in Exchange environments usually refer to environments in which the primary domain name system suffix is different from the Active Directory DNS name. For example, my public DNS suffix in my own organization is BrienPosey.com. For many years, my internal domain structure consisted of a forest with such domain names as production.com and lab.com.

Disjoint namespaces can occur as a result of a few different conditions. In my case, my forest structure was created at a time when I never imagined I'd operate my own Exchange Servers. None of the servers on my network were intended to be Internet-facing, so I used domain names unsuitable for public use because I do not own the names. This was shortsighted on my part, but I have seen similar situations in a number of other networks.

Another common cause of disjoint namespaces is corporate mergers and acquisitions. If Company A buys Company B, then Company B might adopt Company A's external domain name while maintaining its original internal namespace.

Exchange Server support for disjoint namespace

Regardless of how a disjoint namespace happens, it's important to deal with it in a way Microsoft supports. There are three situations where Microsoft supports deploying or operating Exchange in a disjoint namespace environment:

  1. Microsoft will support an environment if a domain controller's primary DNS suffix is different from its DNS name. When this happens, it's acceptable for member computers to be either joint or disjoint (or a mixture of the two).
  2. It supports an environment in which domain controllers share a common DNS suffix and domain name. This doesn't make them a disjoint, but it separates member computers in the domain.
  3. Microsoft supports an environment when the NetBIOS name and subdomain name don't match. If the domain name is normally Contoso.com, the NetBIOS name for the domain is Contoso. Subdomains are domains such as Miami.contoso.com. Normally, a subdomain with this name would have a domain NetBIOS name of Miami. However, subdomain names and NetBIOS names can become disjoint, especially when resources are moved between domains.

Dealing with a disjoint namespace

The method you use to deal with a disjoint namespace depends on its nature and whether the disjoint namespace was intentional.

The most common type of disjoint namespace is a mismatch between an Active Directory domain and a DNS domain. If the mismatch isn't intentional, it's simple to configure a server to use a consistent namespace.

The exact steps you will follow depend on the version of Windows Server being used. In Windows Server 2012, right-click the Start icon, then choose the System option. When the System window appears, locate the Computer Name, Domain and Workgroup Settings section, then click on the Change Settings link.

Click the Change button to reveal the Computer Name/Domain Changes dialog box and click More. Select the Change Primary DNS Suffix When Domain Membership Changes checkbox and click OK (see Figure 1).

DNS Suffix and NetBIOS Computer Name
Figure 1. Select the Change Primary DNS Suffix When Domain Membership Changes checkbox.

If the disjoint namespace is intentional, you'll need to make sure an Active Directory attribute named msDS-AllowedDNSSuffixes contains the correct DNS suffix. Begin the process by using the procedure outlined above and make sure the Change Primary DNS Suffix When Domain Membership Changes checkbox is unchecked.

The rest of the process involves using the ADSI Edit tool. Keep in mind that ADSI Edit bypasses the normal safeguards that are in place for your Active Directory, so making a mistake can have catastrophic consequences. It's critical to have a full backup of your Active Directory before you continue.

Attribute Editor
Figure 2. Select the msDS-AllowedDNSSuffixes attribute.

After you have a full backup, open ADSI Edit and double-click on the partition for the domain you need to modify. Right-click the domain's container object and select the Properties command from the shortcut menu. When you do, you will see the domain's properties sheet. Select the msDS-AllowedDNSSuffixes attribute and click Edit (see Figure 2). Enter the DNS suffix you want to add and click Add, followed by OK. If necessary, you can add multiple DNS suffixes.

Disjoint namespaces can complicate things, but it's still possible to deploy Exchange in that environment. The key is to understand the nature of the disjoint namespace and how to correct it if necessary.

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 health care 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.

This was first published in October 2013

Dig deeper on Exchange Server Deployment and Migration Advice

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close