AD Design: Best Practices

I've been working a few months ago on a AD design for a customer of the company I work for. The AD was not huge, but it was more than just a little 1 forest, 1 tree, 1 domain Active Directory. In the end, the short summary is a single forest, with a empty root domain and 2 child domains.

Of course, for this, lots of documentation need to be read (and created), lots of collaboration, meetings, ... You know, the usual stuff.

I have now created a summary of Best Practices of various documents I've read, which I think make up the ultimate "Best Practice" for AD Design.
These are just copy pastes of various, publicly available documents, so I'm not trying to take any credit for these great "Best Practices".


Forest Design Best Practices
The forest design process includes the following best practices:
• Identify the number of forests and write a justification for each one.
• Identify the number of trees and write a justification for each one.
• Wherever possible, create a Protected Forest Root Domain.
• Wherever possible, create a Single Global Child Domain for production in each tree.
• Identify the number of additional domains required in each tree.
• Identify the scope and contents of each domain.
• Justify each domain.
• Choose the generic name for each domain.
• Once the domain structure for the production forest is complete, design the domain structure for the other forests you created.

Naming Best Practices
Use the following best practices to name your AD forests:
• Use standard Internet characters. If they work on the Internet, they will definitely work in your network. Avoid accents and solely numeric names.
• Use 15 characters or less for each name.
• For the root name, use a simple, short name that is representative of the identity of the organization.
• Follow all DNS standards and make sure the internal DNS name is different from your
external name.
• Finally, before proceeding, buy the name.

Production OU Design Best Practices
Keep the following rules in mind when you create OU structures:
• Think in terms of equipment and objects in the directory.
• Determine how you will implement the administrative delegation process.
• Identify standards for all administrative categories in the organization.
• Use the administrative service or function or the line of business to name OUs. These tend to be more stable than organizational structure.
• Limit your structure to five levels, three if you are not responsible for the finalization of the structure. Recommend a maximum of five levels even though ten are possible. This gives you some breathing room.
• Remember the four reasons for the creation of OUs: categorization, administration, delegation, and segregation.
• Each OU you create must add value to the system.
• Never create an OU that does not contain any objects.
• Never create an OU that does not have a specific purpose.
• If an OU reaches an empty state, consider removing it. This may not be necessary because it may only be temporarily empty. If not, remove it.
• Identify an OU owner for each one you create. If no owner can be identified, remove the OU
• Justify all OUs you create.
• If you find that two OUs have the same purpose, merge them. This means that the combination of owner plus GPO plus delegation strategy is the same for both OUs.
• Use default OUs to administer the whole domain. Domain controllers should be kept in the DC OU. Domain Administrator accounts and groups should be kept in the Users OU. Domain Administrator PCs should be kept in the Computers OU.
• Use the production domain OU strategy to define the OU strategy for other domains and forests.
• Don’t forget to define and put in place standards for the recurring creation and deletion of OUs. These will help control the proliferation of OUs in your directory.

AD Integration Best Practices
Use the following best practices during this process:
• Active Directory should be the core directory service. AD can be modified through a graphical interface. You can also use scripts to perform massive modifications with AD. AD also supports a powerful delegation model. Finally, it supports PC management, something few directory services can perform.
• Use AD as your single point of interaction. AD provides a single point of interaction because it is a distributed database that uses a multimaster replication process. Users can modify data in any regional office and it will automatically be updated through the directory.
• If you need to maintain data integrity between multiple directories, use Microsoft
MetaDirectory Services with Active Directory as your primary data source.
• If you need to install NOS-related applications that modify the schema, add them to the forest root domain before creating the child domains.
• If you need to integrate in-house applications to the directory, use AD in Application Mode. This will have no impact on your NOS directory.
• Integrate NOS-related and other applications to AD only if it is absolutely required. Schema modifications can be retired and reused, but only through a complex process that will involve replication throughout your distributed NOS directory.
• Maintain your Active Directory as a NOS directory first and foremost. This will limit the amount of replication in the forest and will make it easier to upgrade to future versions of Windows server operating systems.

Service Positioning Best Practices
Use the following rules to design your Service Positioning scenario:
• In large AD structures, place the forest-wide Operation Masters in a Protect Forest Root Domain.
• If your forest spans multiple sites, place the Schema Master in one site and the Domain Naming Master in another.
• Carefully protect the access to the Schema Master role.
• Place the RID Master and the PDC Emulator roles on the same DC.
• Create a dedicated PDC Emulator role in domains that have more than 50,000 users.
• Separate Global Catalogs and Infrastructure Masters if you can.
• Place at least two domain controllers per domain.
• If a small domain spans two sites, use at least two domain controllers, one for each site.
• Place a Global Catalog server in each geographic site that contains at least one domain controller.
• Enable Universal group membership caching in each geographic site.
• Place a domain controller wherever there are more than ten users unless the WAN link speed will adequately support remote logon attempts
• Add a regional domain controller whenever there are more than 50 users per DC, especially if it is a multipurpose server.
• Install the Domain Naming Service on every domain controller.
• Use application partitions to designate DNS replication scopes.

Best Practices for Site Topology Design
Use the following best practices to design your site topology:
• Use the default configuration for inter-site replication.
• Do not disable the Knowledge Consistency Checker.
• Do not disable transitive trusts.
• Do not specify Bridgehead Servers.
• Calculate replication latency between sites.
• Create sites according to network topology; Site Links and WAN links should correspond.
• Make sure that no single site is connected to more than 20 other sites.
• Each site must host at least one DC.
• Do not use SMTP for domain-centric replication.
• Do not use SMTP replication if at all possible.
• Use 128 Kbps as the minimum WAN circuit for a Site Link.
• Associate every site with at least one subnet and one Site Link, otherwise it will be unusable.
• Create backup Site Links for each site. Assign higher costs to backup Site Links.
• Create Site Link Bridges wherever there are two hops between sites to reduce replication latency.
• If your available network bandwidth can afford it, ignore replication schedules in all sites. Replication will be performed when required with this option, but it will be more demanding on WAN bandwidth.
• Enable Universal Group Membership Caching in all sites.
• Use Preferred Bridgehead Servers only if replication must cross a firewall.
• Size your DCs accordingly.
• Monitor replication once your forest is in place to determine the impact on your WAN links.

Schema Modification Strategy Best Practices
Use the following schema modification best practices:
• Don’t make your own modifications to the schema unless they are absolutely necessary.
• Use AD primarily as a NOS directory.
• Use AD/AM to integrate applications.
• Use MMS 2003, Standard Edition to synchronize AD and AD/AM directories.
• Make sure all commercial products that will modify the schema are Windows Server 2003 Logo approved.
• Limit your initial modifications to modifications by commercial software.
• Create a Schema Change Policy Holder role early in the AD Implementation Process.
• Document the Schema Modification Policy and Process.

Enjoy!