Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Server

Windows Server 2003 on HP ProLiant Servers : Logical Structure Design (part 1) - Domain and OU Structure

1/30/2013 5:52:07 PM

When you develop the logical design, it is essentially the development of the forest and domain structure, including the OU structure, Global Catalog (GC) server planning, naming standards, Group Policy, and trust definitions. The fundamental components of the logical structure are illustrated in Figure 1.This section deals with logical design details needed in developing a new AD structure, as well as considerations if you already have a Windows 2000 domain structure in place. In today's business climate of seemingly continual mergers and acquisitions, few companies can consider their forest structure set in stone. In addition, the experience the Windows community has gained since the release of Windows 2000, along with new capabilities of Windows Server 2003, has provided motivation to re-evaluate the forest structure.

Figure 1. The AD logical structure.

Your organization's logical structure includes the forest structure, domain structure, and OU structure, and is commonly referred to as the design of the namespace. These elements form the foundation for all other aspects of AD, so it's critical to incorporate the right design for your organization.

1. Domain and OU Structure

The three basic domain structures illustrated in Figure 2 are the single domain model, the multiple domain model in a parent/child relationship, and the multiple domain model in a multiple domain tree relationship. In each model, OUs are used to create subdomain organizations for more granular administration and security purposes. Note that OUs contain nearly anything a domain can contain, including users, computers, printers, groups, shares, Group Policies, and even other (nested) child OUs. Administration of the OUs is delegated from a higher-level container (domain or parent OU).

Figure 2. Basic domain structures in AD.

This section details the differences and design considerations of multiple- versus single domain models. The decision really rests with the question “Can I accomplish my design criteria more effectively with OUs or domains?” To help determine this, refer to Table 1 to compare features of domains and OUs. Note that multiple domains are clearly more rigid and add to the complexity of the AD, as well as being more costly because you must add servers to create and support the additional domains.

Table 1. Domain and OU Feature Comparison
CostMore expensive because additional servers must be employed as DCs. Administrative costs, including problem troubleshooting, also increase.No additional hardware or additional cost required.
Ability to createMust have enterprise admin privileges, additional hardware, and so on. Not trivial.Easily created—compare to creating a folder and adding objects. This right can be delegated.
Ability to renameNot possible in Windows 2000. Possible in Windows Server 2003, but very complex.As simple as renaming a file or folder.
Ability to deleteMust go through the DCPromo demotion process, and requires enterprise Admin privileges.As simple as right-clicking the icon in the snap-in and deleting it.
Group PolicyApply to domains. Default domain policy created. Account security is enforced only from the domain-level policies.Apply to OUs. No default OU policy. Account security cannot be enforced at the OU level; instead, the account security policies as defined at the domain level are applied to all OUs. Group Policy applies only to the OU where the user or computer account exists.
AdministrationCan delegate certain functions, such as DNS administration. Domain Admin has authority over all OUs.OU Admins can have rights delegated as desired by the domain Admin.
ReplicationSignificant impact—expands the replication topology, adds latency, affects the topology design, and requires more network bandwidth and administration, including monitoring and troubleshooting.No impact on replication, bandwidth, or topology. Some troubleshooting impact for applying Group Policy and user rights.


OUs are significantly restricted, in that even though it is available in the Group Policy Editor, account security cannot be applied at the OU level. For example, you cannot set the Maximum Password Age to 60 days on the domain level and then set it to 30 days at an OU. Actually, you can set it at the OU, but it won't apply. This applies only to the Account Security settings and not to User Rights or Audit Policy or any other setting configured in a Group Policy. Windows Server 2003 does not change this behavior.

This behavior is noted here because this security restriction could dictate the necessity of creating domains rather than OUs if separate password policies are required for different business entities. However, if different business entities truly have different security requirements, it might be more advisable to create multiple forests, instead of different domains.

