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

Windows Server 2003 on HP ProLiant Servers : Logical Structure Design (part 2) - Forest Structure, OU Structure

1/30/2013 5:54:30 PM

2. Forest Structure

Just as there are business and technical reasons for creating a single- or multiple-domain forest, there are also reasons to create a single- or multiple-forest AD infrastructure enterprise. Some say AD domains are security boundaries just like they were in Windows NT, and in a very limited sense they are; for example, for defining password policies. However, it is well known today that the true security boundary is at the forest level. In the beginning of Windows 2000 deployments, there were few multiforest deployments. However, a number of multiforest environments exist today and there are good reasons to employ such a structure. It was noted in the discussion on domain design that you should start with a single domain and prove you need more. This rule is even more important in regard to designing the forests.

Although there are many issues to consider in the single versus multiple domain debate, there are only a few when deciding whether you should use a multiple forest environment. It basically comes down to two issues: political and security. Microsoft defined the security issue with the following statement (from “Using the Organization Forest Domain Model” Web site article):

“Domain owners have authority over the entire domain, as well as access to all other domains in the forest. For this reason, domain owners must be trusted individuals selected by the forest owner...Keep in mind that if a forest owner delegates domain-level service management to a domain owner, then other groups might choose not to join that forest if they do not trust that domain owner. All domain owners must be aware that if any of these conditions change in the future, it might become necessary to migrate the organizational domains into a multiple forest deployment.”

This statement describes the importance of trust in those who are domain Administrators and the important security rights they have in the forest. It also points out that if others in the organization do not trust a domain Administrator, it may be cause for creating a separate forest. One government official I talked to several years ago was configuring a test environment to prove he could control security of data in a single domain. Because the implementation of Windows 2000 involved several government departments, if he lost his case, it could mean the creation of about 20 forests.

In addition to security reasons, there can be political, business, or even legal reasons to deploy a multiple-forest enterprise. In analyzing these reasons, perhaps it's easiest to outline the negative impact of multiple forests. The strongest arguments against a multiple forest deployment are administration and implementation of Exchange.

A good example of resolving the multiple forest issue is demonstrated in an AD design project I was involved in. This was a fairly small company that included an autonomous business unit. One business unit, we'll call it ABC, had a legal requirement to be separated from the rest of the company.

It seemed after the assessment, that the rest of the company could adopt a single domain in a forest. However, an engineering division had operated Windows NT domains independently of the IT department. The IT department managed the Windows NT environment for the rest of the company. The research division was lobbying for a multiple-forest environment to retain this autonomy, making an enterprise of three forests, all running on the same physical network. The IT Administrators, however, wanted only one additional forest in addition to the ABC forest. This discussion became very political, and my partner and I were asked to make a presentation to describe the pros and cons of a multiple-forest deployment. The reasons to have multiple forests include

  • Maintain absolute security autonomy: The forest is a definite security boundary. However, a trust can be built to allow one or more groups or users access to resources in another forest. This really boils down to the use of the enterprise Admin account, which cannot be restricted from any domain in the forest, although there are certain rights it doesn't have. If no account can have access across certain domains, then multiple forests are required.

  • Business autonomy: Business requirements might be such that data and security must be separated as though they were separate companies. One company had seven forests—one for each business unit. A holding company might employ a multiple forest structure for this reason.

  • Administrative autonomy: As Microsoft noted in the article we quoted previously, Administrators that are not trusted by other domains can lead to multiple forests. Note that you should work this out rather than make multiple forests. This would have to be a very serious issue to justify the added cost of another forest.

  • Business partner relationship: Perhaps you have a business partner that you want to share data with. Establishing a separate forest and controlling access via trusts would ensure security for each company.

  • External Web farms in a Demilitarized Zone (DMZ): Many companies deploy Web farms that exist in a DMZ for security. In addition, it's difficult to replicate through a firewall, thus making a separate forest desirable.

When analyzing the reasons to deploy a multiple-forest structure, weigh the negative aspects associated with multiple forests, as noted in Table 2.

