OU Design: Geographic Model
With a geographic model, you use OUs to refl ect geographic location. In this model,
top-level OUs represent the largest geographic units, such as continents, and the
lower-level OUs represent successively smaller geographic units, such as countries (see
Fig ure 31-3).
There are several advantages to this model. A geographic structure is fairly stable.
Many companies reorganize internally frequently, but only rarely change geographic
structure. Additionally, when you use a geographic model, it is easy to determine where
accounts and resources are physically located.
The disadvantages to this model have to do with its scope. For a global company, this
design would put all accounts and resources in a single domain. As a result, changes
made to Active Directory at any location would be replicated to every offi ce loca-
tion. Additionally, the OU structure doesn’t relate to the business structure of the
organization.
cpandl.com
North America
Europe
USA Canada Mexico UK Germany Spain
Figure 31-3 The geographic model.
Developing an Organizational Unit Plan 1067
Chapter 31
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
OU Design: The Cost Center Model
With a cost center model, you use OUs to refl ect cost centers. In this model, top-level
OUs represent the major cost centers within the organization and the lower-level OUs
represent geographic locations, projects, or business structures, as shown in Figure
31-4. In a company where budget is the top priority, the cost center model may be an
effective way to refl ect this priority. Cost centers could also be independent divisions or
business units within the company that have their own management and cost controls.
cohowinery.com
N.A. Europe

to redesign the OU structure.
Developing an Organizational Unit Plan 1069
Chapter 31
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
A
s part of the design of Active Directory Domain Service, you should examine the
network topology and determine if you need to manage network traffi c between
subnets or business locations. To manage network traffi c related to Active Directory,
you use sites, which can be used to refl ect the physical topology of your network. Every
Active Directory implementation has at least one site. An important part of understand-
ing sites involves understanding Active Directory replication. Active Directory uses two
replication models: one model for replication within sites and one model for replication
between sites. You need a solid understanding of these replication models to plan your
site structure.
Working with Active Directory Sites
A site is a group of Transmission Control Protocol/Internet Protocol (TCP/IP) subnets
that are implemented to control directory replication traffi c and isolate logon authen-
tication traffi c between physical network locations. Each subnet that is part of a site
should be connected by reliable, high-speed links. Any business location connected
over slow or unreliable links should be part of a separate site. Because of this, indi-
vidual sites typically represent the sets of local area networks (LANs) within an orga-
nization, and the wide area network (WAN) links between business locations typically
mark the boundaries of these sites. However, sites can be used in other ways as well.
Sites do not refl ect the Active Directory namespace. Domain and site boundaries are
separate. From a network topology perspective, a single site can contain multiple TCP/
IP subnets as well. However, a single subnet can be in only one site. This means that the
following conditions apply:

A single site can contain resources from multiple domains.

locations. Here, the organization has decided to use two domains and two sites. The
Main site is for the cohowinery.com domain and the Seattle site is for the sea.coho-
winery.com domain. Again, replication occurs both within and between the sites.
Single Site vs. Multiple Sites
One reason to create additional sites at the same physical location is to control replica-
tion traffi c. Replication traffi c between sites is automatically compressed, reducing the
amount of traffi c passed between sites by 85 to 90 percent of its original size. Because
network clients try to log on to network resources within their local site fi rst, this
means that you can use sites to isolate logon traffi c as well.
Chapter 32
1072 Chapter 32 Configuring Active Directory Sites and Replication
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
sea.cohowinery.com
Seattle site Main site
cohowinery.com
Figure 32-2 Multiple sites at different locations.
In most cases, you’ll want to optimize sites for Active Directory replication control.
Here, it is recommended that each site have at least one domain controller and one
global catalog for client authentication. For name resolution and IP address assignment,
it is also recommended that each site have at least one Domain Name System (DNS)
server and one Dynamic Host Confi guration Protocol (DHCP) server. Then, by creating
multiple sites in the same physical location and establishing a domain controller, global
catalog, and DNS and DHCP server within each site, you can closely control the logon
process.
You can also design sites with other network resources in mind, including distributed
fi le system (DFS) fi le shares, certifi cate authorities, and Microsoft Exchange servers.
Generally speaking, you want to confi gure sites so that clients’ network queries can
be answered within the site. If every client query for a network resource has to be sent
to a remote site, there could be substantial network traffi c between sites, which could
be a problem over slow WAN links. As part of your site design, you should also con-

