Support for DNS Namespace planning in Microsoft server products

Support for DNS Namespace planning in Microsoft server products

Help and support for namespaces in Microsoft products including Single Label Domains (SLDs), Disjoint Namespaces, and Discontiguous Namespaces.

Overview

This Solution Center provides information on the use of namespace in Microsoft server products, including deployments with Single Label Domains (SLDs), Disjoint Namespaces, and Discontiguous Namespaces

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.

Disjoint Namespaces
A disjoint namespace occurs when one or more domain member computers have a primary Domain Name Service (DNS) suffix that does not match the DNS name of the Active Directory domain of which the computers are members. For example, a member computer that uses a primary DNS suffix of corp.fabrikam.com in an Active Directory domain named na.corp.fabrikam.com is using a disjoint namespace.

Discontiguous Namespaces
Discontiguous namespace, also referred to as non-contiguous namespace, is one in which the domains in a forest are not lined up in one hierarchical DNS tree. 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.

Key Resources

Namespace Planning for Domain Name System (DNS)
An introduction on the basics of DNS planning. Includes instructions on choosing domain names, DNS namespace planning for Active Directory, and integration planning for supporting multiple namespaces.

DNS Namespace Planning
How to plan and create a DNS Namespace.

Namespace Planning Example
The article explains some of the issues must be considered when planning a namespace by describing the configuration of two fictitious organizations.

Checklist: Deploying DNS for Active Directory
A checklist detailing the steps that should be considered when deploying DNS for Active Directory.

Planning your Namespace
This article examines key issues that must be considered when planning a namespace, including whether to use a private root and whether internal and external namespaces should have the same domain name.

Single Label Domains in Active Directory Domain Services
This whitepaper explains options for transitionsing from an Active Directory domain that uses a single-label domain (SLD) name to a domain that uses a fully qualified domain name (FQDN).

Disjoint Namespaces

Disjoint Namespaces

A disjoint namespace occurs when one or more domain member computers have a primary Domain Name Service (DNS) suffix that does not match the DNS name of the Active Directory domain of which the computers are members. For example, a member computer that uses a primary DNS suffix of corp.fabrikam.com in an Active Directory domain named na.corp.fabrikam.com is using a disjoint namespace.

Other configurations are sometimes also described as “disjoint namespaces”, such as domains where the leftmost label in the AD DNS domain name does not match the domain NETBIOS name (e.g. DNS fabricam.com and NETBIOS fabricam.com). These configurations are not disjoint based on the definition of the Active Directory Team.

A disjoint namespace is more complex to administer, maintain, and troubleshoot than a contiguous namespace. In a contiguous namespace, the primary DNS suffix matches the Active Directory domain name. Network applications that are written to assume that the Active Directory namespace is identical to the primary DNS suffix for all domain member computers do not function properly in a disjoint namespace.

Key Resources

Namespace Planning for Domain Name System (DNS)
An introduction on the basics of DNS planning. Includes instructions on choosing domain names, DNS namespace planning for Active Directory, and integration planning for supporting multiple namespaces.

DNS Namespace Planning
How to plan and create a DNS Namespace.

Namespace Planning Example
The article explains some of the issues must be considered when planning a namespace by describing the configuration of two fictitious organizations.

Disjoint Namespace
This article provides support information for disjoint namespaces, as well as considerations for application compatibility and the advantages and disadvantages of disjoint namespaces.

Discontiguous Namespaces

Discontiguous Namespaces

Discontiguous namespace, also referred to as non-contiguous namespace, is one in which the domains in a forest are not lined up in one hierarchical DNS tree. 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 a special configuration. By default, they would both be using a NetBIOS name of contoso in their respective domains. You need to specify a different NETBIOS domain name, or the promotion into the same forest will fail. Both the DNS name and NETBIOS name must be unique in their own namespace and must follow the syntax for the name type. The choice of the DNS name is independent from the NETBIOS name, so you should use a custom name for the NETBIOS domain name.