Table 2. Comparison of Single and Multiple Forest Features
FeatureSingle ForestMultiple Forest
Enterprise Admins groupNo way to restrict members of this group in any domain in the forest.Enterprise Admin rights restricted to the forest their accounts exist in, unless a trust is built and specific rights assigned.
Replication topologySingle topology—adding more components for additional domains or sites is much less demanding than an entire new forest.A separate topology is required for each forest. Forests cannot share common sites, site links, and so on. This can impact the network bandwidth.
Kerberos cross forest trustNot applicable.Allows a single trust to be established at the forest level and honors the transitive trusts of each forest. Rights can be restricted or wide open. This is animportant feature.
Hardware costsOnly applicable if additional domains are created.Requires considerably more hardware to establish new domains, multiple DCs in each domain, and so on (same as creating multiple domains in a single forest).
AdministrationEach Admin needs only one account and appropriate rights added.A cross forest trust (Windows Server 2003 only) allows accounts to have rights in multiple domains. Windows 2000 allows this, but requires a separate trust between each pair of domains, increasing administration of the trusts.
Trust managementAll trusts are created and maintained without Administrator intervention.Requires manual creation and maintenance of external trusts. Windows Server 2003 permits a single root- level trust. Windows 2000 requires separate NT LAN Manager (NTLM) trusts between each pair of domains.
Time servicesCan be synchronized automatically between all domains and maintain security for authentication time stamp.Must be synchronized manually between domains (can use same external time source). Security for authentication time stamp only within each forest itself.

After presenting these issues to technical and managerial participants in the meeting, they kept pressing me to boil it down further. After reviewing their business and political environment, I decided it came down to two issues: the role of the Enterprise Admin and Exchange. Members of the enterprise Admins group cannot be locked out from any domain. This was a political concern because the research department Admins didn't trust the IT folks and vice-versa. They didn't want the other Admins in their data—a basic issue of trust as Microsoft's statement previously cited notes. Exchange was an issue because the company, including the ABC business unit, wanted to appear as a single organization. All employees should have a “User@company.com” e-mail address. Because Exchange uses the GC as the Global Address List (GAL), you can't have an organization spanning forests without synchronizing AD objects between the forests. It is possible to accomplish this by giving users in multiple forests a single e-mail address by the use of Simple Mail Transfer Protocol (SMTP) forwarding, but synching up contacts, calendar, and free/busy information is a huge challenge.

Gathering all the interested parties together, I presented these two issues as those that needed to be decided to resolve the question of whether the research department should have its own forest or simply an OU in the company's root domain. In regard to the enterprise Admin issue, it came to an issue of trust that should be controlled by company policy. Anyone who had enterprise Admin privilege should be required to abide by company policies that detail proper conduct and use of that authority. If they don't abide by that policy and if you can't control your employees, that's a management problem—not Windows. I then had an Exchange expert—Don Livengood,explain what was involved in getting Exchange to work across three forests—the administrative overhead and difficulty in keeping calendaring and free/busy data in sync. Recognizing e-mail functions as a mission-critical application, one Administrator said, “I think people wouldn't mind a power outage if they could get to their e-mail.” This discussion ended in a decision to adopt a single forest, single domain for these organizations. The point is that making the right decision took identifying the reasons not to adopt a multiple forest enterprise, getting all the parties together to discuss it, and urging them to do what is best for the company.

Although the company's reason for wanting multiple forests was to ensure division of administrative duties, this can be a reason for other enterprises not to go to multiple forests. This requires some fairly complex security group organization if you have Administrators who must have domain Admin or enterprise Admin rights in more than one forest.


Windows Server 2003 makes multiforest enterprises much easier to manage with the addition of Kerberos-based, cross forest trusts. These trusts allow Administrators in one forest to grant very granular access to resources in another forest.

3. OU Structure