Authentication within and between domains is also handled by domain controllers. If
a user logs on to his or her home domain, the local domain controller authenticates the
logon. If a user logs on to a domain other than the home domain, the logon request is
forwarded through the trust tree to a domain controller in the user’s home domain.
Active Directory’s replication model is designed for consistency, but the consistency is
loosely defi ned. By loosely defi ned, I mean that at any given moment the information on
one domain controller can be different from the information on a different domain con-
troller. This can happen when Windows Server 2008 has not yet replicated the changes
on the fi rst domain controller to the other domain controller. Over time, Windows
Server 2008 replicates the changes made to Active Directory on one domain controller
to all domain controllers as necessary.
When multiple sites are involved, the replication engine uses the Site model to store
and then forward changes as necessary between sites. In this case, a domain controller
in the site where the changes were originally made forwards the changes to a domain
controller in another site. This domain controller in turn stores the changes, and then
forwards the changes to all the domain controllers in the second site. In this way, the
Note
Enterprises often have branch offi ces where each branch offi ce is defi ned as a separate
site to control traffi c for high-bandwidth–consuming applications rather than Active
Directory replication. Here, traffi c for high-bandwidth–consuming applications, such
as DFS or software control and change management (SCCM), is carefully managed but
authentication and global catalog traffi c is allowed to cross the WAN because it is less
bandwidth-intensive.
Chapter 32
1074 Chapter 32 Configuring Active Directory Sites and Replication
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
domain controller on which a change is made doesn’t have to replicate directly with all
the other domain controllers. It can instead rely on the store-and-forward technique to
ensure that the changes are replicated as necessary.
Determining Site Boundaries

Understanding Active Directory Replication
When you are planning site structure, it is important that you understand how replica-
tion works. As discussed previously, Active Directory uses two replication models, each
of which is handled differently. The intrasite replication model is used for replication
within sites and is optimized for high-bandwidth connections. The intersite replica-
tion model is used for replication between sites and is optimized for limited-bandwidth
connections. Before I get into the specifi cs of replication and the replication models,
let’s look at the way replication has changed since Active Directory Domain Service was
introduced with Microsoft Windows 2000.
Understanding Active Directory Replication 1075
Chapter 32
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Replication Enhancements for Active Directory
The replication model used for Microsoft Windows Server 2003 and now Windows
Server 2008 has changed in several important ways from the model in Windows 2000.
In Windows 2000, the smallest unit of replication is an individual attribute. At fi rst
examination, this seems to be what is wanted; after all, you don’t want to have to rep-
licate an entire object if only an attribute of that object has changed. The problem with
this approach is that some attributes are multivalued. That is, they have multiple values.
An example is the membership attribute of a universal group. This attribute represents
all the members of the universal group.
In Windows 2000, by adding or removing a single user from the group, you caused the
entire group membership to be replicated. In large organizations, a signifi cant amount
of replication traffi c was often generated because universal groups might have several
thousand members. Windows Server 2003 and Windows Server 2008 resolve this prob-
lem by replicating only the attribute’s updated value. With universal group member-
ship, this means that only the users you’ve added or removed are updated, rather than
the entire group membership.
As discussed in “Extensible Storage Engine” on page 993, Active Directory uses trans-
actional processing. When there are many changes, Active Directory processes the

support a greater number of sites. These changes affect intersite replication in the fol-
lowing key ways:

In Windows 2000, Windows Server 2003, and Windows Server 2008, all intersite
replication traffi c is compressed by default. Although this signifi cantly reduces
the amount of traffi c between sites, it increases the processing overhead required
on the bridgehead servers to replicate traffi c between sites. Therefore, if processor
utilization on bridgehead servers is a concern, and you have adequate bandwidth
connections between sites, you may want to disable compression, which
Windows Server 2003 and Windows Server 2008 allow you to do.

In Windows 2000, Windows Server 2003, and Windows Server 2008, replication
between sites occurs at scheduled intervals according to the site link confi gura-
tion. With Windows Server 2003 and Windows Server 2008, you can enable
notifi cation for intersite replication, which allows the bridgehead server in a site
to notify the bridgehead server on the other side of a site link that changes have
occurred. This allows the other bridgehead server to pull the changes across the
site link and thereby get more frequent updates.

In Windows 2000, the maximum number of sites you can have in a forest is
greatly infl uenced by the knowledge consistency checker (KCC). As a result, the
KCC has a practical limit of about 100 sites per forest. Because the KCC in Win-
dows Server 2003 and Windows Server 2008 has been revised, the KCC itself is
no longer the limiting factor. This means that you can have many hundreds of
sites per forest.
Note
To turn off compression or enable notifi cation, you need to edit the related site link or
connection object. See “Confi guring Replication Schedules for Site Links” on page 1293.
Replication Enhancements for the Active Directory
System Volume

to 300 percent faster replication and 200 to 300 percent faster compression. Opera-
tional overhead for managing content and replication also was reduced by 40 percent.
Additionally, DFS-R supports automated recovery from database loss or corruption,
replication scheduling, and bandwidth throttling. Together these features make DFS-R
signifi cantly more scalable than FRS.
RDC is the secret ingredient associated with enhanced DFS that allows for granular repli-
cation of changes when using Active Directory with Windows Server 2008—this is what’s
referred to when you read a vague statement that says DFS allows for granular replica-
tion of the Sysvol. RDC enables granular replication by accurately identifying changes
within and across fi les and transmitting only those changes to achieve signifi cant band-
width savings. More specifi cally, RDC detects insertions, removals, or rearrangements
of data in fi les, enabling DFS-R to replicate only the changed fi le blocks when fi les are
updated. Changes within or across fi les are called fi le deltas.
In addition to calculating fi le deltas and transferring only the differences, RDC also can
copy any similar fi le from any client or server to another using data that is common to
both computers. This further reduces the amount of the data sent and the overall band-
width requirements for fi le transfers. Local differencing techniques are used to transform
the old version into a new version. The differences between two versions of the fi le are
calculated on the source domain controller and then sent to the DFS client on the target
domain controller.
The storage techniques and replication architectures for DFS and FRS are decidedly dif-
ferent. Figure 32-3 shows a conceptual view of how File Replication Service is used with
Active Directory on a domain controller. The File Replication Service (Ntfrs.exe) stores
FRS topology and schedule information in Active Directory and periodically polls
Active Directory to retrieve updated information using Lightweight Directory Access
Protocol (LDAP). Most administrator tools that work with FRS use LDAP as well. Inter-
nally, FRS makes direct calls to the fi le system using standard I/O. FRS uses the Remote
Procedure Call (RPC) protocol when communicating with remote servers.
SIDE OUT
Why DFS instead of FRS?

and debug logs stored in the debug log folder (%SystemRoot%\Debug). Esent.dll is
a dynamic link library used by the Jet database to store transactions. Ntfrsres.dll is a
dynamic-link library used by FRS to store events and error messages.
FRS Jet Database
Replica Tree
USN Journal
Staging Folder
FRS Event Log
FRS Debug Logs
NTFS File System
Administrator
Tools
FRS Metadata
Registry
DS APIs
ESENT.DLL
FRS Object
Active Directory
File Replication
Service
(NTFRS.EXE)
NTFRSRES.DLL
LDAP
RPC to FRS
on other servers
File
System
I/O
LDAP
Registry