Microsoft has been advising customers even before Windows 2000 was released that the best AD design strategy was to begin with a single domain and prove you need more. After nearly five years of experience with AD, we can say that this design principle is still true. That is not to say that a single domain will always suffice, but that exercise will force you to justify additional domains.

Single Domain

The single domain, as illustrated in Figure 3, is well suited for small- or medium-size companies with simple business organization models, as well as a large global enterprise. Microsoft itself implemented a multiple domain model and is now attempting to collapse it to a single domain model for security reasons. Remember that the key design principle is to create domains representing entities that do not change, and to use OUs for entities that do change (such as business units). Business unit names, location in the organization hierarchy, and subordinate organizations not only change, but also sometimes disappear altogether.

Figure 3. Single domain structure.

Creating domains based on business entities guarantees a lot of work for the system architect and Administrators, because changing organization structure and department names require changing the domain structure and names. As I worked with companies to design their AD models, it became clear that the most popular domain model is to name domains after geographical entities, such as Americas, North America, South America, Latin America, EMEA (Europe, Middle East, Africa), and Asia Pacific. As one designer noted, “The globe never changes.”

Thus, it becomes easy to see that a company just doing business in a single country or region would be a good candidate for a single domain model. College campuses would fit well in this example. Some features that qualify you for a single domain model include

  • Centralized administration: Managing a single domain makes life much easier for Administrators if they operate in a central location.

  • Small number of remote sites: Remember that a single domain contains all objects and attributes in the AD that must be replicated to all DCs in the forest. Multiple domain models partition the AD to reduce replication traffic, although GC servers hold about 70% of the data from each domain in the forest. Windows 2000 had limits of a single Bridgehead Server (BHS) per domain per site with no load balancing, requiring manual intervention. 


    Windows Server 2003 contains significant improvements in replication performance that eliminate barriers that existed in Windows 2000 . The new application partition feature allows you to partition the AD independently of the domain level and replicate independently between any specifically targeted DCs in a forest. By default, this feature is used to replicate the DNS data stored in AD only to those DCs that are also running the DNS service. If the AD schema is to be extended to hold a lot of special data for your company's applications, you are now able to sufficiently control replication of this AD data using application partitions across domains, which might make single domains even more attractive.

  • Monolithic business model: Organizations such as holding companies or corporations with multiple independent business units will not benefit from a single domain model. Rather these organizations will likely use a multiple forest model. A simple business organization without these complexities lends itself to a single domain.

  • User population: There has never been any limit—real or practical—on the number of objects that can effectively be put into a single Windows 2000 or 2003 domain. HP built a domain in the early days of Windows 2000 that had more than 100 million objects (mostly users) with no significant degradation of performance as the number of objects increased. The single domain models I've seen are typically fewer than 40,000 or 50,000 users. However, that seems to be a result of taking other factors noted here, such as business structure, administration model, and so on, that tend to limit the size of the company and thus the user community. I don't know of a single instance in which the number of users was the sole design criteria for determining a single or multiple domain model.

Although Microsoft and experienced AD architects usually recommend that you start with a single domain model and then prove you need more domains, there are some very good reasons to implement a multiple domain model, as described in the next section.

Multiple Domains

Multiple domain structures are probably the most common AD configuration. Even in small organizations, multiple domains can have advantages. As I noted in the “Single Domain” section, multiple domain models are almost always named after geographical entities. One of the design practices to evolve as Windows 2000 was deployed in the past few years is the role of the empty root domain, also referred to as a “ghost” or “placeholder” domain. This domain contains enterprise Admin and schema Admin accounts, and serves as the forest root domain, which holds the domain structure together. It can be implemented either as a parent to the other domains or a separate domain tree, as shown in Figure 4. Compaq implemented a placeholder domain in a parent-child relationship. Figures 5 and 6 illustrate how Compaqtrimmed more than 1,300 resource domains and 13 master user domains (MUDs) to a simple 4-domain structure in a parent-child relationship.