The OU, of course, is an excellent alternative to multiple domains. Microsoft recommends using OUs to create directory partition structures for changeable entities. For instance, rather than making domains for Engineering, HR, Executive, Finance, and Program offices, OUs are a better solution because these names can change. Figure 9 compares a domain-based and an OU-based implementation. Although Windows Server 2003 has Domain Rename capability, it isn't trivial and there are still a lot of unresolved issues concerning application support. Building OUs allows not only flexibility of rename and restructure, but also requires no additional hardware for new DCs. Also, moving objects between OUs is much easier than between domains. Movement of users across domains requires tools such as Microsoft's Active Directory Migration Tool (ADMT), LDIFDE, or movetree.exe. Movement between OUs can be done in the AD Users and Computers GUI (Graphical User Interface).

Figure 9. Comparing a domain-based structure to an OU-based structure.


In Windows Server 2003, you can select multiple objects (such as users) and drag and drop them onto another OU.

In designing an OU structure, although there are no real design rules, some best practices have been developed from experienced AD designers. The structure really is determined by whether your focus is on Group Policy or administration. Most likely, you will need to consider both in your own design.

Group Policy-Based OUs

One common structure (and similar to that used by HP) that you might consider using is to divide up the first-level OU structure into users and computers. This is a Group Policy-based approach. Because policy is partitioned into user and computer settings, and you can actually limit a Group Policy Object (GPO) to apply only computer or user settings, OUs divided in this way make sense. Figure 10 shows an example of how a three-tier OU structure based on policy might be structured. Note that the first level has OUs titled Servers, Workstations, Printers, and Users. The second level further divides users into Sales, Manufacturing, Engineering, and IT staff. The second level under the Servers OU includes File/Print, Systems Management Services (SMS), and DHCP/WINS (Windows Internet Name Service). Similarly, you could subdivide the printers and workstations OUs, or leave them as single-level OUs. The Manufacturing OU contains a third-level OU structure that divides the Manufacturing users into geographies of North and South America and Canada. This demonstrates the flexibility of the OU structure. Some OUs need be only one level deep, some can be two, and others three or more.

Figure 10. A three-tier Group Policy-based OU structure built for Group Policy deployment as a critical design factor.

Administration-Based OUs

An administration-based OU's model is primarily based on the requirements of a company for the delegation of administrative rights. The structure would look something like that shown in Figure 11. This is almost the reverse of the Group Policy-based structure. Here, you have the geography-based OUs at the top of the structure, the computer- and user-based OUs at the second level, and the subdivisions of those OUs (such as that shown for the Servers OU) on the third level. Obviously this would work if your Administrators were organized by geography. If organized by business unit, you could replace the geography OUs with business unit names.

Figure 11. An administration-based OU structure, placing emphasis on administration of the overall domain components.

In working with the Qtest Windows 2000 testing environment at HP (originally created at Compaq), I decided to create an OU structure for the QAmericas domain and struggled through several designs. During this exercise, I decided that the most important thing in this environment was administration. Administrators were scattered throughout North and South America. I needed an OU structure that was conducive to permitting Administrators to get to all resources in their geography. Imagine the nightmare if I used the Group Policy-based structure. My Administrators' accounts would reside in the geographies—the third tier in the structure. But there would potentially be more geography-based OUs at that level requiring some interesting delegation so that each South American Admin could manage South American resources. However, if I apply the administration-based structure shown in Figure 5.11, all the South American resources are under the South America OU. I can put the South American Admin accounts in that OU, or perhaps put them in a child OU, and delegate rights appropri ately. It's really amazing as you look at different structures and review your business needs, how the solution eventually presents itself to you.

OU Depth

The depth of the OU tree is really governed only by the Group Policy structure that affects logon performance and what you can live with. Microsoft published data for Windows 2000 that specified that each GPO applied to a user-generated 58K, and each GPO applied to a computer-generated 72K of traffic. On startup and logon, each policy is copied from the DC to the workstation. Thus, the more policies that apply to the user, the longer it takes to log on. Note that a user is penalized only for the GPOs that apply to the user—not the total GPOs defined in the domain. This is actually predictable.

