Windows Server Guides

Namespace Considerations

• Woodworking Plans With Step-by-step Instructions

AD uses the DNS namespace as the basis for naming AD domains. Careful planning of the namespace will invariably make it easier to expand AD into new trees and domains, and will also make it easier to access resources using intuitive names. Ease of adding child domains as your network grows will prove critical in the Active Directory namespace life cycle.

Choosing a naming structure most appropriate for your organization will undoubtedly be influenced by the business factors. Obviously, domain names should somehow correspond to what the company is doing, and in many cases it will be necessary to work with existing domain names. It is likewise necessary to honor logical and physical business division needs, for ease of use, security, administrative, and other purposes. It will also help to know what the company plans are for the immediate and longer-term future, if it is growing (naturally or through acquisitions), if it is planning partnerships or subsidiary spin-offs, and so on.

Windows Server 2008 allows renaming domains—something that was not easily available prior to Windows Server 2003. However, even though it is a built-in feature, domain restructuring on a larger scale is not a trivial task. This feature is intended more for unplanned circumstances; architects and administrators are still strongly advised to plan ahead. Though this might take more time in the rollout phase, it will certainly pay off in the long run. AD hierarchy begins with the forest root domain, sometimes referred to as either the forest domain or the root domain. Its purpose is to initiate the AD namespace, and in practice, it is often left empty— that is, not used for storing actual user or application objects. Since every other domain in this forest will inherit the name of this parent container, this is the most critical part in creating the namespace. Table 3-2 summarizes the advantages and disadvantages of several namespace strategies.

It is recommended that you plan your AD structure first, and then create DNS subdomains to reflect your AD planning results. This may be somewhat difficult to accomplish in environments where the DNS structure is already in place. In this case, it is still recommended that you plan the AD structure first, and then either use a DNS subdomain or a completely separate namespace for the purpose of maintaining the AD infrastructure. Keep in mind that the external namespace should not collide with your internal namespace, or it may cause some name resolution problems for your users. This is why it is recommended to either register your DNS domain name to be used as the AD namespace, even though you might not be providing any network services to external clients, or use a name such as .local that is not possible to query outside of your network without establishing some sort of relationship beforehand.

TABLE 3-2

DNS and AD Namespace Strategies

TABLE 3-2

DNS and AD Namespace Strategies