same backup APIs are used to ensure that Volume Shadow Copy service-compatible
backup programs, such as Windows Backup, can make point-in-time, consistent backups
of the replica tree. Before such a program takes a shadow copy of a replica tree, the pro-
gram instructs FRS to stop requesting new work items. After all currently active items are
complete, FRS enters a pause state during which no new items can be processed.
The stand-alone DFS metadata contains information about the root, root tar-
get, links, link targets, and confi guration settings defi ned for each stand-alone
namespace. This metadata is maintained in the Registry of the root server at
HKLM\SOFTWARE\Microsoft\Dfs\Roots\Standalone.
Domain-based root servers have a Registry entry for each root under HKLM\SOFT-
WARE\Microsoft\Dfs\Roots\Domain, but these entries do not contain the domain-
based DFS metadata. When the DFS service starts on a domain controller using Active
Directory with DFS, the service checks this path for Registry entries that correspond
to domain-based roots. If these entries exist, the root server polls the PDC emulator
master to obtain the DFS metadata for each domain-based namespace and stores the
metadata in memory.
In the Active Directory data store, the DFS object stores the DFS metadata for a domain-
based namespace. The DFS object is created in Active Directory when you install a
domain at or raise a domain to the Windows Server 2008 domain functional level.
Active Directory replicates the entire DFS object to all domain controllers in a domain.
SIDE OUT
The replica root
The actual replica root begins at the %SystemRoot%\Sysvol\domain folder, but the folder
that is actually shared is the %SystemRoot%\Sysvol\sysvol folder. These folders appear
to contain the same content because Sysvol uses junction points (also known as reparse
points). A junction point is a physical location on a hard disk that points to data that is
located elsewhere on the hard disk or on another storage device.
The Sysvol\domain folder contains policies and scripts in separate subfolders. The Sysvol\
Staging folder acts as a queue for changed fi les that need to be replicated. Within the
Sysvol\Staging Areas folder, the DomainName folder is a junction point to the Sysvol\

Root and Link
Folders
NTFS Volume
DFS.SYS
SRV.SYS
NETAPI32.DLL
DFS Object
Active Directory
DFS Service
(DFSSVC.EXE)
LDAP
LDAP to DFS
on other servers
CIFS to DFS
Clients
Registry
APIs
DFS Metadata
Registry
Figure 32-4 A conceptual view of how the DFS service works.
DFS uses a client-server architecture. A domain controller hosting a DFS name space
has both the client and the server components, allowing the domain controller to
perform local lookups in its own data store and remote lookup in data stores on other
domain controllers. DFS uses the Common Internet File System (CIFS) for communica-
tion between DFS clients, root servers, and domain controllers. CIFS is an extension of
the Server Message Block (SMB) fi le sharing protocol.
When a domain controller receives a CIFS request, the SMB Service server driver
(Srv.sys) passes the request to the DFS driver (Dfs.sys) and this driver in turn directs
the request to the DFS service. Dfs.sys also handles the processing of links when they
are encountered during fi le system access.

After this information is cached, DFS can provide this to clients that are requesting
information about DFS namespaces. The physical structures and caches on a domain
controller vary according to the type of namespace the server hosts (domain-based
or stand-alone). Each root and link in a namespace has a physical representation on
an NTFS volume on each domain controller. The DFS root for Active Directory corre-
sponds to the Sysvol shared folder. If a domain controller hosts additional namespaces,
the domain controller will have additional roots and links.
Replication Architecture: An Overview
Active Directory replication is a multipart process that involves a source domain con-
troller and a destination domain controller. From a high level, replication works much
as shown in Figure 32-5.
The step-by-step procedure goes like this:
1. When a user or a system process makes a change to the directory, this change is
implemented as an LDAP write to the appropriate directory partition.
2. The source domain controller begins by looking up the IP address of a replication
partner. For the initial lookup or when the destination DNS record has expired,
the source domain controller does this by querying the primary DNS server.
Subsequent lookups can be done using the local resolver cache.
Chapter 32
1082 Chapter 32 Configuring Active Directory Sites and Replication
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
3. The source and destination domain controllers use Kerberos to mutually
authenticate each other.
4. The source domain controller then sends a change notifi cation to the destination
domain controller using RPC over IP.
5. The destination domain controller sends a request for the changes using RPC
over IP, including information that allows the source domain controller to
determine if those changes are needed.
6. Using the information sent by the destination domain controller, the source
domain controller determines what changes (if any) need to be sent to the

Sends the necessary changes
6b
Figure 32-5 An overview of replication.
Understanding Active Directory Replication 1083
Chapter 32
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Note
For intersite replication, two transports are available: RPC over IP and SMTP. With this in
mind, SMTP could also be used as an alternate transport. SMTP uses TCP port 25.
As you can see from this overview, Active Directory replication depends on the follow-
ing key services:

LDAP

Domain Name System (DNS)

Kerberos version 5 authentication