A good example of an OU design exercise was a large, global enterprise based in Atlanta that had already determined that its OU structure was to be six levels deep when I was asked to review the design. The interesting thing was that all of the objects—users, computers, printers, and so on—were in the sixth-level OU. The other OU levels contained only groups and were designed to look like the business organization.

Concerned about this, I convinced my coworkers that we should review the structure. We locked ourselves in a conference room for about three hours one day and drew all possible OU structures—basically iterations of the Group Policy- and administration-based structures discussed in this section previously. As we drew the structures on the whiteboard, we tried to fit the company's administration model into them. Finally it was evident that the only way to meet the business needs of the administration model the company wanted was to implement the six-layer OU model. I was satisfied with that because we challenged the model and proved it was the best solution.

Note that if we had taken the rule of thumb of not going more than three levels deep, we would not have arrived at the best solution. In addition, this six-level structure didn't impact the logon performance more than if it had been a single-level structure because the number of GPOs would be the same. If you want to reduce the logon time, you reduce the GPOs or groups, not the OUs.

Default and Special-Purpose OUs

By default, one OU is created during AD installation: the DC's OU. This OU, by default, houses all DCs and contains a Default Domain Controller (DDC) GPO. Although you can move DCs to any OU you want to, I don't recommend it. DC security policy is really in its own world, even by Microsoft's standards. Moving DCs out of the DDC's OU and changing the DDC's policy is adding a degree of uncertainty to the environment. If you run into security issues in the future, you should first ask whether it's because the DCs are not in the DDC OU. There might be valid reasons to do this, but make sure it's critical enough to pay the potential price.


The users and computers containers under the domain container are just that—containers—not OUs. In Windows 2003, you can convert these containers into OUs so that Group Policy can apply to them.

Special-purpose OUs are used to house objects temporarily during an installation or as a staging area for migration. They also can be used to troubleshoot problems such as group membership or Group Policy application. For instance, they can be used to synchronize objects in the AD for legacy e-mail environments such as Exchange 5.5 and GroupWise. Temporary OUs can be used to house the synchronized mailbox user contacts.
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
- Evaluating Applications for Windows 7 Compatibility : Deploying XP Mode
- System Center Configuration Manager 2007 : Operating System Deployment - Tips and Techniques
- Sharepoint 2013 : Health Monitoring and Disaster Recovery - Maintaining Content Integrity (part 2) - Versioning
- Microsoft Project 2010 : Linking Tasks (part 2) - Using the Start-to-Start Relationship,Using the Finish-to-Finish Relationship
- SQL Server 2008 R2 : Executing Stored Procedures
- Microsoft Visio 2010 : Creating Web Pages from Visio Drawings (part 1) - Saving as Web Page
- Monitoring Windows Small Business Server 2011 : Using Windows SBS Console Monitoring (part 2) - Using Notification Settings
- Microsoft Exchange Server 2007 : Consolidating a Windows 2000 Domain to a Windows Server 2003 Domain Using ADMT (part 5) - Migrating Computer Accounts
- Repairing and Removing Programs : Changing and Repairing Programs
- SharePoint 2010 : Configuring Search Settings and the User Interface - Web Parts (part 3)
Top 10
- Windows Phone 8 : Configuring Mailbox Settings (part 5) - Configuring Automatic Replies
- Windows Phone 8 : Configuring Mailbox Settings (part 4) - Lightening the Display,Changing the Mailbox Sync Settings
- Windows Phone 8 : Configuring Mailbox Settings (part 3) - Message Signatures, Blind CCing Yourself
- Windows Phone 8 : Configuring Mailbox Settings (part 2) - Unlinking Mailboxes, Conversation View
- Windows Phone 8 : Configuring Mailbox Settings (part 1) - Linking Mailboxes
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 6) - Tracking installed roles, role services, and features
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 5) - Installing components at the prompt
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 4) - Managing server binaries
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 3) - Adding server roles and features
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 2) - Installing components with Server Manager - Viewing configured roles and role services
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro