Professor Windows - March 2002

Best Practices for Active Directory Design and Deployment

By Yossi Saharon
Reviewed By:
Stuart Kwan, Group Program Manager, Microsoft Corporation
Efi Bregman, Microsoft Consulting Services


Setting up Active Directory forests is a process requiring a proper dose of Design considerations and a well reviewed deployment plan. The purpose of this column is not to serve as a comprehensive design and deployment white paper, but rather to generally outline the main considerations you need to keep in mind in order to successfully deploy Active Directory forests in your organizations, including some of the important tips and known issues based on field experiences. The best practice approach is based on the experience gained by the Active Directory development team from organizations that have successfully implemented Active Directory. This approach shortens planning cycles by:

  • Promoting standard, tested Active Directory designs.
  • Focusing on design choices that are proven to work well in the Windows NOS management role.
  • Clarifying task milestones and the order of tasks with flowcharts and worksheets.
  • Providing scenarios to reinforce design concepts

For information on How to plan your Active Directory Design and Deployment, please refer to the Best Practice Active Directory Design and Deployment white papers.

I will also mention few Windows Server 2003 Active Directory enhancements in the relevant parts, so you can plan ahead and know what's coming up in the next Windows Server platform in the areas of design and deployment. I will mention a very partial list of the new upcoming features in Windows Server 2003 Directory Services. The latest milestone for Windows Server 2003 is Beta 3 (at the time of this writing).

This column is intended for IT Professionals that have a good understanding and knowledge of Active Directory concepts. In the scope of this column we cannot cover Active Directory architecture or take a deep level look at what Active Directory is. To get more technical information on what Active Directory is and how it works, try the following link:

Getting Started: Determining the Number of Active Directory Forests

First and foremost, as trivial as it may sound, always start with understanding the current environment and the organization's demands and needs. Your design plan needs to serve current as well as futuristic needs and plans. Over the course of your design you will be considering things like your namespace planning (naming conventions), the number and size of objects, physical branches and geographical locations, mergers/acquisitions etc. A forest design includes planning for domains, DNS, Organizational Units and physical topology (Sites).

Start by determining the number of forests. A single forest is the most simplistic and applicable implementation. It's optimal from a functionality point of view. It's efficient in terms of cost savings and resources. Yet, not every organization will find a single forest model to be sufficient. A forest shares a single Schema, Configuration, Global Catalog and complete trust between the domains inside the forest. Consider a single forest when there is agreement on who will control the schema and forest-wide configuration parameters, and when you know you can trust the forest owner(s) and domain owner(s). The DCs should be physically secured in any case. For more information, please read the "Design Considerations for Delegation of Administration" paper. There are a few implications on multiple forests design. There's no automatic trust between forests. Kerberos is not available between forests in Windows 2000. Cross-forest transitive trusts do exist in Windows Server 2003 though. Also, for the Global catalog to get forest scope aggregate a view across forests, a synchronization technology is required (e.g. MMS – Microsoft MetaDirectory Services). The impact on Exchange 2000, for example, will be that if there are multiple Exchange 2000 organizations (which map to AD forests) – each forest/organization will hold its own GAL (Global Address List) and will need to synch with the others. Another possible scenario that requires attention in respect to Exchange 2000 would be when you plan to have Exchange 2000 in one organization (one AD forest), yet you will have users from other forests using the Exchange 2000 Services in that forest.

Domain Planning

When we determine the number of forests, we continue with the Domains planning. Start by choosing the forest root domain. Also choose your domain model: a dedicated root model enables easy transfer of forest ownership and isolates forest administrators from ordinary administrators. In domain models, as with forests, a single tree is the simplest – in case there's no strong need for multiple trees or disjoint namespace. You can also partition domains geographically that will map to physical global locations. Mapping to geographical locations usually maps well to your network/WAN layout. It's also a stable model, since geography is relatively unchanging. Name your forest root domain and choose your DNS suffix while taking into account the limitations of the naming conventions: allowed characters are A-Z, a-z, 0-9, - (hyphen). Remember not to exceed the 15-character length for your prefix and NetBIOS names. Once you determine your DNS suffix, make sure you register it with your ISP. Even if you don't plan to use this suffix publicly in the internet today, you should own the DNS name you choose to implement throughout the organization.

DNS Best Practices

Step 3 is all about DNS planning. DNS is an important service in a Windows 2000 Active Directory domain, and is used in many operations, such as a DC locator mechanism. The requirements from the DNS server are that the authoritative DNS for the locator services for DCs must support SRV resource records. As a primary for the DCs locator services, it's also recommended that it'll support Dynamic updates (RFC2136). Windows 2000 DNS is a well tested implementation, of course. Other tested implementations are BIND version 8.1.2+ and Cisco's CNR 3.0, although the only DNS Server with support for secure dynamic updates is the Windows 2000 DNS Server.

You have three possibilities when connecting your DNS and AD infrastructure:

  • No existing DNS infrastructure
  • AD namespace doesn't overlap with DNS namespace (e.g. DNS is used for and AD will use, or
  • AD namespace overlaps with DNS namespace (e.g. is used both as the DNS zone and the domain name)

In case the namespaces don't overlap, simply delegate the zone to a Windows 2000 DNS Server (e.g. from DNS Server, delegate to the AD domain DNS Server). If you followed the best practice for name selection during the domain naming process, then all you have to do is delegate control over the name you selected to Windows 2000 DNS servers running on AD domain controllers

When using Windows 2000 DNS Servers, it's also recommended that you use Active Directory integrated zones. When your DNS zones are stored in AD, they are replicated to other Domain Controllers, and you can use secure dynamic updates. If you use AD integrated zones and you lose your DNS server, simply add the DNS service on another server and it'll read all the zones and registration information from Active Directory. One of the important best practices with DNS is to delegate the zone to all child domain DNS Servers and make them authoritative for this zone. You need to delegate this forest root zone and make all DNS servers authoritative for this zone while the Forest root DNS servers remain as primary and all other DNS servers are secondary for this zone. This delegation is important because if a remote site loses network connectivity to the rest of the enterprise, it enables location of the local Global Catalogs and replication partners (Domain Controllers).The following figure illustrates how this delegation looks:

If your browser does not support inline frames, click here to view on a separate page.

Figure 1 Delegating zone

As for DNS client configuration: Each client should be configured to query at least the two closest DNS servers. This enables fault tolerance and reduces network traffic.

It's also highly recommended that the Primary DNS Suffix of computers match the Domain DNS name. If they're not the same, Users still may access servers by their old names, but Kerberos authentication is not possible without manual updates of the server's computer account.

You can use DNSCMD.exe from the Windows 2000 support tools to perform many DNS related tasks from the command-line, such as enumerating zones, adding / removing records from DNS and more.

DNS in Windows Server 2003 will introduce some new enhancements such as Conditional forwarding and Stub Zones, plus some other new features. Windows Server 2003 will also include a Group Policy setting to control the client's DNS setting (e.g. DNS suffix, DNS Servers list).

For more in-depth information on DNS planning and deployment, please refer to the Best Practice Active Directory Design and Deployment papers.

Organizational Units

Organizational Units represent the logical structure of our Active Directory tree, while Sites, subnets and site links represent the Physical layout of our network. It's important to remember to differentiate between the logical and physical layouts during the design process.

Justify each and every OU (Organizational Unit) you add into your domains. Keep in mind that OUs are used to contain objects for purposes such as delegation of permissions, Group Policies and hiding objects or parts of the tree structure.

There is a detailed suggested OU model in the Best Practice Active Directory Design and Deployment papers.

Although there's no technical limit, it's recommended to limit your OU nesting to 10 levels of depth to avoid complexity in design and in the on going management of objects. Always remember that OU hierarchy does not have to mirror departmental hierarchy. It doesn't need to resemble your org chart, although you can do so if you justify this structure with proper reasons (e.g. delegation, group policies, etc.).

If an OU doesn't have a defined purpose, then it probably shouldn't be created.


The procedure for site planning should be as follows:

  1. Identify your physical locations
  2. Place DCs into locations based on their needs,
  3. Define locations with DCs as sites.

The PDC Emulator FSMO role DC should be placed in a Site with high network connectivity, and possibly in the site with the largest amount of users in the domain. Follow the recommendations of the Active Directory Branch Office deployment planning guide in case there are over 200 Sites and/or over 20 Site Links to a single location. The ISTG (Inter Site Topology Generator) needs to be turned off in certain cases in Windows 2000 where there are lots of sites, but it can be used in Windows Server 2003 due to performance improvements.

In addition, Windows Server 2003 will allow you to disable compression of replication traffic between sites, which is a good thing if you want to decrease the CPU usage on your replication partners (DCs). Keep in mind it does increase the amount of information being sent physically over the network.

