Best Practices
173
the changes and automatically reboot. You then must establish a method of rebooting all
member servers, workstations, and other client machines and then reboot them all a
second time to ensure that all services receive the domain-naming change.
Step 6: Post-Rename Tasks
The final step in the Rendom task is to run the rendom /clean operation, which will
remove temporary files created on the domain controller and return the domain to a
normal operating state.
In addition to the cleanup tasks, you need to effectively rename each domain controller,
to change its primary DNS suffix. Each domain controller needs to go through this operation, which you run via the netdom command-line utility. The following steps outline the
renaming of a domain controller:
1. Open a Command Prompt window (choose Start, Run, and then type cmd.exe).
2. Type netdom computername OldServerName /add:NewServerName.
3. Type netdom computername OldServerName /makeprimary:NewServerName.
5. Type netdom computername NewServerName /remove:OldServerName.
You run all the preceding commands from the command line. Replace the generic designators OldServerName and NewServerName with the entire DNS name of the old server
and the new server, such as server1.companyabc.com and server1.companyxyz.com.
Summary
With the advent of technologies such as domain rename, fine-grained password policies,
and cross-forest trusts, mistakes in AD DS design have become more forgiving than they
were in the past. However, it is still important to thoroughly examine the political and
technical aspects of any organization to design an infrastructure that aligns with its needs.
AD DS is very flexible in these regards and can be matched with the needs of almost any
organization.
Best Practices
The following are best practices from this chapter:
 Fully understand the structure of AD DS before designing.
 Implement fine-grained password policies and the Active Directory Recycle Bin to
reduce the need for additional domains.
 Secure any external namespace chosen by registering it so that it cannot be used
anywhere on the Internet.
5
4. Restart the server.
174
CHAPTER 5
Designing a Windows Server 2008 R2 Active Directory
 Start a domain design by considering the single domain model first.
 Consider using multiple domains for specific reasons only.
 Consider using the federated forest design model when uniting two disparate AD DS
structures.
 Control and optimize replication traffic by using sites.
 Upgrade any down-level clients to reduce administration and maintenance.
 Use domain rename sparingly, and only when faced with no other alternative.
CHAPTER
6
Designing
Organizational Unit and
Group Structure
The organization of users, computers, and other objects
within the Windows Server 2008 R2 Active Directory
Domain Services (AD DS) structure gives administrators
great flexibility and control over their environments. Both
organizational unit (OU) and group structure design can be
tailored to fit virtually any business need. There is, however,
a great bit of confusion among administrators in the design
and use of OUs and groups. Often, OUs are indiscriminately
used without reason, and group structure is ineffectual and
confusing. With the proper preparation and advance knowledge of their use, however, a functional OU and group
design can do wonders to simplify a Windows Server 2008
R2 AD DS environment.
In addition to the lessons learned from OU and group use
in Windows 2000 Server and Windows Server 2003,
Windows Server 2008 R2 introduced functionality such as
the Active Directory Recycle Bin, which reduces the risk of
OU deletion, and Active Directory Web Services and an
Active Directory Module for Windows PowerShell, which
makes it easier to administer OUs. In addition, AD DS builds
upon the improvements to OU structure and design introduced with the release of Windows Server 2008, such as OU
Deletion Protection, universal group membership caching,
incremental group replication, and other enhancements
that have increased the flexibility of OU and group design
and have given administrators greater tools to work with.
This chapter defines organizational units and groups
within Windows Server 2008 R2’s AD DS and describes
methods of integrating them into various AD DS designs.
Specific step-by-step instructions and “best practice” design
IN THIS CHAPTER
 Defining Organizational Units in
AD DS
 Defining AD Groups
 Examining OU and Group Design
 Starting an OU Design
 Using OUs to Delegate
Administration
 Group Policies and OU Design
 Understanding Group Design
 Exploring Sample Design
Models
CHAPTER 6
176
Designing Organizational Unit and Group Structure
advice are given as well. In addition, functional OU and group design models are detailed
and compared.
Defining Organizational Units in AD DS
An organizational unit is an administrative-level container, depicted in Figure 6.1, that is
used to logically organize objects in AD DS. The concept of the organizational unit is
derived from the Lightweight Directory Access Protocol (LDAP) standard upon which AD DS
was built, although there are some conceptual differences between pure LDAP and AD DS.
Organizational Units
Los Angeles
Chicago
New York
FIGURE 6.1 Examining AD DS organizational unit structure.
Objects within Active Directory can be logically placed into OUs as defined by the administrator. Although all user objects are placed in the Users container by default and
computer objects are placed in the Computers container, they can be moved at any time.
NOTE
The default Users and Computers folders in AD DS are not technically organizational
units. Rather, they are technically defined as Container class objects. It is important
to understand this point because these Container class objects do not behave in the
same way as organizational units. To be able to properly utilize services such as
Group Policies, which depend on the functionality of OUs, it is recommended that you
move your user and computer objects from their default container locations into an
OU structure.
Each object in the AD DS structure can be referenced via LDAP queries that point to its
specific location in the OU structure. You will often see objects referenced in this format
when you’re writing scripts to modify or create users in AD DS or simply running LDAP
queries against AD DS. For example, in Figure 6.2, a user named Paul Cochrane in the SF
sub-OU of the Locations OU would be represented by the following LDAP string:
CN=Paul Cochrane,OU=SF,OU=Locations,DC=companyabc,DC=com
Defining Organizational Units in AD DS
177
companyabc.com
Locations
Syndey
London
Paul
Cochrane
SF
FIGURE 6.2 Viewing the LDAP structure of a user object in AD.
NOTE
The OU structure can be nested, or include sub-OUs that are many layers deep. Keep
OUs primarily satisfy the need to delegate administration to separate groups of administrators. Although there are other possibilities for the use of OUs, this type of administration
delegation is, in reality, the primary factor that exists for the creation of OUs in an AD
environment. See the “Starting an OU Design” section of this chapter for more details on
this concept.
THE NEED FOR ORGANIZATIONAL UNITS
Although there is a tendency to use organizational units to structure the design of AD
DS, OUs should not be created to just document the organizational chart of the
company. The fact that the organization has a Sales department, a Manufacturing
department, and a Marketing department doesn’t suggest that there should be these
three AD DS OUs. An administrator should create OUs if the departments will be
administered separately and/or policies will be applied differently to the various departments. However, if the departments will all be administered by the same IT team, and
the policies being applied will also be the same, having multiple OUs is not necessary.
Additionally, OUs are not exposed to the directory, meaning that if a user wants to send
an email to the members of an OU, he would not see the OU structure nor the
members in the OU grouping.
6
in mind, however, that the more complex the OU structure, the more difficult it becomes
to administer and the more time consuming directory queries become. Microsoft recommends not nesting more than 10 layers deep. However, it would be wise to keep the
complexity significantly shorter than that number to maintain the responsiveness of
directory queries.