Figure 4. The empty root domain can be implemented in a parent-child structure or as separate domain trees.

Figure 5. Compaq's Windows NT domain structure (prior to merger with Hewlett Packard).

Figure 6. Compaq's Windows 2000/2003 domain structure. HP was migrated into this structure after the merger. This is the current HP Windows Server 2003 domain structure.

I know consultants who have advised their customers to create a placeholder domain even if a single domain model would be sufficient. Their reasoning was for expansion. In reality, if you did create a single domain and later wanted to implement a placeholder domain structure,you could create additional domains and leave the original as the placeholder, migrating users, computers, groups, and so on to the other domains.

Consider the case of the Georgia (United States) Department of Transportation (GDOT),  which moved from a multimaster full mesh Windows NT domain model (shown in Figure 7) to a two-domain model with an empty root for its Windows 2000 infrastructure (shown in Figure 8). Essentially, this is a single domain model because GDOT employs a placeholder domain as a root domain, which contains only enterprise Admin accounts. GDOT replaced the Windows NT resource domains with OUs. Consider the simplicity of the new domain model. Note also that GDOT has migrated now to Windows Server 2003 without modifying its AD structure.

Figure 7. GDOT's Windows NT multimaster domain structure.

Figure 8. GDOT's Windows 2000 and Windows Server 2003 domain structure. Originally designed for Windows 2000 and did not change for Windows Server 2003.

A structure of this nature gives the simplistic advantage of a single domain with the flexibility of a multiple domain structure.

However, even though the empty root + one or many child domain structure has often been implemented in the past, the rising security awareness of Microsoft and companies using these infrastructures (including HP) has taught us some clear disadvantages of this AD design. Companies that have not yet deployed AD in their enterprise should especially take the following drawbacks into consideration when deciding between creating multiple domains within their forest (including the empty root domain) or multiple single-domain forests if one single domain forest won't meet their needs:

  • Disaster-recovery practices, including restoring deleted objects, are more complicated and lengthened. For example, special recovery mechanisms are required to restore group memberships in universal or domain local groups of other domains in the forest; the order of operation becomes very relevant for forest-recovery scenarios needed to differentiate between rebuilds of GC versus non-GC DCs.

  • Replication topology is more complex due to a larger number of connection objects.

  • Token evaluation on GCs. Token evaluation depends upon the domain in which a GC resides. This can cause intermittent and difficult to troubleshoot application failures.

  • Trusts between forests (that is, between the root domains of the forests) that are not at Windows Server 2003 forest functional level behave like Windows 2000 cross forest trusts; that is, they are not transitive and need to be created between each participating domain.

  • When creating forest trusts (at 2003 forest functional level), they lack the visibility of child domains in logon dialogue (even if trust is transitive to child domains, users from “other” forests have to log on using their User Principal Name [UPN]).

  • Additional DCs (security event logs, capital and licensing costs, Syskey, restore mode password management).

  • More Flexible Single Master Operation (FSMO) role holders to manage and monitor as each domain has a PDC (Primary Domain Controller) Emulator, an RID master, and an infrastructure master.

  • Duplication of policy for each domain. Domain-specific processes have to be executed multiple times (for example, if you want to ensure Global Policies in a forest).

  • A more complex namespace is always more difficult to understand for help desk and other support staff and can thus increase troubleshooting efforts.

  • More administrative and service accounts, which potentially increase the attack surface of an AD forest. Every domain Administrator of any child domain could—by the nature of how security in AD is designed—elevate his privileges to become an enterprise Administrator. As such, multiple domains could potentially decrease the security of an AD forest.

  • Not-well-known security issue: Kerberos tickets can still be requested by and obtained for the disabled user in trusted domains within the forest (because DCs of the trusted domains do not check the status of an account when granting Kerberos tickets to access resources in their domain).