Additional Tips and Best Practices

Always configure your DC's DNS client to point to the local server as the preferred DNS server and any other DNS server as the alternate DNS server. The exception here is with the Forest root domain DCs: These should point to other forest root DCs both as the preferred and alternate DNS server ("The Island problem" is the known issue here. Read the Microsoft Knowledge Base article Q275278 for more information). Configure the DNS client before you run dcpromo (except the first DC) and point to any existing DNS server before you run dcpromo. Re-configure the DNS client after a third domain controller is promoted.

It's a best practice to install Terminal Services, in remote administration mode, on your Domain Controllers, so you can manage them remotely. Install Service Pack 2, plus available hotfixes and keep your DCs up to date at all times. It's also recommended that you install the Windows 2000 Server Support Tools and the Windows 2000 Server Resource Kit Tools, which contain many useful tools to manage and troubleshoot your DCs. Some commonly known tools that can really help are DCdiag, NetDiag and Replication monitor (or repadmin, the command-line tool). A monitoring solution (Such a MOM – Microsoft Operations Manager) is highly recommended, especially in largely distributed networks, in order to know when your AD forest is "out of shape" in terms of performance and operations execution.

A few words on Flexible Single Master Operation (FSMO) roles offline scenarios, - Having the Schema, Domain Naming master and Infrastructure master offline for a short time does not affect the Directory Service. Essentially, the RID Master is also non-critical for a short period of time, unless you're planning bulk-operations (migrations) at the time of the outage. The RID master should be brought back on-line in a few hours, just to be on the safe side. The exception is the PDC Emulator role, which should be online always. For any of the other FSMO roles, transfer the role(s) to another server only when the role is needed urgently, and while perfectly understanding that the original server that held that role up till now is NOT coming back online into your network without a re-install.

The Active Directory Migration Tool (ADMT) is a free tool from Microsoft that can be used for domain migrations, and allows you to transfer users, groups, computers etc from Windows NT4.0 domains to a Native Mode Active Directory destination domain. ADMT can migrate user SIDs, so you can obtain your access permissions to resources in the source domain. ADMT version 2.0, which will be available later this year, will include the option to migrate from any Windows NT 4.0/2000/.NET domain to Windows 2000/.NET AD domains. It will include a new option to migrate user passwords. It will also be fully scriptable. Additionally, ADMT version 2.0 includes a command-line version of the tool, which allows you to do bulk migration from the command-line prompt.

A known issue in the deployment process is the "piling-on scenario". When the PDC is upgraded to Windows 2000, and there are still BDCs in your domain, all Windows 2000/XP Professional computers will only contact Windows 2000 domain controllers in a mixed mode domain (in this case, that single DC). There's a workaround for this issue and it's clearly explained in the Microsoft Knowledge Base article Q298713.


Please remember that this column is not a replacement for a fully documented and reviewed design and deployment plan (like, for example, a MSF – "Microsoft Solutions Framework"-based paper). For detailed information on how to effectively plan your Active Directory Design and Deployment, please refer to the Best Practice Active Directory Design and Deployment papers.

Forest design might be politically driven. Keep in mind the considerations for multiple forests, and that a single forest is the simplest and most functional design.

Delegate DNS to Active Directory. It's your best approach in terms of secure updates, management and replication unification.

Use OUs wisely – an OU without a purpose shouldn't be there in the first place.

Site topology reflects your network topology and affects replication times and latency, so plan it with the proper considerations taken.

And finally, do your capacity planning: estimate your work load and objects processing, while keeping in mind that Domain Controllers scale up very well (adding hardware to a single box), so scale up your DCs before scaling out (adding new DCs). In any case, you should never have any domain with less than two Domain Controllers. Remember: Multi-Master replication in Active Directory means each DC is a read-write replication partner which holds a copy of your whole domain and forest-wide data. This is your first fault tolerance barrier. Always back-up your DCs, of course, regardless to this knowledge.

Again, for more in-depth information I strongly encourage you to read our official design & deployment whitepapers mentioned in the related links section below.

Good luck with your Active Directory deployments!

Related Links

Best Practice Design and Deployment papers

Design Considerations for Delegation of Administration in Active Directory

Active Directory Branch Office Deployment Planning guide

Windows 2000 Deployment Planning Guide

For any questions or feedback regarding the content of this column, please write to Microsoft TechNet.