Remote Procedure Call (RPC)
These Windows services must be functioning properly to allow directory updates to be
replicated. Active Directory also uses either FRS or DFS to replicate fi les in the System
Volume (Sysvol) shared folders on domain controllers. The User Datagram Protocol
(UDP) and TCP ports used during replication are similar regardless of whether FRS or
DFS is used. Table 32-1 summarizes the ports that are used.
Table 32-1 Ports Used During Active Directory Replication
Service/Component Port
UDP TCP
LDAP 389 389
LDAP Secure Sockets Layer (SSL) 686
Global catalog (LDAP) 3268


In a pull replication model, two servers are used. One is designated the push part-
ner, the other the pull partner. It is the responsibility of the push partner to notify
the pull partner that changes are available. The pull partner can then request the
changes. Creating push and pull replication partners allows for rapid notifi cation of
changes and for updating after a request for changes has been made.
The KCC uses these models to create a replication ring. As domain controllers are added
to a site, the size and confi guration of this ring change. When there are at least three
domain controllers in a site, each domain controller is confi gured with at least two
incoming replication connections. As the number of domain controllers changes, the KCC
updates the replication topology.
When a domain controller is updated, it waits approximately 15 seconds before initiat-
ing replication. This short wait is implemented in case additional changes are made.
The domain controller on which the change is made notifi es one of its partners, using
an RPC, and specifi es that changes are available. The partner can then pull the changes.
After replication with this partner completes, the domain controller waits approximately
3 seconds, and then notifi es its second partner of changes. The second partner can then
pull the changes. Meanwhile, the fi rst partner is notifying its partners of changes as
appropriate. This process continues until all the domain controllers have been updated.
SIDE OUT
Intrasite replication essentials
Active Directory’s multimaster replication model is designed to ensure that there is no
single point of failure. In this model, every domain controller can access changes to the
database, and can replicate those changes to all other domain controllers. When replica-
tion occurs within a domain, the replication follows a specifi c model that is very different
from the replication model used for intersite replication.
With intrasite replication, the focus is on ensuring that changes are rapidly distributed.
Intrasite replication traffi c is not compressed, and replication is designed so that changes
are replicated almost immediately after a change has been made. The main component
in Active Directory responsible for the replication structure is the KCC. One of the main

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

The 15-second delay for replication applies to Windows Server 2003 and Windows Server
2008. For Windows 2000, the default delay is 300 seconds. In either case, however, the
delay is overridden to allow immediate replication of priority changes. Priority (urgent)
replication is triggered if you perform one of the following actions:

Lock out an account, change the account lockout policy, or if an account is locked
out automatically due to failed logon attempts

Change the domain password policy

Change the password on a domain controller computer account

Change the relative ID master role owner

Change a shared secret password used by the Local Security Authority (LSA) for
Kerberos authentication
Urgent replication means that there is no delay to initiate replication. Note that all other
changes to user and computer passwords are handled by the designated primary domain
controller (PDC) emulator in a domain. When a user changes a normal user or computer
password, the domain controller to which that user is connected immediately sends the
change to the PDC emulator. This way, the PDC emulator always has the latest password
for a user. This is why the PDC emulator is checked for a new password if a logon fails
initially. After the new password is updated on the PDC emulator, the PDC emulator rep-
licates the change using normal replication. The only exception is when a domain con-
troller contacts the PDC emulator requesting a password for a user. In this case, the PDC
emulator immediately replicates the current password to the requesting domain control-
ler so that no additional requests are made for that password.
Figure 32-6 shows a ring topology that a KCC would construct if there were three

Kerberos authentication
Urgent replication means that there is no delay to initiate replication. Note that all other
changes to user and computer passwords are handled by the designated primary domain
controller (PDC) emulator in a domain. When a user changes a normal user or computer
password, the domain controller to which that user is connected immediately sends the
change to the PDC emulator. This way, the PDC emulator always has the latest password
for a user. This is why the PDC emulator is checked for a new password if a logon fails
initially. After the new password is updated on the PDC emulator, the PDC emulator rep-
licates the change using normal replication. The only exception is when a domain con-
troller contacts the PDC emulator requesting a password for a user. In this case, the PDC
emulator immediately replicates the current password to the requesting domain control-
ler so that no additional requests are made for that password.
Chapter 32
1086 Chapter 32 Configuring Active Directory Sites and Replication
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.