A discontiguous namespace is more complex to administer, maintain, and troubleshoot than a contiguous namespace. In a contiguous namespace, the primary DNS suffix matches the Active Directory domain name. Network applications that are written to assume that the Active Directory namespace is identical to the primary DNS suffix for all domain member computers do not function properly in a discontiguous namespace.

Key Resources

Implementation of Trees in Active Directory
This article provides a description of a forest the logical structure of Active Directory.

Single Label Domains

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.

Although SLD is not a common configuration worldwide, some Microsoft products can be installed in an SLD and other uncommon namespace configurations; certain considerations may apply as noted by individual product groups. Existing products may continue to function with SLDs, but SLDs are not a recommended configuration for future deployments, and may not work with some products or versions. Other Microsoft or third party applications that end-users may wish to run in your environment may not be compatible on an SLD. Microsoft recommends that customers deploy infrastructure using common, tested configurations to minimize extra deployment and testing costs.

Key Resources

Microsoft Support for Single Label Domains
This article contains information about Microsoft’s support stance and ongoing Common Engineering Criteria (CEC) regarding uncommon namespace configurations, including SLD, disjoint name space, and discontiguous name space.

Information about configuring Windows for domains with single-label DNS names
This article contains information about deployment and operation of Active Directory domains that are configured with single-label domains and the effect that single-label domains may have on client computers, domain controllers, and server-based applications.

Administering Active Directory Domain Rename
This guide provides information about planning and performing a domain rename operation in Windows Server 2008.

Active Directory Installation Warnings in Domains with Single Label DNS Names
This article describes the warnings that may occur as a result of installing Active Directory Domain Services on Windows Server 2008 and Windows Server 2008 R2 in domains with single label DNS names.

Unable to Select DNS Server Role when Adding a Domain Controller into an Existing Active Directory Domain
This article describes how to troubleshoot auto-installing the DNS Server role in the Active Directory Installation Wizard when promoting a Windows Server 2008 or Windows Server 2008 R2 replica domain controller.

Single Label Domains in Active Directory Domain Services
This whitepaper explains options for transitionsing from an Active Directory domain that uses a single-label domain (SLD) name to a domain that uses a fully qualified domain name (FQDN).

Note: Active Directory, Single Label Domain (SLD) is not a Microsoft recommended configuration.

Product Compatibility

Product Compatibility

For more information about namespace compatibility for a particular product, please choose one of the products listed below:

BizTalk Server
Exchange Server
Forefront
Lync (Office Communications Server)
Office Outlook
Office SharePoint
Online Services (Business Productivity Online Standard Suite)
SQL Server
System Center
Windows Server

Migrating to FQDN

Migrating to Fully Qualified Domain Namespace

FQDN (Fully Qualified Domain Name) sometimes referred to an absolute domain name is a domain name that specifies its exact location in the tree hierarchy of the Domain Name System (DNS). It specifies all domain levels including the top-level domain, relative to the root domain.

Key Resources

Active Directory Migration Tool (ADMT) Guide
Microsoft provides a number of Active Directory migration tools to automate and guide you through the process of moving from an SLD Domain Name to a Fully Qualified Domain Name. This document provides guidance on performing migration of domains using the Active Directory Migration Tool.

Renaming a Domain: Process and Side Effects
This article describes how to safely rename a Windows NT domain. This will work for a single domain, or for an accounts domain or resource domain in a network using the master domain model.

Effects of Customer- User Account Migration on BPOS D/F
The purpose of this document is to clarify the types and methods that Microsoft Online does and does not support for migrating users, either intra or inter forest within their current Active Directory structure. It is also to advise BPOS-D/F customers of the potential consequences should a customer proceed in migrating a user domain account using a migration type and method that MS Online does not support. Scenarios of migrating users include but are not limited to users moving geographically, change in employee status, domain consolidation or migrating users from single-label domain (SLD) to a fully qualified domain (FQDN). A brief discussion of Microsoft Online future plans for supporting migration types and methods has also been provided in this document.

Last Review : August 19, 2011