Other -----------------
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Ensuring proper year-end closing by checking Posting Types
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Preventing account selection errors with Chart Segment names
- Monitoring Windows Small Business Server 2011 : Using Windows SBS Console Monitoring (part 3) - Creating and Viewing Reports
- Monitoring Windows Small Business Server 2011 : Using Windows SBS Console Monitoring (part 2) - Using Notification Settings
- Monitoring Windows Small Business Server 2011 : Using Windows SBS Console Monitoring (part 1) - Using the Network Essentials Summary
- System Center Configuration Manager 2007 : Operating System Deployment - Boot Images
- System Center Configuration Manager 2007 : Operating System Deployment - Site Systems
- BizTalk Server 2006 : Pipeline Component Best Practices and Examples - The Databased Disassembler
- BizTalk Server 2006 : Pipeline Component Best Practices and Examples - Using PGP (part 2) - PGP Decode Component
- BizTalk Server 2006 : Pipeline Component Best Practices and Examples - Using PGP (part 1) - PGP Encode Component
- Microsoft Dynamics CRM 4.0 : Using Microsoft Dynamics CRM with Microsoft SharePoint
- Windows Server 2003 on HP ProLiant Servers : Defining the Windows 2003 Infrastructure
- Microsoft Content Management Server : Implementing Server-Side Validation
- Microsoft Content Management Server : Preventing Pages with Invalid Content from Being Saved
- Microsoft Systems Management Server 2003 : Permissions and Security Objects (part 2) - Assigning Permissions
- Microsoft Systems Management Server 2003 : Permissions and Security Objects (part 1)
- Microsoft Systems Management Server 2003 : Security - Accounts and Groups
- Windows Server 2003 on HP ProLiant Servers : Assessment of the Enterprise - Conducting the Assessment
- Windows Server 2003 on HP ProLiant Servers : Assessment of the Enterprise - The Assessment Team
- Windows Small Business Server 2011 : Disaster Planning - Preparing for a Disaster, Restoring from Backup
Most view of day
- Windows Phone 8 : Orientation and the PhoneApplicationPage Class (part 5) - Animating the Entire Page When Orientation Changes
- Using OneNote with Other Programs : OneNote Integration with Outlook (part 2)
- Microsoft Systems Management Server 2003 : Security - Accounts and Groups
- Microsoft Dynamics GP 2010 : Preventing Errors in Dynamics GP - Ensuring proper year-end closing by checking Posting Types
- Windows Server 2008 : Working with the Schema - Modifying the Schema with adprep, Registering the Active Directory Schema Snap-In
- Microsoft Exchange Server 2010 : Setting Up Transport Rules (part 5) - Creating New Rules with the Exchange Management Shell
- Protecting Windows from Viruses and Spyware : Antimalware Strategy: Defense in Depth (part 3) - Data Execution Prevention
- Adobe Dreamweaver CS5 : Using Java Applets
- Microsoft Exchange Server 2013 : Mailbox management - Setting mailbox permissions (part 1) - Mailbox delegation
- Microsoft OneNote 2010 : Using the Research and Translate Tools (part 1) - Setting Options for the Research Task Pane, Searching with the Research Task Pane
Top 10
- Windows Phone 8 : Scheduled Tasks - Scheduled Task API Limitations
- Windows Phone 8 : Scheduled Tasks - Updating Tiles Using a Scheduled Task Agent
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 5) - Editing an Existing To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 4) - Creating the To-Do Item Shell Tile, Saving a To-Do Item
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 3) - Debugging Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 2) - TodoService, TodoItemViewModel
- Windows Phone 8 : Scheduled Tasks - To-Do List Scheduled Task Sample (part 1) - TodoItem,TodoDataContext
- Windows Phone 8 : Scheduled Tasks - Using Scheduled Tasks
- Windows Phone 8 : Scheduled Tasks - Background Agent Types
- Windows Phone 8 : Windows Phone Toolkit Animated Page Transitions - Reusing the Transition Attached Properties
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro