Read-Only Domain Controller (RODC)

Branch Office Guide

Microsoft Corporation
Published: June 2009

Abstract
This guide explains how to plan, deploy, and administer read-only domain controllers (RODCs) in
branch office environments.
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious,
and no association with any real company, organization, product, domain name, e-mail address,
logo, person, place, or event is intended or should be inferred. Complying with all applicable
copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part
of this document may be reproduced, stored in, or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or
otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.
© 2009 Microsoft Corporation. All rights reserved.
Active Directory, Microsoft, Windows, Windows NT, and Windows Server are either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Contents
Read-Only Domain Controller (RODC) Branch Office Guide..........................................................1
Abstract....................................................................................................................................1

Contents..........................................................................................................................................3

Read-Only Domain Controller Branch Office Guide........................................................................6

Who Should Read These Guidelines, and What Scenarios Do They Apply To?.............................6

Branch Office Environment Characteristics.....................................................................................7

Deciding Which Type of Domain Controller Meets the Needs of a Branch Office Location.............8
Datacenters and hub locations....................................................................................................9
Branch offices and satellite locations...........................................................................................9
Deciding whether a branch office location requires a domain controller....................................10
Deciding which type of domain controller to deploy...................................................................10

Differences Between Recommendations in the Windows Server 2003 Branch Office Guide and
Default Settings for RODCs.......................................................................................................15

Planning for RODCs in Branch Offices.........................................................................................18

Review the Existing Active Directory Design.................................................................................19

Evaluate Your Active Directory Logical Structure..........................................................................20

ADMT.....................................................................................................................................22

Review Policy Settings and Network Settings...............................................................................22

Determine the Domain Upgrade Order.........................................................................................23

Review the Existing Physical Structure.........................................................................................25

Recommendations from the Windows Server 2003 Branch Office Guide That Still Apply to
RODCs......................................................................................................................................29

Plan Replication for Branch Offices...............................................................................................30

Plan for DFS Replication for SYSVOL..........................................................................................30

Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008 RODCs. 31
Example: How bridgehead server load-balancing works........................................................32
Failover for FRS replication of SYSVOL.................................................................................33

Plan the Hub Site Deployment......................................................................................................34

Preventing Bridgehead Server Overload During a Transition........................................................35

Use ADLB from the Windows Server 2003 Branch Office Guide to Rebalance Connections
Between Writeable Domain Controllers in the Hub....................................................................35

Branch Office-to-Hub Replication Overload (Inbound Overload)..................................................37

Hub-to-Branch Office Replication Overload (Outbound Overload)................................................38

Using the Windows 2000 Compression Algorithm on Slow WAN Links........................................38

Create a Dedicated RODC Replication Hub.................................................................................40

Enabling the Bridge All Site Links Option......................................................................................41

Enabling Client Computers to Locate the Next Closest Domain Controller...................................42

Filtering sites with RODCs.....................................................................................................43
Forcing domain controller rediscovery....................................................................................44
Methods for applying the TryNextClosestSite setting.............................................................44

Plan DNS Servers for Branch Office Environments......................................................................45

Review the current DNS client settings......................................................................................46

Plan Global Catalog Servers.........................................................................................................47

Enabling universal group membership caching.........................................................................48

Deploying RODCs in Branch Offices.............................................................................................48

Step 1: Take an Inventory of Branch Office Resources.................................................................49

Applications............................................................................................................................49
Operating systems.................................................................................................................49
Users and computers.............................................................................................................50

Step 2: Verify That Prerequisites for RODC Deployment Are Complete.......................................50

Step 3: Decide How to Define the Password Replication Policy...................................................50

Step 4: Customize the RODC Filtered Attribute Set......................................................................51

Step 5: Determine Your Strategy for Deploying RODCs to Branch Offices...................................53

Deploy an RODC to a Branch Office That Currently Has No Domain Controller...........................53

Replace a Windows Server 2003 Domain Controller in a Branch Office with a Windows Server
2008 RODC...............................................................................................................................55

Upgrade a Windows Server 2003 Domain Controller in a Branch Office and Make It an RODC. .57

Step 6: Complete Additional Steps for Configuring an RODC.......................................................58

Step 7: Raise the Domain and Forest Functional Levels to Windows Server 2008......................60
Administering RODCs in Branch Offices.......................................................................................60
Using Remote Desktop to administer RODCs in branch offices................................................61
Reestablishing replication for an RODC....................................................................................62
Checking the lastLogonTimeStamp attribute on an RODC to discover stale accounts in a
branch office...........................................................................................................................64
Resolving an account lockout problem in a branch office with an RODC..................................65
Performing backups of an RODC..............................................................................................66

Monitoring Your Branch Office Environment.................................................................................67

Determining what to monitor......................................................................................................67
Monitoring domain controller performance.............................................................................67
Monitoring CPU utilization...................................................................................................68
Monitoring available disk space..........................................................................................68
Monitoring disk utilization....................................................................................................68
Monitoring memory utilization.............................................................................................69
Monitoring directory service performance..............................................................................69
Monitoring Active Directory replication................................................................................69
Repadmin........................................................................................................................70
Dcdiag.............................................................................................................................72
When to monitor branch office domain controllers.................................................................73
Scheduling..........................................................................................................................73
Using Windows Reliability and Performance Monitor................................................................74
Installing performance objects and running the Active Directory Diagnostics Data Collector
Set......................................................................................................................................74
Using NTDS object counters..................................................................................................75
Using Database object counters.............................................................................................77
Monitoring SYSVOL replication.................................................................................................78
Using System Center Operations Manager...............................................................................79
Read-Only Domain Controller Branch Office
Guide
The topics in this section describe new features in Windows Server 2008 that can provide
benefits for Active Directory deployments that include branch offices. These topics explain how to
assess your existing deployment of domain controllers in branch offices to determine whether
deploying read-only domain controllers (RODCs) in existing or future branch offices is appropriate
for your organization.
If necessary, you can review the previous topics about configuring RODCs and the functionality
that they provide in Understanding Planning and Deployment for Read-Only Domain
Controllers. For more information about how to deploy an RODC in a perimeter network, see
Active Directory Domain Services in the Perimeter Network (Windows Server 2008). For more
general information about Active Directory Domain Services (AD DS), see Active Directory
Domain Services (http://go.microsoft.com/fwlink/?LinkID=127814).
Many organizations have existing Active Directory branch office deployments that are similar to
the recommendations in the Windows Server 2003 Active Directory Branch Office Planning and
Deployment Guide (http://go.microsoft.com/fwlink/?LinkID=28523). For convenience in helping
these organizations more easily integrate RODCs into their existing infrastructure, some topics in
this guide refer to recommendations from the Windows Server 2003 guide. Therefore, familiarity
with your current Active Directory infrastructure and the recommendations from the
Windows Server 2003 guide is helpful. However, the recommendations in the following topics are
applicable for any branch office deployment that can benefit from RODCs:
• Who Should Read These Guidelines, and What Scenarios Do They Apply To?
• Branch Office Environment Characteristics
• Deciding Which Type of Domain Controller Meets the Needs of a Branch Office Location
• Differences Between Recommendations in the Windows Server 2003 Branch Office
Guide and Default Settings for RODCs
• Planning for RODCs in Branch Offices
• Deploying RODCs in Branch Offices
• Administering RODCs in Branch Offices
• Monitoring Your Branch Office Environment

Who Should Read These Guidelines, and

What Scenarios Do They Apply To?
These guidelines should be read by system architects and information technology (IT)
professionals who are responsible for evaluating, planning, or deploying an IT infrastructure in an

6
organization that may face a number of constraints in its Active Directory deployment. These
constraints may include limited physical security in remote branch offices, limited available
hardware, slow wide area network (WAN) links that connect the hub offices and branch offices, or
a lack of IT experience in the branch offices.
Even though most branch office environments present a consistent set of characteristics, the
requirements for deployment of IT resources in these environments may vary significantly from
organization to organization. You should make sure that the recommendations in this guide apply
to your specific scenario before proceeding. Because these guidelines focus on planning and
deploying read-only domain controllers (RODCs) in branch offices, it is important to first
determine whether RODCs help fulfill the requirements for your scenario. For more information
about common characteristics of branch office deployments that an RODC can help address, see
Branch Office Environment Characteristics. For more information about how to determine if an
RODC is suited for your scenario, see Deciding Which Type of Domain Controller Meets the
Needs of a Branch Office Location.
These guidelines explain the most important issues to consider before you decide whether
RODCs are a good fit for your environment. The guidelines then focus on best practices for
deploying RODCs in a remote branch office environment.

Note
These guidelines are applicable to most organizations that have from a few branch
offices to several hundred branch offices.

Branch Office Environment Characteristics

Branch offices have specific requirements beyond their normal, centralized services. The key
requirement is to provide the normal range of data and services in these branches. However,
systems architects face a difficult trade-off in designing their branch architectures. They can do
either of the following:
• Place servers in branch sites, which provides better reliability. Branch office users can
work if the wide area network (WAN) link to the main site is not available and the users are
not held back by bandwidth delays. However, this also incurs the management costs that an
organization incurs by deploying and managing servers in each site.
• Leave the servers in central sites and have branch office users access the resources on
those servers remotely. This reduces the server management requirements, but it also
reduces the performance and autonomy of the branch office.
In an ideal strategy, branch offices have the benefit of data and service locality without the costs
of securing and administering the information technology (IT) infrastructure. Read-only domain
controllers (RODCs) map well to that strategy because they can cache the data that the branch
office needs, and they provide delegation for specific management tasks. The rest of this topic
describes some of the challenges that branch offices present. For more information about how
RODCs help address some of these issues, see Deciding Which Type of Domain Controller
Meets the Needs of a Branch Office Location.

7
A typical branch office environment has one or more of the following characteristics:
• Hub-and-spoke site topology
In this type of network topology, all or most of the IT staff and resources reside in one or more
centralized hub locations, while users and computers reside in multiple branch offices. Each
branch connects to a central hub through a WAN link. Typically, the central IT staff
administers IT resources remotely in the branch as necessary.
• Large number of branch offices
A branch office environment can include many remote locations where there are users who
need to access IT resources. Some of the branch offices may currently have part or all of the
required resources available locally. However, some branch offices may rely entirely on the
availability of a link to a hub site for access to these resources. In particular, some branch
offices may currently have a domain controller; others may not.
• Slow, congested, latent, or unreliable network connectivity between the branch and
hub locations
Even if the WAN links provide more bandwidth at a higher speed, when a domain controller in
a branch office is offline, the users, computers, and applications in that branch office might be
able to continue to work, but they might experience slower response times for operations
such as logon. In this situation, an RODC can speed up response times and mitigate a
potential service-failure scenario. This represents a compelling deployment reason by itself.
• Small number of users in each location
A branch office might have few users and computers that require authentication and
authorization for network services and resources. However, there are no technical limitations
that prevent an RODC from supporting thousands of users and computers.
• Lack of dedicated IT experience in the branch office
Typically, few or none of an organization’s branch offices have dedicated IT personnel to
manage the local IT infrastructure. Therefore, access rights are often limited to the
performance of required tasks. In less-ideal cases, an organization may have to deploy a
domain controller to a branch office and grant elevated permissions to manage the domain
controller to one of the branch users to provide necessary IT services locally.

Deciding Which Type of Domain Controller

Meets the Needs of a Branch Office
Location
When you are planning a deployment of domain controllers in branch office locations, first, decide
which locations require domain controllers. Then, for the locations that do require domain
controllers, decide whether to install writable domain controllers or read-only domain controllers
(RODCs).

8
In general, you should plan to use as few domain controllers as possible, to help reduce costs.
Start by determining which domain controllers must be placed in the larger locations, such as
datacenters and hub locations, and then do the same for the remaining locations.

Datacenters and hub locations

Plan to place at least two writable domain controllers for each domain in datacenters and hub
locations. Application servers (such as servers running Microsoft Exchange Server) are often
placed in datacenter and hub locations. These servers in turn may need access to a writable
domain controller if they are Active Directory–integrated servers and they perform updates. In
most cases, deploying writable domain controllers is the best approach if these locations can be
secured and they have information technology (IT) personnel on site.
These locations also often have data that must be secured, such as human resource (HR)
records. They may also have other types of applications that include sensitive data, such as user
account provisioning systems. Because they often include data that requires a high level of
security and that is critical for maintaining operations in the organization, these locations typically
have strong physical security, a reliable networking infrastructure, and an experienced IT staff.
These characteristics also make these locations better suited for writable domain controllers than
for RODCs.
RODCs provide only limited security benefits for locations that also have writable domain
controllers deployed. However, some RODC features can provide administrative advantages. For
example, Administrator Role Separation makes it possible for RODC administration to be
delegated to a nonadministrative domain user. Because RODCs do not perform outbound
replication, they cannot replicate lingering objects to other domain controllers. For only those
administrative benefits, you might use an RODC in a location that has a writable domain
controller.

Branch offices and satellite locations

For your branch offices and other satellite locations, consider which of these locations requires a
domain controller of any type, whether read only or writable.
If you decide that a particular location requires a domain controller, consider other factors, such
as the type of data and services that are required to run in that location, the level of trust that you
have that the data and services will be handled securely, the frequency in which applications in
that location make writes to Active Directory Domain Services (AD DS), and the level of physical
security of the location, to decide which type of domain controller to place there.
The following sections and flowchart can help you decide whether to deploy domain controllers in
branch office locations and which type of domain controllers to deploy.

9
Deciding whether a branch office location
requires a domain controller
The first decision to make is whether you should place a domain controller in the branch office or
not. This is decided mostly by the quality of the wide area network (WAN) link between your
branch office and the hub site. If the WAN is highly reliable and available and if the performance
of directory-enabled applications and logons in the branch office is acceptable, you do not have to
place a domain controller at that branch office location.
Consider these factors when you are deciding whether to place a domain controller in a branch
office location:
• If a location has no domain controller locally, users in that branch office location are at
risk of being unable to log on and access some critical network resources if a WAN link fails,
which can lead to a loss of productivity. Each organization has to make a trade-off between
reliable availability of services to branch users and the cost of deploying and maintaining
infrastructure services, such as domain controllers, in the branch office. In addition, to enable
user logons in a multidomain forest, a domain controller for the user’s domain must be
available. Also, the domain controller in the branch office must be a global catalog server, or
universal group caching must be enabled in the corresponding site. For more information
about these two options, see Plan Global Catalog Servers.
• If you want to improve the logon times in a branch office, you can place a domain
controller in the branch office. The local domain controller can provide Group Policy objects
(GPOs) and logon scripts, which can improve logon performance.
A local domain controller can help reduce network logon traffic between the branch office and
the datacenter, but that benefit is offset by Active Directory replication traffic. However, you
can schedule Active Directory replication traffic to occur during nonbusiness hours.
For example, consider a network that has branch offices that are connected through slow
links to the headquarters. If the daily logon traffic and directory search traffic of a few remote-
site users causes more network traffic than replication of updates to the branch office, or if
you want to dedicate more bandwidth to business-critical applications during business hours,
consider adding a domain controller to the branch office location. An RODC does not create
any outbound replication to the hub site. An RODC can also apply GPOs to all the client
computers that are in its site, including accounts that are not cached on the RODC.
If reducing the cost of maintaining infrastructure services, such as domain controllers, is more
important than network traffic, or if the risk of productivity loss if the WAN is unavailable or
congested is considered very minor, centralize the domain controllers for that domain and do
not place any regional domain controllers at the branch office location.

Deciding which type of domain controller to

deploy
If a branch office has a writable domain controller and it meets your requirements in terms of
security, the service that it provides to end users, and the total cost of ownership (TCO) for

10
management, there is probably no reason to change your current infrastructure. Otherwise,
factors such as the trustworthiness of the location, the sensitivity of data that will be stored there,
and application compatibility can determine the type of domain controller to deploy.
For example, if the location has a Structured Query Language (SQL) server that includes all
employee account information, it requires a higher level of trust and should be secured in an
appropriate manner. In this case, deploying an RODC may not improve the security of that
location.
RODCs are designed to be deployed in locations that have a critical need for local authentication
and authorization services but that also lack the trustworthiness and physical security
requirements that are appropriate for a writable domain controller.

Security Note
Accounts that are members of the Domain Admins group (or similarly privileged
accounts) should logon interactively only to a trusted computer. If a computer in a branch
office, such as an RODC or a File server, is not trusted, then privileged accounts should
not use the console or remote desktop to log on to it, thus providing that computer with
the clear text password or the logon session. RODCs provide mechanisms to delegate
local administration of the RODC without requiring privileged accounts. Delegated RODC
administration mitigates risk but still provides the benefits of having Active Directory
Domain Services deployed close to users and computers.
In many cases, branch offices are locations that lack trustworthiness. Therefore, if a branch office
requires a domain controller, RODCs should be the first choice over writable domain controllers
because they are designed specifically for branch office environments. Some of the functionality
that RODCs provide helps meet branch office challenges in very practical ways:
• Read-only database and one-way replication
An RODC performs only inbound replication. Therefore, no data ever replicates out of the
branch office. This improves security by preventing malicious or accidental updates in a
branch office from replicating to the rest of the forest. It also reduces the load on hub site
domain controllers that replicate with domain controllers in branch offices. This helps resolve
one of the most critical bottlenecks for branch office deployments that use domain controllers
running Windows Server 2003: inbound replication on hub site domain controllers. For more
information about inbound replication on hub site domain controllers, see the
Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?
LinkID=28523).
Another important benefit of unidirectional replication is the reduced cost to manage the
Active Directory replication topology in branch offices. If you use RODCs in branch offices,
you do not have to use the Active Directory Load Balancing tool (Adlb.exe) to stagger
replication connections or schedules, as recommended in the Windows Server 2003
Active Directory Branch Office Guide. RODCs have a built-in mechanism to automatically
redistribute connections across a number of possible Windows Server 2008 bridgehead
servers when you add or remove bridgehead servers in the hub site. Also, unidirectional
replication eliminates the need to manage and monitor complex schedules for the bridgehead
servers to replicate updates from the branch offices.

11
• DFS Replication of SYSVOL content
At the Windows Server 2008 domain functional level, you can use Distributed File System
(DFS) Replication, instead of File Replication Service (FRS), to replicate updates to the
SYSVOL folder between domain controllers. Because it is more scalable than FRS,
DFS Replication of SYSVOL makes unnecessary the recommendation in the
Windows Server 2003 Active Directory Branch Office Guide to limit the number of domain
controllers for each domain to 1200. However, if you plan to deploy more than 1200 domain
controllers in a single domain, you should be extremely careful about the monitoring
processes and troubleshooting procedures that you have in place to support a deployment of
that scale. Microsoft System Center Operations Manager 2007 can help you monitor your
branch office environment.
• Computer replacement after system failure
Replacing a failed RODC is easier than replacing a failed writable domain controller. This
operation can be delegated to a nonadministrative user, and there is no data that must be
retrieved and saved before the replacement. RODCs never maintain any unique critical
pieces of information. No write operations are performed on the RODCs. Therefore, they
never contain information that is not yet replicated to other domain controllers. For more
information, see RODC Removal and Reinstallation (http://go.microsoft.com/fwlink/?
LinkId=151600).
• Password Replication Policy and Filtered Attribute Set
The Password Replication Policy (PRP) and Filtered Attribute Set (FAS) features of RODCs
help improve the security of branch offices, compared to writable domain controllers. A
common problem in branch offices is the lack of physical security and a higher potential for
the domain controller in the branch office to be either compromised or stolen. RODCs make it
possible for you to limit credentials and credential-like data in the branch office. For more
information about these features, see RODC Filtered Attribute Set, Credential Caching, and
the Authentication Process with an RODC (http://go.microsoft.com/fwlink/?LinkId=151602).
If an RODC is stolen, most likely only the user credentials that are replicated to it must be
reset. (You can reset the credentials with the Active Directory Users and Computers snap-in.)
Also, the attacker cannot read any credential-like data that is included in the FAS locally on
the RODC. For more information, see Securing Accounts After an RODC Is Stolen
(http://go.microsoft.com/fwlink/?LinkId=151603).
• Deployment and administration
An RODC can be installed directly onsite by a domain user who has been delegated the right
to promote only that particular RODC. This user, who does not have to be a domain
administrator, can then perform tasks that a normal server operator would perform, such as
applying updates, performing disk defragmentation, and so on. The ability of a delegated user
to install an RODC and the ability to install the RODC directly in the branch office are two
factors that can make it unnecessary to use a staging site to prepare a domain controller
before it is installed in the branch office. This makes deployment of the branch office domain
controller easier. It also significantly reduces the cost of maintaining the domain controller in
the remote location.

12
 Another new feature that aids RODC deployment is Install from Media (IFM). For RODCs,
you can create installation media that does not contain any credentials or any attribute from
the FAS. The RODC media prevents secrets, such as passwords, from being on the
installation media during transport or while the RODC is getting installed or running. For more
information, see Installing Active Directory Domain Services from Media
(http://go.microsoft.com/fwlink/?LinkID=132630).
• WAN link utilization
RODCs can reduce network traffic by satisfying user and computer logon and authorization
requests and performing Active Directory searches locally in the branch office. A general
principle for deploying infrastructure is to deploy it physically as close as possible to the users
who will use the services.
For example, suppose that you deploy an RODC with the global catalog server option in a
branch office. In addition, you have the RODC cache the passwords for branch office users,
their computers, and the other branch office servers that host resources that the users need
to access. In this situation, the RODC in the branch office can provide authentication and
authorization to local resources, and it can satisfy Lightweight Directory Access Protocol
(LDAP) searches within the branch office without requiring any WAN connectivity to the hub.
The RODC also applies Group Policy to any branch office user and computer, even those
users whose passwords are not cached on the RODC.
This use of an RODC helps reduce network traffic in comparison to not placing any domain
controller in the branch office. It can also help avoid unavailability of the directory service for
the branch office users when the WAN connection is not available. Although changes that
happen elsewhere in the forest have to replicate to the RODC in the branch office, you can
schedule that replication to occur during off-peak hours. This can help free up bandwidth for
line-of-business (LOB) applications during peak hours. Note that write operations, however,
must be performed by a writable domain controller in a hub site. Therefore, they require
bandwidth.
When you consider whether to place a writable domain controller or an RODC in a branch office
location, consider the trade-off between completeness of service offered in the branch office on
one side and reduction of both the TCO of having a branch office domain controller and the risk
due to the lack of physical security in the branch office on the other side.
Physical security ensures that unauthorized users cannot turn domain controllers on or off, add or
remove hardware, insert or remove removable media, log on by using the keyboards and displays
of domain controllers, or remove backup media.
While the items in the previous list explain the advantages of RODCs that can help reduce the
cost of administering a domain controller in a branch office location, there are still certain
conditions under which organizations cannot deploy RODCs in their branch offices:
• Application compatibility
Most directory-enabled applications only have to read data from the directory. As a result,
these applications should work without problems with RODCs anytime—even if connectivity
to a writable domain controller is not available, for example, when the WAN is offline.
However, some applications must be able to write to AD DS. If these applications are located

13
 in the branch office and they cannot be relocated to the hub, you may have to install a
writable domain controller in the branch office if the applications have to make updates to
AD DS even when the WAN is not available.
For more information, see the Read-Only Domain Controllers Application Compatibility Guide
(http://go.microsoft.com/fwlink/?LinkID=117785).
You should test applications that run in the branch office to make sure that they work with
RODCs. One widely used application that is known to not work with RODCs is
Exchange Server. Therefore, you should carefully consider whether you really need to run
Exchange Server in the branch office location or you should consolidate your
Exchange Server infrastructure in a centralized location.
In addition, some applications may not work correctly if they are installed directly on an
RODC. If the RODC is the only server in the branch office and the branch office must run this
type of application, consider the following alternatives:
• Deploying a writable domain controller in the branch office location
• Running the RODC or the application in a virtual machine (VM)
• Deploying additional server hardware to the branch office location to run the other
application.
Finally, an application may target a writable domain controller even though the application
only performs read operations. In this case, you must either deploy a writable domain
controller to support the application; reconfigure the application to work with RODCs; or
relocate the application to a place, such as a datacenter or hub location, where it can use a
writable domain controller. The assumption for these solutions is that having these
applications access domain controllers across the WAN is not acceptable.
• Service with the WAN offline
When the WAN is offline, an RODC can authenticate only the users and resources for which
it has cached passwords. If you have a strong requirement that any user must be able to
authenticate in the branch office location, you may want to place a writable domain controller
at that branch office location. As an alternative, you can place an RODC at the branch office
location and configure the RODC so that all users’ credentials are allowed to replicate to it.
You can then have an automated process in place that caches the credentials of the users,
computers, and other resources that are located in the branch office. This way, you can take
advantage of other RODC features.
If a location requires a writable domain controller, deploy it where you can ensure its physical
security and only allow authorized administrators to access it. A malicious person who has
physical access to a writable domain controller can gain access to sensitive data that is stored in
AD DS, such as passwords, by using a variety of methods. For example, in this situation an
attacker can:
• Access physical disks by starting an alternate operating system.
• Remove (and, possibly, replace) physical disks on a domain controller.
• Obtain and manipulate a copy of a domain controller system state backup.

14
Take appropriate precautions to restrict unauthorized access to branch office domain controllers.
Windows® BitLocker™ Drive Encryption can partially mitigate a few of these risks, but it does not
completely eliminate the risks that are inherent with inadequate physical security of a server. For
more information about BitLocker, see BitLocker Drive Encryption
(http://go.microsoft.com/fwlink/?LinkId=141479).
If you place a writable domain controller in the branch office, you must also make sure that it can
be administered and maintained by a domain administrator.
You can use the following flowchart to decide whether a branch office location requires a domain
controller and which type of domain controller it requires.

Differences Between Recommendations in

the Windows Server 2003 Branch Office
Guide and Default Settings for RODCs
In many cases, read-only domain controllers (RODCs) provide default settings that eliminate the
need to implement complex configurations that are described in the Windows Server 2003
Branch Office Guide. The following table compares how some best practices are implemented in
the Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?
LinkID=28523) and how you can achieve the same results using RODCs.

15
There are also best practices in the Windows Server 2003 Active Directory Branch Office Guide
that still apply to RODCs. For more information, see Recommendations from the Windows Server
2003 Branch Office Guide That Still Apply to RODCs.

Best practice Windows Serv Windows Serv Notes

er 2003 er 2008
Active Directo RODC
ry Branch
Office Guide

Minimize replication that is Create branch Use the Using staged installation
required to install domain office domain staged prevents exposure of Domain
controllers in branch offices controllers in installation Admin credentials in branch
a staging site process to offices, and Dcpromo.exe in
at corporate install RODCs Windows Server 2008 makes
headquarters, directly in the installation of RODCs directly
and then ship branch office into an Active Directory site
the domain locations. possible. In addition, you can
controllers to use the Install from Media (IFM)
their final feature to reduce the replication
destination in requirements for installation of
branch Active Directory Domain
offices. Services (AD DS). For more
information about using staged
installation, see Performing a
Staged RODC Installation
(http://go.microsoft.com/fwlink/?
LinkID=133259). For more
information about IFM, see
Installing AD DS from Media
(http://go.microsoft.com/fwlink/?
LinkID=132630).

A client computer should Configure By default, Group Policy for disabling

always first try to communicate client RODCs do automatic site coverage is no
with a local domain controller. computers to not perform longer necessary for RODCs. If
communicate automatic site you maintain only RODCs in
with a local coverage. your branch offices, you can
domain revert the corresponding
controller by changes that were
using a recommended in the chapter
Group Policy “Planning a DNS Structure for
setting that the Branch Office Environment”
disables in the Windows Server 2003
automatic site Active Directory Branch Office

16
 coverage that Guide
domain (http://go.microsoft.com/fwlink/?
controllers LinkID=28523).
perform for
other sites.

Client computers in branch Client Make all By default, Dcpromo.exe makes

offices query Domain Name computers RODCs in RODCs DNS servers and
System (DNS) servers to queried DNS branch offices global catalog servers. This
update resource records, servers and be DNS ensures that when wide area
locate servers, and query global catalog servers and network (WAN) connectivity to a
global catalog servers for servers in hub global catalog hub site is not available, branch
network logons. sites, or servers. office client computers can
universal query DNS locally to locate
group other servers in the same site
membership and query the global catalog
caching could locally for network logon.
be enabled for
branch office
sites instead
of global
catalog server
placement.

Hub site client computers and Create a By default, Group Policy for name server
resources should never have Group Policy RODCs (NS) resource record
to use a domain controller in a object (GPO) register only registration is no longer
branch office location for DNS so that non- site-specific necessary if you maintain only
or Lightweight Directory site-specific resource RODCs in branch offices. If you
Access Protocol (LDAP) records records. They maintain writable domain
queries, authentication, and so (including do not register controllers in branch offices,
on. delegation delegation or you can re-enable name server
entries and name server (NS) resource record
name server (NS) resource registration by using a registry
(NS) resource records. key and access control list
record (ACL) changes in DNS.
registrations)
are not
registered,
and manage
the GPO by
using
computer
groups.

17
To avoid overloading the Turn off KCC RODCs A best practice is to use
bridgehead servers for File failover on should not Distributed File System (DFS)
Replication Service (FRS) branch office use Branch Replication to replicate
replication, enable Branch domain Office Mode SYSVOL. For more information,
Office Mode for the controllers, for see Plan for DFS Replication
Knowledge Consistency and enable redundancy for SYSVOL.
Checker (KCC). For more redundant because they
information about Branch connection automatically
Office Mode, see the objects. redistribute
Windows Server 2003 connection
Active Directory Branch Office objects. For
Guide more
(http://go.microsoft.com/fwlink/ information,
?LinkID=28523). see Review
Bridgehead
Server Load-
Balancing
Improvements
with Windows
Server 2008
RODCs.

When you add a new Run Adlb.exe By default, Adlb.exe is not needed or
bridgehead server, redistribute manually to RODCs supported for RODCs.
connection objects to utilize redistribute automatically However, you can continue to
the new capacity. connections redistribute use it to redistribute connection
across connections objects between writable
bridgehead when a new domain controllers.
servers. bridgehead
(Move a server is
maximum of added.
10 Redistribution
connections works without
at a time.) having to use
preferred
bridgehead
server lists.

Planning for RODCs in Branch Offices

The section describes the following planning steps:
• Review the Existing Active Directory Design. This includes the following:

18
 • Evaluate Your Active Directory Logical Structure
• Review Policy Settings and Network Settings
• Determine the Domain Upgrade Order
• Review the Existing Physical Structure
• Recommendations from the Windows Server 2003 Branch Office Guide That Still
Apply to RODCs
• Plan Replication for Branch Offices. This includes the following:
• Plan for DFS Replication for SYSVOL
• Review Bridgehead Server Load-Balancing Improvements with Windows Server
2008 RODCs
• Plan the Hub Site Deployment
• Plan DNS Servers for Branch Office Environments
• Plan Global Catalog Servers

Review the Existing Active Directory Design

Before you begin an installation of read-only domain controllers (RODCs) in a branch office
location, review information about your existing Active Directory design, including information
about the logical and physical designs. The logical design includes the forest, domain, and
organizational unit (OU) structure for users, computers, and other resources. The physical design
includes information such as network maps and site topology.
Knowing how many users and computers you have in the branch office can help you determine
whether to deploy an RODC in a branch office. If you deploy an RODC, this information can also
help you determine how to plan and administer the Password Replication Policy (PRP).
You can use a tool such as the Microsoft Active Directory Topology Diagrammer to create a visual
diagram that includes the existing domains, sites, servers, administrative groups, and
connections. The Microsoft Active Directory Topology Diagrammer is a free download at the
Download Center (http://go.microsoft.com/fwlink/?LinkId=122938).
• Evaluate Your Active Directory Logical Structure
• Review Policy Settings and Network Settings
• Determine the Domain Upgrade Order
• Review the Existing Physical Structure
• Recommendations from the Windows Server 2003 Branch Office Guide That Still Apply to
RODCs

19
Evaluate Your Active Directory Logical
Structure
Many organizations that add Windows Server 2008 domain controllers to their existing
Active Directory environment—including read-only domain controllers (RODCs) in branch office
locations—also review the logical structure of their current environment and look for ways to
improve it. The introduction of Windows Server 2008 domain controllers does not necessarily
require any changes to your existing logical structure. However, it can present an opportunity to
lower costs by reducing the number of domains that you currently have deployed. By reducing the
number of domains, you can reduce complexity, improve efficiency, and reduce the administrative
costs of running your environment.
For example, the following illustration of the forest for a fictional company called Contoso
Pharmaceuticals shows the logical structure that was recommended in the Windows Server 2003
Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?LinkID=28523), including:
• A corporate (corp) domain for the forest root
• A headquarters (hq) domain for the datacenter
• A branches domain for all the branch office locations

Figure 1

20
In Windows Server 2003, using separate domains in this manner provided an organization with
administrative benefits, such as centralized administration of network resources and autonomy
between the datacenter and the branch offices.
In Windows Server 2008, you might obtain the same benefits by deploying a single domain.
Therefore, your Windows Server 2008 branch office planning process can be a good time to
revisit the decisions that led to your current logical structure design. You can confirm that the
factors that led to those decisions are still relevant. You can also evaluate whether the cost of
migrating to a consolidated environment is offset sufficiently by the savings that are obtained from
the use of these new features.
The following table includes a list of issues that have led organizations to deploy multiple domains
in the past, along with new Windows Server 2008 features that are designed to address these
issues. You can review the table for issues that are relevant to your environment. Then, you can
determine whether the new features in Windows Server 2008 justify any changes to your existing
logical structure.

Issues that can require the deployment of an New Windows Server 2008 features that address
additional Windows Server 2003 domain these issues

Different password policy requirements for
different departments within an organization
At the Windows Server 2008 domain functional
level, you can configure fine-grained password
policies (FGPPs) to require different password
policies for different sets of users within a single
domain.

The scalability of File Replication Service
(FRS), which is used to replicate SYSVOL
contents between domain controllers. The
recommended maximum number of domain
controllers in one domain is 1,200.
At the Windows Server 2008 domain functional
level, Distributed File Service (DFS) Replication
is used to replicate SYSVOL. Because
DFS Replication can scale more effectively than
FRS, you can deploy more than 1,200 domain
controllers in a single domain. However, if you
plan to deploy more than 1,200 domain
controllers in a single domain, ensure that you
have an appropriate monitoring solution and
troubleshooting procedures to manage an
environment that large.

For more information about these features and other new features in Windows Server 2008, see
What's New in Active Directory Domain Services in Windows Server 2008
(http://go.microsoft.com/fwlink/?LinkID=117789).
For more information about designing a logical structure, see Designing the Logical Structure for
Windows Server 2008 AD DS (http://go.microsoft.com/fwlink/?LinkID=89024).

21
ADMT
If you plan to reduce the number of domains that you are currently operating, you can use the
Active Directory Migration Tool (ADMT) version 3.1 (v3.1) or non-Microsoft migration tools to
migrate user, group, and computer accounts from one domain to another. ADMT v3.1 is available
at the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=122944).
Be sure that the domain controllers in the target domain are running Windows Server 2008 before
you start the migration. ADMT v3.1 is specifically designed to work with migrations in which the
target domain controllers run Windows Server 2008. ADMT v3.1 is also required if you migrate
client computers that run Windows Vista.
For more information about using ADMT v3.1, see ADMT v3.1 Guide: Migrating and Restructuring
Active Directory Domains (http://go.microsoft.com/fwlink/?LinkID=93678).

Review Policy Settings and Network Settings

Before you begin an installation of read-only domain controllers (RODCs) in branch office
locations, review all the Group Policy settings that are currently used in your environment. Assess
how these Group Policy settings might be affected by the RODC deployment.
Some policy settings, such as the settings that enforce Server Message Block (SMB) packet and
secure channel signing, are enabled by default on domain controllers that run
Windows Server 2003 and Windows Server 2008. Some organizations might disable these
settings to allow client computers that run earlier versions of Windows to communicate with
Windows Server 2008 domain controllers. For more information, see Modify Default Security
Policies on Windows Server 2008–Based Domain Controllers (http://go.microsoft.com/fwlink/?
LinkId=141480).
If you are using a Group Policy object (GPO) to control how client computers fail over to a hub
site domain controller when the domain controller in their branch office location is not available,
as described in the Windows Server 2003 Active Directory Branch Office Guide
(http://go.microsoft.com/fwlink/?LinkID=28523), update the security group that is used to filter the
policy. The 2003 guide recommends that the security group membership include hub site domain
controllers so that only those domain controllers register service (SRV) resource records.
During the transition period in which there might be RODCs in some branch offices and writeable
domain controllers in other branch offices, add the Read-only Domain Controllers default security
group to the security group that you use to filter the policy. The security group is named Hub-DCs
in the example in the following procedure. This excludes the RODCs from the policy. By default,
RODCs do not register service (SRV) resource records for other sites.
Membership in Domain Admins, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

To add members to the Hub-DCs security group

1. Open the Active Directory Users and Computers snap-in. In Active Directory Users

22
 and Computers, click the Domain Controllers OU, and then in the details pane, double-
click the Hub-DCs group.
2. In the Hub-DCs Properties dialog box, click the Members tab.
3. Click Add, click Object Types, click Computers, and then click OK.
4. In the Select Users, Computers, or Groups dialog box, type Read-Only Domain
Controllers and the names of the domain controllers from the Branches domain that are
supposed to be located in Data-Center-Site, separated by semicolons.
5. Click Check Names.
6. After the names resolve, click OK to add the names to the group.
7. In the Hub-DCs Properties dialog box, verify that all the domain controllers are
added to the group, and then click OK.
8. To ensure that the new domain controllers recognize their new group membership
and are able to apply security settings on the GPO correctly, reboot all the domain
controllers in the Hub-DCs group.

Determine the Domain Upgrade Order

Before you begin an installation of read-only domain controllers (RODCs) in branch office
locations, determine the order of the domain upgrades. The recommended order for upgrading
domains in an existing branch office deployment is as follows:
1. Beginning with the domain that contains the branch offices, install writeable Windows
Server 2008 domain controllers in the hub sites. This step is the minimum that is required for
deployment of RODCs in the branch offices. Most organizations will want to make sure that
all hub site domain controllers for every domain are running Windows Server 2008 before
they begin to deploy RODCs in branch offices, either because their deployment begins with
sites that host the most critical infrastructure services or to coincide with predefined
schedules for hardware and software replacement.
2. For the same domain, upgrade or replace the existing domain controllers in the branch
offices with RODCs.
3. Raise the domain functional level to Windows Server 2008.
4. For the remaining domains, upgrade or replace the remaining domain controllers with
Windows Server 2008 domain controllers.
The rest of this topic explains this sequence in more detail. For more information about
prerequisites for deploying an RODC, see Prerequisites for Deploying an RODC.
If you have multiple domains in your forest, begin the installation of writeable
Windows Server 2008 domain controllers (either clean installations or upgrades of
Windows Server 2003 domain controllers) in the domain where you plan to use RODCs.
Writeable domain controllers running Windows Server 2008 must be deployed in that domain

23
before you can introduce RODCs in your branch offices. For example, if the forest has three
domains, as shown in the illustration in Evaluate Your Active Directory Logical Structure, start the
deployment process by installing Windows Server 2008 domain controllers in the Branches
domain. The Branches domain contains the users and computers in the branch office locations.
In this scenario, first upgrade or deploy new writeable Windows Server 2008 domain controllers
from the Branches domain that are running in the Data-Center-Site. These domain controllers,
which are shown in the illustration in Review the Existing Physical Structure, are the operations
master (also known as flexible single master operations or FSMO) role holders named HubDC1
and HubDC2 and the bridgehead servers named BHDC1, BHDC2, BHDC3, and so on.
As a best practice, replace all the Windows Server 2003 domain controllers from the Branches
domain in the Data-Center-Site with writeable Windows Server 2008 domain controllers before
you begin to deploy RODCs in branch office locations. If you have all these domain controllers
running Windows Server 2008, the RODCs that you subsequently add to the domain will be load
balanced across the bridgehead servers automatically. You will not have to use the Adlb.exe tool
to evenly distribute the replication workload for RODCs. However, you can continue to run
Adlb.exe on the writeable Windows Server 2008 domain controllers in the Data-Center-Site to
load-balance the replication connections that they have with the Windows Server 2003 domain
controllers in the branch offices during the transition period when you are replacing the branch
office domain controllers with RODCs. For more information about using Adlb.exe during the
transition, see Preventing Bridgehead Server Overload During a Transition.
You do not have to replace all the Windows Server 2003 domain controllers from the Branches
domain in the Data-Center-Site before you start to deploy RODCs. A writeable
Windows Server 2008 domain controller is required for an RODC to replicate domain data and to
enforce the Password Replication Policy (PRP). If you cannot replace all the Data-Center-Site
domain controllers for the Branches domain before you begin to deploy RODCs, you should
deploy at least two writeable Windows Server 2008 domain controllers so that the RODCs can fail
over to the second Windows Server 2008 domain controller if the first domain controller is not
available. If you have only one writeable Windows Server 2008 domain controller and it becomes
unavailable, none of the RODCs that you deploy can replicate the domain partition, including
passwords, and you cannot make any changes to the PRP.
Another factor to consider when you are choosing which domains to upgrade is a plan to migrate
from File Replication Service (FRS) to Distributed File System (DFS) Replication for SYSVOL. If
you want to use DFS Replication for SYSVOL, the domain functional level must be
Windows Server 2008. As a best practice, plan to raise the domain functional level to
Windows Server 2008 as soon as possible because DFS Replication provides better support for
SYSVOL on RODCs than File Replication Service (FRS) does. In particular, if possible, you
should raise the domain functional level to Windows Server 2008 and migrate to DFS Replication
before you begin to add RODCs to branch office locations that did not previously have any
Windows Server 2003 domain controllers. This way, when you add RODCs they will automatically
use DFS Replication for SYSVOL. However, this is not a requirement for introducing RODCs, and
it is practical mostly in environments that have only a few domain controllers deployed in branch
offices. For more information, see Plan for DFS Replication for SYSVOL.

24
You can upgrade or replace the Windows Server 2003 domain controllers in other domains
anytime if they will not have any RODCs. However, domain controllers in the other domains must
run Windows Server 2003 or Windows Server 2008 because RODCs require the forest functional
level to be Windows Server 2003.
To replace existing Windows Server 2003 domain controllers, you can either upgrade them
directly to Windows Server 2008 or decommission them and replace them with new servers. For
more information, see Upgrading Active Directory Domains to Windows Server 2008 AD DS
Domains (http://go.microsoft.com/fwlink/?LinkId=141481).

Review the Existing Physical Structure

Review the current site topology for your organization to determine which sites will be candidates
for read-only domain controllers (RODCs) and where to place the writable domain controllers that
they will replicate from. Windows Server 2008 domain controllers can usually be integrated easily
into your existing site topology. The following illustration from the Windows Server 2003
Active Directory Branch Office Guide shows an example of a site topology, including the location
of domain controllers in each site.

25
We no longer recommend using a staging site for deploying domain controllers to branch offices
when these domain controllers are RODCs, contrary to the recommendation in the
Windows Server 2003 Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?
LinkID=28523). This is because you can deploy RODCs by using a staged, delegated installation
process. In this process, the RODCs are installed directly in branch office locations in the
appropriate site by a delegated administrator. This differs from the process for
Windows Server 2003, in which domain controllers were installed in the staging site by a member

26
of the Domain Admins group and then moved to their respective branch sites. This action was
followed by cleanup of the Knowledge Consistency Checker (KCC) connections.
As an alternative, you can continue to use a staging site to install RODCs in a centralized location
before you transport them to a branch office, as described in the Windows Server 2003 Active
Directory Branch Office Guide. However, this RODC guide focuses on the new, staged installation
process.
In addition, review where Domain Name System (DNS) servers, global catalog servers, and
operations master (also known as flexible single master operations or FSMO) roles are placed.
The recommendation for deploying DNS servers and global catalog servers in branch offices is
also changed from Windows Server 2003. Whereas the Windows Server 2003 Branch Office
Guide provided no recommendation, in a Windows Server 2008 domain where writable domain
controllers are deployed in hub sites and RODCs are deployed in branch offices, the best practice
is to add the global catalog and DNS server role to the RODCs. This helps ensure that client
computers in the branch offices can continue to log on and complete DNS lookups for local
resources if wide area network (WAN) connectivity to a hub site domain controller is not available.
There are no changes to the recommendations for placing operations master roles. The following
figure shows an example of a site topology with Windows Server 2008 domain controllers.

27
28
Recommendations from the Windows Server
2003 Branch Office Guide That Still Apply
to RODCs
The following table lists some of the recommendations from the Windows Server 2003 Branch
Office Guide that still apply to installations of read-only domain controllers (RODCs).
Recommendation
In most cases, organizations with many branch
offices choose to disable the Bridge all site
links option. However, each organization must
assess for itself the advantages and
disadvantages of disabling this option. For
more information, see Enabling the Bridge All
Site Links Option.
Make all domain controllers in branch offices be User logons in a multidomain forest require
global catalog servers.
All domain controllers in the branch offices are
Domain Name System (DNS) servers. They
should point to themselves as the preferred
DNS server and another DNS server in a hub
site as an alternate DNS server.
Client computers and server computers in the
branch offices should be configured with at
least two DNS server IP addresses.
The DNS client should be configured to use a
preferred DNS server that is located in the
same branch office or at least in the same site.
The alternate DNS server should be a DNS
server in the datacenter (hub site).
Reason
Prevents Active Directory replication on a
domain controller from failing over to another
branch office when the hub site is temporarily
unavailable. Also reduces the load on the
domain controllers in the hub site.
either a global catalog or universal group
caching to be enabled for the site. We
recommend whenever possible that you use a
global catalog server in the branch office, rather
than enabling universal group caching.
Provides fast local name resolution of
resources. If the wide area network (WAN) fails,
client computers can still find resources in their
local branch offices.
Branch office client computers look up DNS
data on a domain controller in the branch office.
If the WAN fails, client computers can still find
resources in their local branch offices.
29
Plan Replication for Branch Offices
The topics in this section describe the following issues that are related to planning replication for
branch office installations of read-only domain controllers (RODCs):
• Plan for DFS Replication for SYSVOL
• Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008
RODCs
• Plan the Hub Site Deployment

Plan for DFS Replication for SYSVOL

The SYSVOL shared folder contains logon scripts and Group Policy objects (GPOs) for a domain.
It replicates to all domain controllers, including read-only domain controllers (RODCs). If you
create a new domain and select the Windows Server 2008 domain functional level during the
installation of Active Directory Domain Services (AD DS), SYSVOL contents are replicated by
Distributed File System (DFS) Replication by default. You do not have to perform migration from
File Replication Service (FRS) in this situation.
If SYSVOL is not replicated with DFS Replication, it is replicated with FRS by default. After you
raise the domain functional level to Windows Server 2008, you can use the Dfsrmig.exe tool to
migrate from FRS replication to DFS Replication of SYSVOL.
The process for migration from FRS replication to DFS Replication is designed to minimize any
potential downtime for the contents of the SYSVOL shared folder.

Important
If the SYSVOL shared folder is not available on a domain controller, users and computers
will not be able to log on using that domain controller.
This process is designed with multiple steps to make monitoring of the migration easy, and it
accounts for replication latency. During the migration, you can retain detailed control, perform
backup and restore operations, and roll back anytime before you commit entirely to the migration.
The process for migration from FRS replication to DFS Replication accounts for RODCs and for
scenarios in which multiple domain controllers are deployed in one or more hub sites and branch
offices. The process does not depend on all domain controllers being online or reachable at the
time of the migration.
The DFS Replication service detects the migration process when it polls AD DS. Then, it performs
the steps that are required to migrate the domain controller.
For more information about the process for migration from FRS replication to DFS Replication,
see the SYSVOL Replication Migration Guide: FRS to DFS Replication
(http://go.microsoft.com/fwlink/?LinkID=93057).

30
Review Bridgehead Server Load-Balancing
Improvements with Windows Server 2008
RODCs
One of the benefits of deploying read-only domain controllers (RODCs) in branch offices is
unidirectional replication. Bridgehead servers in a hub site do not replicate Active Directory data
from the RODCs in each branch office, which reduces the inbound replication load on the
bridgehead servers and also reduces administration and network usage. For outbound replication
from the hub site to the branch office sites, RODCs provide load-balancing improvements that
help distribute outbound replication connections evenly across a set of bridgehead servers. This
topic explains how load-balancing was typically handled in branch office deployments that used
previous versions of Windows Server. It also explains how RODCs in Windows Server 2008 can
improve load-balancing by redistributing replication connections automatically.
With previous versions of Windows Server, after you add a new bridgehead domain controller in a
hub site (for example, for hardware replacement), there is no automatic mechanism to redistribute
the replication connections between the branch domain controllers and the hub domain
controllers to take advantage of the new hub domain controller for replication.
For example, consider a hub site that has two Windows Server 2003 domain controllers that
replicate with domain controllers in six different branch offices. If you add a third domain controller
in the hub site, none of the replication connections is automatically redistributed to the additional
domain controller in the hub site.
For Windows Server 2003 domain controllers, you can rebalance the workload by using a tool
such as Adlb.exe, which is included in the download package for the Windows Server 2003
Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?LinkID=28523).
For Windows Server 2008 RODCs, normal operation of the Knowledge Consistency Checker
(KCC) provides load-balancing, which eliminates the need to use an additional tool such
Adlb.exe. The automatic load-balancing is enabled by default. If you do not want RODC
replication connections to be redistributed automatically and you prefer to distribute the load
(Adlb.exe will not distribute the load from RODCs), you can disable automatic load-balancing by
adding the following registry key on each RODC that you want to exclude from load-balancing:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
“Random BH Loadbalancing Allowed”
1 = Enabled (default), 0 = Disabled

Note
The new automatic load-balancing applies only to RODCs. If you have writeable domain
controllers in branch sites and you add a new bridgehead server in the hub site, continue
to use a tool such as Adlb.exe to redistribute the workload across all the hub site
bridgehead servers.

31
Example: How bridgehead server load-balancing works
When the KCC on an RODC detects a new bridgehead server candidate that it can replicate
from, it determines whether to switch replication partners to that new bridgehead. This decision is
based on an algorithm that provides probabilistic load-balancing.
For example, assume that there is a hub site with four bridgehead servers, named Hub-DC-01
through Hub-DC-04, as shown in the following illustration. There are 100 RODCs that perform
inbound replication from the four bridgehead servers—a 25:1 ratio.

Note
This ratio is intended only to illustrate how the new load-balancing for RODCs works. It is
not intended to be a recommended ratio.

Another bridgehead server (Hub-DC-05) is added to the hub site, which creates a total of five.
When each RODC replicates the Configuration partition from a bridgehead server, it detects the
new bridgehead server. Then, on the next KCC run, the KCC determines whether the RODC
should switch its replication connection to the new bridgehead server.
There is a one-in-five chance (a 20-percent probability) that an RODC will switch its replication
connection. After all 100 RODCs have performed this operation, approximately 20 of them will
have switched to replicate from the new bridgehead server.

32
If you remove a bridgehead server from the hub site, the KCC on each RODC that replicates with
that bridgehead server again automatically creates a new connection object with one of the
remaining bridgehead servers. There is no minimum number of hub bridgehead servers required
for the load-balancing to work.
If you add more RODCs in the branches without adding more bridgehead servers in the hub site,
the new connections are also balanced across the static set of bridgehead servers.

Failover for FRS replication of SYSVOL

The File Replication Service (FRS) connection object on an RODC must use the same target as
the connection object that the KCC generates on the RODC for Active Directory replication. To
achieve this, the fromServer value on the two connections is synchronized. If you are using FRS
to replicate SYSVOL, the connection that is used for replication of SYSVOL data will also be
switched to the new bridgehead server.
However, only the removal of the old connection triggers the fromServer value on the FRS
connection object to change. The removal step happens, depending on the environment, up to
eight hours after the new connection object is created. Consequently, the fromServer value
continues to reference the original partner until the old connection is removed by the KCC.
A side effect of this is that while Active Directory replication works successfully against the new
partner, FRS replication fails during this period. The additional delay is by design; it avoids
causing FRS to perform an expensive version vector join (vvjoin) operation against the new

33
partner. FRS performs a vvjoin operation when it creates a new connection. In this case, the new
connection is not necessary if the outage of the original partner is only temporary.

Note
Whenever a new connection object is created, FRS performs a vvjoin operation with its
new replication partner while they synchronize their SYSVOL replication. Vvjoin is a CPU-
intensive operation that can affect the performance of the server. It can also generate
replication traffic. If there is a high number of connection failures that cause the KCC to
create new connection objects frequently, the vvjoin operations can seriously affect
server performance. For more information, see the Windows Server 2003
Active Directory Branch Office Guide (http://go.microsoft.com/fwlink/?LinkID=28523).
For more information about the KCC and Active Directory replication, see the Active Directory
Replication Topology Technical Reference (http://technet.microsoft.com/en-
us/library/cc755326.aspx).
Under most circumstances, you do not have to take any action when the FRS connection object
for an RODC fails over to a new server. If you plan for the original replication partner to be online
again within eight hours or if there is no need to replicate SYSVOL contents during that time, wait
for the KCC to update the connection objects automatically.

Plan the Hub Site Deployment

Plan to deploy Windows Server 2008 writeable domain controllers in your hub sites before you
begin to deploy read-only domain controllers (RODCs) in branch offices.
As a best practice, make all your bridgehead servers run Windows Server 2008 before you install
any RODCs. This helps ensure that RODC replication connections are evenly load-balanced
across all the bridgehead servers and that failover for RODCs works automatically. You should
also make sure that hub site bridgehead servers host all the partitions that RODCs must
replicate, including global catalog partitions and DNS application directory partitions.
If you are using preferred bridgehead server lists, make sure that they include at least one
writeable Windows Server 2008 domain controller in the same domain as the RODCs. RODC
replication will fail if the servers in the list do not host all the partitions that the RODCs must
replicate. We recommend that all the bridgehead servers run Windows Server 2008 to make
troubleshooting replication errors easier and to ensure that branch RODCs can fail over if a hub
site domain controller fails. In addition, ensure that the bridgehead servers host all the directory
partitions that the branch office domain controllers need to replicate, including Domain Name
System (DNS) partitions and other application directory partitions and the global catalog.
We also recommend that you deploy a hotfix that prevents Windows Server 2003 domain
controllers from performing automatic site coverage for a site that includes an RODC. You must
apply this hotfix to any Windows Server 2003 domain controllers that you plan to continue to use
and that are configured to perform automatic site coverage. For more information about how
Windows Server 2003 domain controllers perform automatic site coverage for a site that has an
RODC, see article 944043 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?

34
LinkId=122974). For more information about other known issues related to RODCs, see Known
Issues for Deploying RODCs (http://go.microsoft.com/fwlink/?LinkId=152838).
The following topics describe hub site deployment issues in more detail:
• Preventing Bridgehead Server Overload During a Transition
• Enabling the Bridge All Site Links Option
• Enabling Client Computers to Locate the Next Closest Domain Controller

Preventing Bridgehead Server Overload

During a Transition
Only read-only domain controllers (RODCs) perform automatic load-balancing across a set of
bridgehead servers. Windows Server 2008 writeable domain controllers perform initial load-
balancing, in a manner similar to Windows Server 2003 domain controllers, but they do not
reassign connections to other bridgehead servers as new bridgehead servers are added. As a
result, you should continue to monitor connection objects for bridgehead servers in hub sites until
you have deployed RODCs to all the branch sites. For more information about automatic load-
balancing for RODCs, see Review Bridgehead Server Load-Balancing Improvements with
Windows Server 2008 RODCs.
If you cannot have all the bridgehead servers in the hub site be writeable Windows Server 2008
domain controllers before you begin to deploy RODCs in the branch offices, you can consider
using these alternatives as a transition until all domain controllers in the environment run
Windows Server 2008:
• Use ADLB from the Windows Server 2003 Branch Office Guide to Rebalance
Connections Between Writeable Domain Controllers in the Hub
• Create a Dedicated RODC Replication Hub

Use ADLB from the Windows Server 2003

Branch Office Guide to Rebalance
Connections Between Writeable Domain
Controllers in the Hub
The Windows Server 2003 Active Directory Branch Office Guide provides guidelines for detecting
and resolving inbound and outbound replication overload conditions on bridgehead servers that
run Windows Server 2003. It also provides guidelines for using the Windows 2000
Active Directory replication compression algorithm on slow wide area network (WAN) links. For
convenience, the guidelines from the Windows Server 2003 Active Directory Branch Office Guide
are reproduced in the following sections. You can follow the same guidelines for preventing

35
bridgehead servers from becoming overloaded while you replace your existing bridgehead
servers that run Windows Server 2003 with bridgehead servers that run Windows Server 2008.
You can use the Active Directory Load Balancing (ADLB) tool (Adlb.exe) from the
Windows Server 2003 Active Directory Branch Office Guide to load-balance connections between
writeable domain controllers, including domain controllers that run Windows Server 2008.
Adlb.exe does not attempt to load-balance connections between read-only domain controllers
(RODCs) and writeable domain controllers. However, because RODCs automatically redistribute
connections among bridgehead servers that run Windows Server 2008, you can focus your
monitoring efforts on the connections between the bridgehead servers and the
Windows Server 2003 domain controllers that remain in the branch offices.
For example, consider a topology in which one hub site has four bridgehead servers that run
Windows Server 2003. The hub site is connected to 100 branch office sites, and each site has a
domain controller that runs Windows Server 2003. After you run Adlb.exe, each bridgehead
server has replication connections to 25 domain controllers, as shown in the following illustration.

Sample topology showing four bridgehead servers connected to 100 branch office domain
controllers

In this situation, if you upgrade any Windows Server 2003 domain controllers, they maintain their
existing connection objects after the upgrade. Upgrade is preferred because if you replace any
Windows Server 2003 domain controllers by demoting them and promoting writeable
Windows Server 2008 domain controllers in their place, you must re-create any manual
connection objects that existed on the original Windows Server 2003 domain controllers.
If you run the ADLB tool, these additional connection objects from RODCs will be ignored and the
bridgehead server will end up with the same load as other bridgehead servers that are generated
from writeable branch domain controllers, in addition to the load that is generated from the
36
RODCs. It will also be a single point of failure even if other Windows Server 2003 domain
controllers are available at the hub. As a consequence, the higher the percentage of
Windows Server 2008 bridgehead servers you have in the hub, the better the load will be
distributed across them.
The following topics explain how you can help prevent hub site domain controllers from becoming
overloaded by replication operations during the transition period in which you still have writeable
domain controllers in branch offices:
• Branch Office-to-Hub Replication Overload (Inbound Overload)
• Hub-to-Branch Office Replication Overload (Outbound Overload)
• Using the Windows 2000 Compression Algorithm on Slow WAN Links

Branch Office-to-Hub Replication Overload

(Inbound Overload)
Inbound overload occurs when a bridgehead server is trying to replicate (pull) changes from more
domain controllers than it can handle. As a bridgehead server attempts replication, the replication
queue begins to grow because the server does not have time or the hardware resources to
service all the requests before a new cycle begins. As this situation progresses, more requests
are added to the queue that are higher priority and they are placed in the queue ahead of the
lower-priority items. An overload condition exists if there are items in the queue that are never
serviced because higher-priority items are always placed in front of them.
If you have read-only domain controllers (RODCs) in branch offices, there will be no inbound
overload on bridgehead servers because there is no replication from RODCs to the hub servers.
For the most part, you have to monitor inbound overload on bridgehead servers only while you
still have writeable domain controllers in the branches.
You can best resolve the problem of inbound overload by replacing the Windows Server 2003
domain controllers in branch offices with Windows Server 2008 RODCs, adding another
bridgehead server in the hub site, or extending the replication schedule.
Two tools that you can use to detect inbound overload are Repadmin and Adlb.exe. You can run
the repadmin command with the /queue option to check the size of the queue. You should run
this command while the replication schedule is closed so that you can check to see if the queue is
empty. If the result never reaches zero, the bridgehead server is overloaded. You can use
Adlb.exe to generate a loading report.
If your environment has not been load-balanced, Adlb.exe might be able to redistribute
connections to reduce the load on some writeable domain controllers. Adlb.exe works only with
writeable domain controllers.
If you use Adlb.exe, be sure to use the version of this tool that is included with the download
package for the Windows Server 2003 Active Directory Branch Office Guide
(http://go.microsoft.com/fwlink/?LinkID=28523).

37
For File Replication Service (FRS) and Distributed File System (DFS) Replication, monitor the
inbound connections. For more information, see Monitoring Your Branch Office Environment.

Hub-to-Branch Office Replication Overload

(Outbound Overload)
Outbound overload occurs when too many branch office domain controllers are attempting to pull
changes from a hub site bridgehead server at the same time. Replication from bridgehead
servers to read-only domain controllers (RODCs) can create an outbound overload condition.
This situation can occur in two ways:
• The connection objects are unbalanced, and too many of them point to a single
bridgehead server. RODCs automatically balance connection objects. However, if you have
writable domain controllers in branch offices in addition to RODCs, connection objects can
become unbalanced.
• The replication schedule is too aggressive so that replication never finishes. This
happens because some high-priority updates always take precedence in the replication
queue and lower-priority updates never replicate.
You can resolve the problem of outbound overload by using the same methods that you use for
inbound overload: extend the availability schedule, add another bridgehead server in the hub site,
or use the Adlb.exe tool to rebalance connections within the site. As an alternative, you can
consider switching to better hardware with multicore processors so that more threads can be run
in parallel.
For File Replication Service (FRS) replication, the outbound connections on the bridgehead
servers must be monitored for increased backlog. For more information, see Monitoring Your
Branch Office Environment.

Using the Windows 2000 Compression

Algorithm on Slow WAN Links
For slow wide area network (WAN) links, we recommend that you use the compression algorithm
that creates .zip files. This algorithm generates more calculation effort on the bridgehead server,
but it lowers the traffic on the network. The compression algorithm is controlled by registry entries
under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, as
shown in the following table.

Registry entry Type Default value Notes

Replication REG_DWORD 3 The default value of 3

compression Recommended value if means that the
algorithm the bandwidth is XPRESS compression

38
 greater than algorithm is used. The
64 Kbps: 3 value 2 switches the
Recommended value if compression algorithm
the bandwidth is less to the .zip file
than 64 Kbps: 2 compression
algorithm, which we
recommend for a
bandwidth that is less
than or equal to
64 Kbps. Note that we
do not recommend
switching to the .zip
file compression
algorithm if a
bridgehead server
runs under heavy load
(CPU usage is greater
than or equal to
80 percent). If you
change the value to 2,
you should monitor
CPU usage on your
bridgehead servers to
determine whether to
revert to the previous
setting or maintain the
change.

Replication REG_DWORD 3 A value of 0 means no

compression level compression. A value
of 9 means the highest
compression.
Increasing the
compression level
increases the load on
the CPU. Therefore,
you should monitor the
CPU load closely in
case you want to
change this value. It is
generally
recommended to keep
the default value of 3.

39
Create a Dedicated RODC Replication Hub
To minimize the impact on your load-balancing and monitoring processes while you roll out read-
only domain controllers (RODCs) in your branch offices, you can create a new dedicated hub site
to be used solely for RODC replication.
Creating a dedicated RODC replication hub should be used only as a temporary measure to
separate the new branch office environment that you plan to deploy from the existing
environment. This solution adds management costs compared to the solution that consists of
upgrading your hub entirely to Windows Server 2008. Therefore, this is usually not the preferred
solution.
If you need to separate the Windows Server 2008 deployment from your existing deployment—for
example, for maintaining compatibility with an existing application or for some other nontechnical
reason—this solution can provide some operational separation. But it should be used temporarily
because it increases the complexity of the environment.
The new dedicated RODC replication hub site will contain only writeable Windows Server 2008
domain controllers. For example, in the following illustration, a new site named RODC Hub is
created specifically to replicate with RODCs that are deployed in branch office sites. The new site
has a site link with the original hub site, named Central Hub, which contains the
Windows Server 2003 domain controllers.
An advantage to creating a dedicated RODC replication hub site is that it helps maintain load-
balancing for existing Windows Server 2003 bridgehead servers in the current hub site. It also
helps improve load-balancing for Windows Server 2008 domain controllers in the new RODC
replication hub site.

To decrease replication latency between the two hub sites, you can enable change notification on
the site link that contains them. With change notification enabled, replication occurs between the
sites after a source domain controller notifies a target domain controller about recent changes
instead of replication occurring during the schedule for the site link. To enable change notification,
complete the following procedure.
Membership in Domain Admins, or equivalent, for the domain that contains the RODCs, is the
minimum required to complete this procedure. Review details about using the appropriate
accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
40
 To enable change notification on a site link
1. Click Start, click Administrative Tools, and then click Active Directory Sites and
Services.
2. In the console tree, double-click Sites, double-click Inter-Site Transports, and then
click IP.
3. In the details pane, right-click the site link that contains the Central Hub site and the
RODC Hub site, and then click Properties.
4. Click Attribute Editor, and then click options. By default, the options attribute has a
value of <not set>.
If the default value appears, click Edit, type 1, and then click OK twice.
If another value appears, add 1 to that existing value. For example, if the current value is
2, change the value to 3.

After you create a dedicated hub site for RODC replication, complete the following steps to
replace a Windows Server 2003 domain controller in a branch office location with an RODC:
1. Create a new site link between the branch office site and the dedicated RODC replication
hub.
2. Complete the steps in Replace a Windows Server 2003 Domain Controller in a Branch
Office with a Windows Server 2008 RODC or Upgrade a Windows Server 2003 Domain
Controller in a Branch Office and Make It an RODC.

Enabling the Bridge All Site Links Option

Site link transitivity is controlled by the Bridge all site links option on the properties pages of
transport folders (such as IP or SMTP) in the Active Directory Sites and Services snap-in. Site link
transitivity is enabled by default.
If you leave the Bridge all site links option enabled, you have to create a site link or add the site
to an existing link only when you add a new site or remove a site so that least-cost replication
paths are created automatically. The Knowledge Consistency Checker (KCC) on a read-only
domain controller (RODC) always creates an inbound replication connection from a writeable
Windows Server 2008 domain controller even if the KCC has to traverse many site links to
establish the required replication path.
In addition, Distributed File System (DFS) can compute the cost matrix for its site-costing
functionality. In other words, if you disable site link bridging and you are using File Replication
Service (FRS) to replicate DFS replicas, which include the SYSVOL share, the DFS site-costing
ability is also disabled.
However, with the Bridge all site links option enabled, domain controllers run the
Intersite Messaging service periodically to build a spanning tree graph with the costs of the
various branches of the topology. If you enable the Bridge all site links option in a large
environment that has approximately 1,000 sites or more, the Intersite Messaging service can

41
cause a spike in CPU use by the Lsass.exe process on domain controllers when the KCC runs.
By default, the KCC runs every 15 minutes.
If you want to leave the Bridge all site links option enabled for applications that can take
advantage of site link bridging, such as DFS, and you want the KCC to ignore the Bridge all site
links setting for performance purposes so that the KCC uses only published site links and
manual site link bridges, run the command repadmin /siteoptions +W2K3_BRIDGES_REQUIRED in the
sites where you are concerned about KCC performance impact. To run the command, you must
know the name of a domain controller in the site.
The command syntax is as follows:
repadmin /siteoptions <domain controller> /site:<site name> +W2K3_BRIDGES_REQUIRED

For example, to run the command on a site named Branch01 that has a domain controller named
DC01, type the following command at an elevated command prompt, and then press ENTER:
repadmin /siteoptions DC01 /site:Branch01 +W2K3_BRIDGES_REQUIRED

Some applications and features that can take advantage of site link bridging include the following:
• DFS
• Microsoft Exchange Server 2007
• The TryNextClosestSite setting for DC Locator
• Automatic site coverage
• Universal and global group membership caching

Enabling Client Computers to Locate the

Next Closest Domain Controller
In a Windows Server 2008 domain, you can make it possible for Windows Vista and
Windows Server 2008 client computers to locate domain controllers more efficiently by enabling
the TryNextClosestSite Group Policy setting. This setting improves the performance of
DC Locator by helping to streamline network traffic. This functionality is available only in
Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.
For branch office environments, you can use this setting to help control how client computers fail
over to another site when the domain controller in their own site is not available. For example,
suppose that you have a branch office deployment with multiple hub sites with writeable domain
controllers and many branch office sites with read-only domain controllers (RODCs). When a
client computer in one of the branch office sites has to fail over to a hub site because the local
RODC is not available, you can use this setting to control which of the hub sites will be used for
failover. Any deployment that has multiple sites with writeable domain controllers can benefit from
using this setting.
By default, the TryNextClosestSite setting is not enabled to maintain the same default behavior
that existing client computers use today. For more information about how this setting works, see

42
Enabling Clients to Locate the Next Closest Domain Controller (http://go.microsoft.com/fwlink/?
LinkId=145407).

Filtering sites with RODCs

By default, DC Locator uses a filter that prevents it from considering any site that contains an
RODC when it determines the next closest site. (The setting is named NextClosestSiteFilter.)
The default behavior is to exclude sites with RODCs because:
• RODCs are typically deployed in branch offices, where you usually do not want client
computers to fail over.
• An RODC might be placed in a physically unsecured site, where it possibly could be
compromised by an attacker. For example, if a member of the Domain Admins group logs on
to a Windows Vista or Windows Server 2008 client computer in the headquarters, DC Locator
should not choose the RODC to process logon scripts and Group Policy on the client
computer for security reasons.
We recommend that you maintain the default setting for the NextClosestSiteFilter. This means
that when DC Locator runs, it will not consider a site that has an RODC to potentially be the next
closest site.
However, in special circumstances in which the RODC is trusted (that is, physically secure) you
might want to include RODCs as valid domain controllers to fall back on. To do this, modify the
registry setting for the NextClosestSiteFilter on Windows Server 2008 domain controllers. (The
setting applies specifically to a domain controller that has the registry setting.) The following table
describes the possible values for the NextClosestSiteFilter (DWORD) registry setting under
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters.

Value Description

0 DC Locator does not apply

NextClosestSiteFilter.

1 DC Locator filters sites that contain only

RODCs. If an RODC is deployed in the same
site as a writeable domain controller,
DC Locator considers it as the possible next
closest site.

2 (default) DC Locator filters sites that contain at least one

RODC. Even if a writeable domain controller is
deployed in the same site as an RODC,
DC Locator does not consider the site as the
possible next closest site.

43
Forcing domain controller rediscovery
In addition to finding a domain controller in the next closest site, a new Group Policy setting in
Windows Server 2008 ensures that a client computer that is running Windows Vista or
Windows Server 2008 finds a new domain controller that might be introduced since the last
domain controller location. On domain controllers that are running Windows Server 2008, the
Force Rediscovery Interval Group Policy setting forces a new domain controller location every
12 hours (43,200 seconds) by default. You can change the time limit for rediscovery by enabling
the setting and specifying a new time in seconds. This makes it possible for client computers to
redistribute their load across available domain controllers every 12 hours by default, while taking
into account weight and priority values that an administrator defines for domain controllers.
By default, client computers cache the last domain controller that was returned by DC Locator. On
client computers that are running Windows XP or Windows Server 2003, even if the domain
controller that was last located is in a distant site, DC Locator continues to return the cached
domain controller on each subsequent request. The cache is updated only if the cached domain
controller is unavailable or the client computer restarts.
For domain client computers that are running Windows XP and Windows Server 2003, a hotfix is
available that makes the registry setting available for this Group Policy setting. For information
about downloading and using this hotfix, see article ID 939252 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=122681).

Methods for applying the TryNextClosestSite setting

To apply the TryNextClosestSite setting, you can create a Group Policy object (GPO) in
Group Policy and link it to the appropriate object for your organization, or you can modify the
Default Domain Policy to have it affect all Windows Vista and Windows Server 2008 client
computers in the domain. You can also apply this setting by modifying the registry, but you can
apply the setting more efficiently by using a GPO.
Membership Enterprise Admins in the forest or Domain Admins in the domain, or equivalent,
is the minimum required to complete this procedure. Review details about using the appropriate
accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.

To enable client computers to locate a domain controller in the next closest site
1. Click Start, click Administrative Tools, and then click Group Policy Management.
2. If the User Account Control dialog box appears, confirm that the action it displays is
what you want, and then click Continue.
3. Double-click Forest:forest_name, double-click Domains, and then double-click
domain_name.
4. Right-click Default Domain Policy, and then click Edit.
5. In Group Policy Management Editor, in the console tree, go to Computer
Configuration/Policies/Administrative Templates/System/Netlogon/DC Locator DNS
Records.
6. In the details pane, double-click Try Next Closest Site, click Enabled, and then click

44
 OK.

As an option, you can create the following registry entry to affect the Domain Locator
(DC Locator) behavior for an individual computer that runs Windows Vista or Windows
Server 2008.

Caution
Incorrectly editing the registry may severely damage your system. Before making
changes to the registry, you should back up any valued data on the computer.
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\Try Next Closest Site
If the registry entry DWORD value is 1, DC Locator will try to find the domain controller in the next
closest site if it cannot find a domain controller in the client computer's site. If the value is 0,
DC Locator will find any domain controller if it cannot find a domain controller in the client
computer's site.

Plan DNS Servers for Branch Office

Environments
This topic describes best practices for installing Domain Name System (DNS) servers to support
Active Directory Domain Services (AD DS) in branch office environments.
As a best practice, use Active Directory–integrated DNS zones, which are hosted in the
application directory partitions named ForestDNSZones and DomainDNSZones. The following
guidelines are based on the assumption that you are following this best practice.
In branch offices that have a read-only domain controller (RODC), install a DNS server on each
RODC so that client computers in the branch office can still perform DNS lookups when the wide
area network (WAN) link to a DNS server in a hub site is not available. The best practice is to
install the DNS server when you install AD DS, using Dcpromo.exe. Otherwise, you must use
Dnscmd.exe to enlist the RODC in the DNS application directory partitions that host
Active Directory–integrated DNS zones. For more information about using Dnscmd.exe, see
Enlist a DNS Server in a DNS Application Directory Partition (http://go.microsoft.com/fwlink/?
LinkId=151963).

Note
You also have to configure the DNS client’s setting for the RODC so that it points to itself
as its preferred DNS server. For more information, see Review the current DNS client
settings.
To facilitate dynamic updates for DNS clients in branch offices that have an RODC, you should
have at least one writeable Windows Server 2008 DNS server that hosts the corresponding DNS
zone for which client computers in the branch office are attempting to make DNS updates. The
writeable Windows Server 2008 DNS server must register name server (NS) resource records for
that zone.

45
By having the writeable Windows Server 2008 DNS server host the corresponding zone, client
computers that are in branch offices that are serviced by RODCs can make dynamic DNS
updates more efficiently. This is because the updates replicate back to the RODCs in their
respective branch offices by means of a replicate-single-object (RSO) operation, rather than
waiting for the next scheduled replication cycle.
For example, suppose that you add a new member server in a branch office, Branch1, which
includes an RODC. The member server hosts an application that you want client computers in
Branch1 to locate by using a DNS query. When the member server attempts to register its host (A
or AAAA) resource records for its IP address to a DNS zone, it performs a dynamic DNS update
on a writeable Windows Server 2008 or Windows Server 2008 R2 DNS server that the RODC
tracks in Branch1. If a writeable Windows Server 2008 DNS server hosts the DNS zone, the
RODC in Branch1 replicates the updated zone information as soon as possible from the writeable
Windows Server 2008 DNS server. Then, client computers in Branch1 can successfully locate the
new member server by querying the RODC in Branch1 for its IP address.
If you do not have a writeable Windows Server 2008 DNS server that hosts the DNS zone, the
update still succeeds but the updated record in the DNS zone will not replicate to the RODC in
Branch1 until the next scheduled replication cycle, which can delay client computers that use the
RODC DNS server for name resolution from locating the new member server.
For more information about how DNS dynamic updates are performed in locations that have an
RODC, see the section “DNS updates for clients that are located in an RODC site” in Appendix A:
Technical Reference Topics (http://go.microsoft.com/fwlink/?LinkID=128273).

Review the current DNS client settings

Review the DNS server and DNS client settings for your existing domain controllers. The
Windows Server 2003 Branch Office Guide recommends that all your domain controllers be DNS
servers. If you have followed those guidelines, the DNS client settings for each domain controller
will be configured so that the domain controller points to itself as the preferred DNS server and
points to another domain controller as the alternate DNS server.
You can also run DNS tests using the Dcdiag.exe tool to ensure that name resolution is working
correctly in your environment before you begin to add Windows Server 2008 domain controllers
to it.
It is a best practice to always to make RODCs DNS servers that host Active Directory–integrated
DNS zones and to configure DNS clients in the site to use the DNS server on the RODC as their
preferred DNS server for DNS queries. RODCs do not register name server (NS) resource
records for the DNS zones that they host.
During installation of AD DS in Windows Server 2008, the Dcpromo tool does not make any
changes to the preferred DNS server setting. However, it adds the IP version 4 (IPv4) loopback
address 127.0.0.1 to the end of the list of alternate DNS servers, and it configures DNS
forwarders to help resolve DNS names that are not included in the DNS zone that the domain
controller hosts. If IP version 6 (IPv6) is enabled, Dcpromo adds the IPv6 loopback address ::1 to
the list of Alternate DNS servers and the IPv6 addresses appear before IPv4 addresses in the list.

46
After each RODC installation in a branch office, change the IP address of the Preferred DNS
server on each RODC (if this is not already done by means of a Group Policy setting) so that the
RODC points to itself as the Preferred DNS server instead of the Alternate DNS server.
Windows Server 2008 includes a Group Policy setting that provides improvements in the
DC Locator process. The improvements can help client computers that run Windows Vista or
Windows Server 2008 locate domain controllers more efficiently on a network than was possible
in previous versions of Windows Server. For a procedure that explains the steps to set this Group
Policy setting, see Enable Clients to Locate a Domain Controller in the Next Closest Site
(http://go.microsoft.com/fwlink/?LinkID=147362).

Plan Global Catalog Servers

Read-only domain controllers (RODCs) do not introduce any significant new considerations for
determining whether to make a branch domain controller a global catalog server. Global catalog
placement generally requires planning unless you have a single-domain forest. In a single-
domain forest, you can configure all domain controllers as global catalog servers without causing
any additional replication or an increase in disk size or CPU usage.
However, only domain controllers that are designated as global catalog servers can respond to
global catalog queries on the global catalog Lightweight Directory Access Protocol (LDAP)
port 3268. Designating all domain controllers as global catalog servers eliminates server or
network capacity planning concerns about which domain controllers can respond to global
catalog queries by applications or other domain controllers.
In a multiple-domain forest, deciding whether a domain controller should be a global catalog
server takes extra planning. As a general rule, it is best to make branch-office domain controllers
(including branch-office RODCs) be global catalog servers so that authentication—and, generally,
any global catalog query—can be performed by using just the RODC. This comes, however, at
the price of replicating the partial attribute set for objects from every domain in the forest to the
branch office, which may be expensive in terms of network and disk usage if some domains have
large amounts of users, computers, or groups with a high rate of updates.
If you determine that you cannot make the branch-office domain controller a global catalog
server, you should enable universal group caching in that site. With universal group membership
enabled, a domain controller must connect to a global catalog server across a wide area network
(WAN) link only for initial logons in the site. Thereafter, universal group membership can be
checked from a local cache.
For more information about planning for Global Catalogs, see Planning Global Catalog Server
Placement (http://go.microsoft.com/fwlink/?LinkID=142505).
If you are running Microsoft Exchange Server, locate your Exchange servers in hub sites and
data centers with writeable domain controllers. Exchange Server does not use RODCs. This
means that if an RODC and a computer running Exchange Server are running in the same site,
the computer running Exchange Server disregards the RODC and attempts to contact a writeable
domain controller.

47
Enabling universal group membership caching
For locations that have the following characteristics, you can deploy domain controllers running
Windows Server 2008 and enable universal group membership caching:
• Locations that cannot replicate the global catalog, for example, as a result of limited
bandwidth
• Locations that include less than 100 users
• Locations that do not include a large number of roaming users or applications that require
a global catalog server

Ensure that the global catalog servers are not more than one replication hop from the domain
controller that is in a site for which universal group membership caching is enabled so that
universal group information in the cache can be refreshed.

Note
If you are deploying an RODC in a site, universal group membership caching is not
enabled by default. Either add the global catalog server option to the RODC or enable
universal group membership caching for that site.
For best results, add the global catalog server option to the RODC because the cache lifetimes
and refresh logic for universal group membership caching are not integrated with RODC
credential caches, which can lead to some unexpected results. For example, suppose that the
password changes for an account whose password is allowed to be cached on the RODC. The
password is nulled out when it replicates in to the RODC. (That is, the link between the password
attribute value and its memory address is removed; the password itself is unchanged and
remains stored in memory.) The user logs on, and the password cache on the RODC is refreshed
with the new password. However, the group membership cache for the same account is not
refreshed at the same time.
Adding the global catalog partitions to what the RODC replicates from the hub increases the
amount of information that has to be replicated over the wide area network (WAN). This requires
more bandwidth for replication than universal group membership caching does. But unless
bandwidth is restricted, adding the global catalog to the RODC provides a better overall
experience for users in the branch office beyond logging on. This is because a global catalog
provides all objects from the forest, which in turn can enable wider application compatibility in
situations in which WAN availability to another global catalog server does not exist.

Deploying RODCs in Branch Offices

The following topics include the steps for deploying read-only domain controllers (RODCs) in
branch offices:
Step 1: Take an Inventory of Branch Office Resources
Step 2: Verify That Prerequisites for RODC Deployment Are Complete

48
Step 3: Decide How to Define the Password Replication Policy
Step 4: Customize the RODC Filtered Attribute Set
Step 5: Determine Your Strategy for Deploying RODCs to Branch Offices
Step 6: Complete Additional Steps for Configuring an RODC
Step 7: Raise the Domain and Forest Functional Levels to Windows Server 2008

Step 1: Take an Inventory of Branch Office

Resources
Before you begin a deployment of read-only domain controllers (RODCs) in branch office
locations, take an inventory of the following types of branch office resources.

Applications
Take an inventory of the directory-integrated applications that you run in branch offices. Test the
applications in a lab environment to make sure that they work as expected with RODCs before
you replace or deploy new domain controllers in branch offices. Most applications should work
well with a read-only copy of the directory data. For more information about testing applications,
see the Read-Only Domain Controllers Application Compatibility Guide
(http://go.microsoft.com/fwlink/?LinkID=117785).

Operating systems
The client computers that you plan to run in branch offices with RODCs must run one of the
following operating systems:
• Windows 2000 Professional
• Windows XP Professional
• Windows Vista Business, Windows Vista Enterprise, and Windows Vista Ultimate
• Windows 7 Professional, Windows 7 Enterprise, and Windows® 7 Ultimate
• Windows 2000 Server
• Windows Server 2003
• Windows Server 2008
All 32-bit and 64-bit editions of these operating systems work with RODCs.
Check the list of known issues for client computers that interact with RODCs to determine
whether you should apply the hotfix to make an RODC work for the scenario that you plan for it.
For example, if you have Windows XP Professional clients or Windows Server 2003 clients, apply
the hotfix to make those clients synchronize time with an RODC. Most of the known issues have
a potential workaround that you can use if you cannot apply the hotfix. For more information, see
Known Issues for Deploying RODCs (http://go.microsoft.com/fwlink/?LinkId=152838).

49
Users and computers
If you know the names of the users and computers (including all servers and workstations) in
each branch office, create a list or a security group that includes those security principals for each
branch. You can use this list or security group later in the deployment process to define the
Password Replication Policy (PRP) for each RODC. For more information, see Step 3: Decide
How to Define the Password Replication Policy.

Step 2: Verify That Prerequisites for RODC

Deployment Are Complete
Before you can add a read-only domain controller (RODC) to any domain in the forest, the
following prerequisites must be complete:
• The forest functional level must be Windows Server 2003, Windows Server 2008, or
Windows Server 2008 R2.
• You must run the adprep /rodcprep command, and the changes must replicate
throughout the forest. For more information about running adprep /rodcprep, see Running
Adprep.exe (http://go.microsoft.com/fwlink/?LinkId=142597).

Important
When you run adprep /rodcprep, if you receive an error message that indicates that
the command could not contact a replica for the partition
DC=DomainDNSZones,DC=<domain> or for the partition
DC=ForestDNSZones,DC=<domain>, see article 949257 in the Microsoft Knowledge
base (http://go.microsoft.com/fwlink/?LinkID=114419). For more information about
this error message, see Known Issues for Deploying RODCs
(http://go.microsoft.com/fwlink/?LinkId=152838).
• At least one writable domain controller running Windows Server 2008 must be running in
the same domain where you plan to install an RODC.
For more information, see Prerequisites for Deploying an RODC (http://go.microsoft.com/fwlink/?
LinkId=153461).

Step 3: Decide How to Define the Password

Replication Policy
Define a Password Replication Policy (PRP) for each read-only domain controller (RODC) that
you deploy. The PRP determines which account passwords are allowed to be cached on an
RODC and which account passwords are explicitly denied from being cached on an RODC. An
account password cannot be cached on an RODC unless you add the account to the Allowed list
for that RODC directly or the account is member of a group that is in the Allowed list. In addition,

50
the account cannot be in the Deny list or a member of a group that is in the Deny list. You can
specify the PRP during an RODC installation, and you can modify it as needed after the RODC is
installed. You can define the PRP in any number of different ways, as in the following examples:
• You can allow no account passwords from the domain to be cached. This is the default
option and the most secure option.
• You can allow all account passwords from the domain to be cached.
• You can allow only account passwords from the branch office to be cached.
In most cases, the recommended way to specify the PRP is to include the users and computers
that reside in a branch office in the Allowed RODC Password Replication Group for that RODC.
However, each of these examples has advantages and disadvantages. For more information
about the PRP, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkID=133488).
There are multiple ways to determine which users should be added to the Allowed list of a
particular RODC:
• Use office location data from your Human Resources (HR) systems to figure out which
users are in which location. After you have that data, you can study how locations are
covered by RODCs and whether users should have their accounts cached on it or not.
• As an alternative, your organization may already have groups in place that map to each
of your offices and contain users from these offices. You can use these groups to define your
PRP. However, you have to ensure that resources from each branch office, including the
computers for the users, are also cached on the RODC for that branch. You can maintain the
group memberships by using applications such as Microsoft Identity Lifecycle Manager (ILM).
• If you do not have an easy way to define what accounts should be cached on any given
RODC that you deploy in a branch office, start with the default PRP and monitor the msDS-
AuthenticatedToAccountList attribute to determine which users and computers have used
a writeable Windows Server 2008 domain controller to access an RODC as a resource.
Continue to monitor this attribute until you think that the Allowed list contains all or most users
and computers that will frequently use the RODC to authenticate but the list does not contain
many accounts that will use the RODC infrequently. For more information about the msDS-
AuthenticatedToAccountList attribute, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkID=133488).

Step 4: Customize the RODC Filtered

Attribute Set
The read-only domain controller (RODC) filtered attribute set (FAS) is a set of attributes of the
Active Directory schema that is not replicated to an RODC. If you have data that you do not want
to be replicated to an RODC in case it is stolen, you can add these attributes to the RODC FAS. If
you add the attributes to the RODC FAS before you deploy the first RODC, the attributes are
never replicated to any RODC.

51
As an alternative, you can add attributes to the RODC FAS after you deploy RODCs, but attribute
values that have already replicated to an RODC may not be physically removed from the
database or could still be present in an old local backup copy of the server. Therefore, if you want
complete assurance that the attribute values do not appear on an RODC, add attributes to the
FAS before you assign any values to them.
In addition, if you plan to add attributes to the RODC FAS, as a best practice, ensure that the
forest functional level is Windows Server 2008. Until the forest functional level is
Windows Server 2008, an RODC can replicate data of the RODC FAS from a global catalog
server that is running Windows Server 2003.

Note
Only a compromised RODC (for example, an RODC that is being used for malicious
purposes) would attempt to replicate data from a global catalog server that is running
Windows Server 2003.
To decide which attributes to add to the RODC FAS, review any schema extensions that have
been performed in your environment and determine whether they contain credential-like data or
not. In other words, you can exclude from consideration any attributes that are part of the base
schema, and review all other attributes. Base schema attributes have the systemFlags attribute
value 16 (0x10) set.
If this complete set of attributes is too large, you can also look at which attributes in your
environment have the Confidential bit (0x80, or 128 in decimal format) for the searchFlags
attribute set. These attributes are more likely to contain credential-like data that should not
replicate to RODCs.
For example, you can use the Ldifde.exe tool to search the schema for attributes that are not part
of the base schema and that have the confidential bit set by using the following Lightweight
Directory Access Protocol (LDAP) search filter:
Ldifde –d “cn=schema,cn=configuration,dc=contoso,dc=com” –f output.ldf –p subtree –r
“(&(objectClass = attributeSchema)(!(systemFlags:1.2.840.113556.1.4.803:=16))
(searchFlags:1.2.840.113556.1.4.803:=128))”

You cannot add system-critical attributes to the RODC FAS. An attribute is system critical if it is
required for Active Directory Domain Services (AD DS); Local Security Authority (LSA); Security
Accounts Manager (SAM); or any of Microsoft-specific Security Service Providers, such as the
Kerberos authentication protocol, to function properly. A system-critical attribute has a
schemaFlagsEx attribute value of (schemaFlagsEx attribute value & 0x1 = TRUE).
For more information about the RODC FAS, see Adding Attributes to the RODC Filtered Attribute
Set (http://go.microsoft.com/fwlink/?LinkId=153620).

52
Step 5: Determine Your Strategy for
Deploying RODCs to Branch Offices
There are a few different ways in which you can deploy read-only domain controllers (RODCs) to
branch offices. The following topics describe some common scenarios for deploying RODCs and
the steps that you perform to complete an RODC deployment:
• Deploy an RODC to a Branch Office That Currently Has No Domain Controller
• Replace a Windows Server 2003 Domain Controller in a Branch Office with a Windows
Server 2008 RODC
• Upgrade a Windows Server 2003 Domain Controller in a Branch Office and Make It an
RODC

Deploy an RODC to a Branch Office That

Currently Has No Domain Controller
In this scenario, the branch office does not have any domain controllers, either because it is a
new location, it does not have the physical security to host a domain controller, or it does not
have the administrative expertise to manage a domain controller. In this scenario, you can
perform a staged installation in which a read-only domain controller (RODC) is promoted onsite in
the branch office. The benefit to using a staged installation is that you can delegate RODC
promotion to any domain user, which means that a Domain Admin does not have to log on in the
branch office to complete the RODC installation. Also, if you usually use an answer file to install
Active Directory Domain Services (AD DS), you do not have to include the password of a Domain
Admin account in the answer file, which reduces the risk if someone intercepts the answer file.
Complete the following steps to deploy an RODC to a branch office that currently has no domain
controller:
1. Using the Active Directory Sites and Services snap-in, create a site object for the branch
office and a site link object that makes it possible for that branch office location to replicate
with a hub site or data center.
2. Using the Active Directory Users and Computers snap-in, right-click the Domain
Controllers organizational unit (OU), and then select the option to create an account for the
RODC. This step must be completed by a member of the Domain Admins group, or you must
be delegated the appropriate permissions. When you create the account, specify the
following options in particular:
• Enter the name of the RODC.
• Select the new site that you just created as the site for the RODC.
• Select the DNS server and Global catalog options. If you do not install these
options when you create the RODC account, you must take additional steps to install
them later, including steps to enlist the RODC in the DNS application directory partitions.

53
 • Delegate an administrator for the RODC. As a best practice, use a security group as
the delegated RODC administrator account. If a delegated RODC administrator is not
selected when the RODC account is created, you can select one after the account is
created. For more information, see RODC Administration (http://go.microsoft.com/fwlink/?
LinkID=133521).
• Configure the Password Replication Policy (PRP) for the RODC. The PRP specifies
which account passwords are allowed to be cached or denied from being cached by the
RODC. For more information, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkID=133488).

Note
If you are using the Active Directory Domain Services Installation Wizard to
create the RODC account, select the Use advanced mode installation check
box on the Welcome page of the wizard to configure the PRP when you create
the RODC account.
For more information, see Performing a Staged RODC Installation
(http://go.microsoft.com/fwlink/?LinkID=129193).
3. If you plan to install the RODC from media, run the ntdsutil ifm command on a
Windows Server 2008 domain controller to create secret-less installation media (that is,
media in which passwords and other attributes that are included in the RODC FAS have been
removed) for the RODC installation, and then send the media to the branch office where the
installation will occur. By using the Install from Media (IFM) option, you can reduce the
amount of data that must replicate to the RODC during the installation process. For more
information about creating secret-less media for an RODC installation, see Installing
Active Directory Domain Services from Media (http://go.microsoft.com/fwlink/?
LinkID=120013).
4. Deploy a Windows Server 2008 server in the branch office. You can, for example, have a
server with Windows Server 2008 preinstalled sent directly to the branch office. We
recommend that you use the Server Core installation option of Windows Server 2008 for an
RODC. However, there are some other server roles that you might want to run on the RODC
that cannot run on a Server Core installation. For more information about what server roles
can run on a Server Core installation, see the section “Choosing whether to install the Server
Core or the Full installation option” in RODC installation (http://go.microsoft.com/fwlink/?
LinkId=153622).
One alternative is to deploy the RODC as a virtual machine (VM) by using a virtualization
technology, such as Windows Server 2008 Hyper-V™. You can install an RODC on a Server
Core installation on a VM and run other roles such as File and Print server on other VMs. For
more information, see Running Domain Controllers in Hyper-V
(http://go.microsoft.com/fwlink/?LinkID=139651).

Note
The server must be in a workgroup, and it should have the same name as the
account that is specified in step 2.

54
 Have a delegated RODC administrator complete the second stage of the AD DS installation.
For more information, see Performing a Staged RODC Installation
(http://go.microsoft.com/fwlink/?LinkID=129193).
5. Verify that the RODC installation is working correctly. If you did not install the DNS server
role or the global catalog during the AD DS installation, you should complete those steps
now.
For more information about completing those steps and the specific tests that you can run to
verify the RODC installation, see RODC Post-Installation Configuration
(http://go.microsoft.com/fwlink/?LinkId=152749).

Replace a Windows Server 2003 Domain

Controller in a Branch Office with a
Windows Server 2008 RODC
In this scenario, you replace a Windows Server 2003 domain controller that is currently deployed
in a branch office with a new server that will be a read-only domain controller (RODC). During the
RODC installation, the existing Windows Server 2003 domain controller continues to authenticate
the branch office users and computers. After the RODC is installed, you can remove
Active Directory from the Windows Server 2003 domain controller and retain the domain
controller as a member server.

Security Note
For security reasons, you should make sure that the Windows Server 2003 domain
controller and the RODC are running in the same site for only a short time.
The steps to complete this scenario are similar to the steps for adding an RODC to a new site
that does not have a domain controller. You create the RODC account and select a delegated
RODC administrator to complete the installation of the RODC in the branch office. But you can
only use a Windows Server 2008 domain controller as a source to create secret-less media (that
is, media in which passwords and other secret-like data has been removed) for an Install from
Media (IFM) installation of the RODC. Therefore, if possible, consider upgrading the
Windows Server 2003 domain controller to Windows Server 2008 so that you can use it as a
source to create secret-less media for the RODC installation. This makes it possible for all the
RODC installation procedures to be completed in the branch office location.
As an alternative, you can use a Windows Server 2008 domain controller in a hub site to create
the secret-less media and then ship the media to the branch office for the RODC installation. In
either case, the RODC must use a Windows Server 2008 domain controller as a replication
source during the installation of Active Directory Domain Services (AD DS).
For these reasons, you should perform an IFM installation to reduce replication over the wide
area network (WAN) link during the RODC installation. On the other hand, if the WAN link can
sustain the replication traffic, you can choose to have all Active Directory data replicated during
the installation.

55
Complete the following steps to replace a Windows Server 2003 domain controller in a branch
office with a Windows Server 2008 RODC:
1. Using the Active Directory Users and Computers snap-in, right-click the Domain
Controllers OU, and then select the option to create an account for the RODC. This step must
be completed by a member of the Domain Admins, or you must be delegated the appropriate
permissions. When you create the account, specify the following options in particular:
• Enter the name of the RODC.
• Select the site that has the Windows Server 2003 domain controller that you want to
replace as the site for the RODC.
• Select the DNS server and Global catalog options. If you do not install these
options when you create the RODC account, you must take additional steps to install
them later, including steps to enlist the RODC in the DNS application directory partitions.
• Delegate an administrator for the RODC. As a best practice, use a security group as
the delegated RODC administrator account. If a delegated RODC administrator is not
selected when the RODC account is created, you can select one after the account is
created. For more information, see RODC Administration (http://go.microsoft.com/fwlink/?
LinkID=133521).
• Configure the Password Replication Policy (PRP) for the RODC. The PRP specifies
which account passwords are allowed to be cached or are denied from being cached by
the RODC. For more information, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkID=133488).

Note
If you are using the Active Directory Domain Services Installation Wizard to
create the RODC account, select the Use advanced mode installation check
box on the Welcome page of the wizard to configure the PRP when you create
the RODC account.
For more information, see Performing a Staged RODC Installation
(http://go.microsoft.com/fwlink/?LinkID=129193).
2. If you plan to install the RODC from media, run the ntdsutil ifm command on a
Windows Server 2008 domain controller to create secret-less installation media for the RODC
installation, and then send the media to the branch office where the installation will occur. By
using the IFM option, you can reduce the amount of data that has to replicate to the RODC
during the installation process. For more information about creating secret-less media for an
RODC installation, see Installing AD DS from Media (http://go.microsoft.com/fwlink/?
LinkID=120013).
3. Deploy a Windows Server 2008 server in the branch office. You can, for example, have a
server with Windows Server 2008 preinstalled sent directly to the branch office. We
recommend that you choose the Server Core installation option of Windows Server 2008 for
an RODC. However, there are some other server roles that you might want to also run on the
RODC that cannot run on a Server Core installation. For more information about which server
roles can run on a Server Core installation, see the section “Choosing whether to install the

56
 Server Core or the Full installation option” in RODC installation
(http://go.microsoft.com/fwlink/?LinkId=153622).
One alternative is to deploy the RODC as a virtual machine (VM) by using a virtualization
technology such as Hyper-V. You can install an RODC on a Server Core installation in a VM
and run other roles such as File and Print server on other VMs. For more information, see
Running Domain Controllers in Hyper-V (http://go.microsoft.com/fwlink/?LinkID=139651).

Note
The server must be in a workgroup, and it should have the same name as the
account that is specified in step 2.
The delegated RODC administrator runs dcpromo at the command line. For more
information about running dcpromo, see Performing a Staged RODC Installation
(http://go.microsoft.com/fwlink/?LinkID=129193).
4. Verify that the RODC installation is working correctly. For more information about specific
tests that you can run to verify the installation, see RODC Post-Installation Configuration
(http://go.microsoft.com/fwlink/?LinkId=152749).
5. Remove Active Directory from the Windows Server 2003 domain controller.
6. As a security best practice, delete all system state backups or snapshots from the original
domain controller after you remove Active Directory from it. The backups and snapshots
contain secrets. Because most organizations deploy an RODC to eliminate exposure of those
secrets, it is a good security practice to delete them. You will never need them because they
can no longer be used to restore the original domain controller.

Upgrade a Windows Server 2003 Domain

Controller in a Branch Office and Make It
an RODC
In this scenario, you have an existing Windows Server 2003 domain controller in the branch
office. You want to upgrade the operating system and then run a Windows Server 2008 read-only
domain controller (RODC) on the same hardware. You cannot upgrade a Windows Server 2003
domain controller and make it a Windows Server 2008 RODC as part of the process of upgrading
the operating system. To make any writable domain controller an RODC, you have to remove and
then reinstall Windows Server 2008 Active Directory Domain Services (AD DS).
In this scenario, a Domain Admin will be required to log on in the branch office to remove AD DS
from the domain controller after it is upgraded. Because the Domain Admin will be required to log
on in the branch office, the staged installation process does not provide any administrative
benefit.
The branch office users and computers will have to authenticate over the wide area network
(WAN) link while AD DS is removed from the existing domain controller and then reinstalled.

57
Complete the following steps to upgrade a Windows Server 2003 domain controller and then
make it a Windows Server 2008 RODC:
1. Upgrade the operating system of the Windows Server 2003 domain controller to
Windows Server 2008.

Note
If you upgrade the operating system of the domain controller before you remove
AD DS from it, you can run the ntdsutil ifm command to create secret-less media on
the upgraded domain controller. Then, you can use the resulting secret-less
installation media to complete subsequent RODC installations. This reduces
downtime within the branch office and minimizes WAN link utilization during the
RODC installation. For more information about creating secret-less media for an
RODC installation, see Installing AD DS from Media (http://go.microsoft.com/fwlink/?
LinkID=120013).
2. Run the Dcpromo.exe tool to remove AD DS. You must be a member of the Domain
Admins group to complete this operation.
3. Run Dcpromo.exe again to install AD DS on the server. When you run Dcpromo.exe,
select the option to install an RODC and specify the folder where you installed the IFM media
for the RODC installation. You must be a member of the Domain Admins group to complete
the RODC installation or you must be delegated the appropriate permissions. In this case, the
risk that is associated with using privileged credentials during the installation is not as
significant because the privileged credentials were already used in the step when AD DS was
removed.
4. Verify that the RODC installation is working correctly. If you did not install the DNS server
role or the global catalog during the AD DS installation, you should complete those steps
now.
For more information about completing those steps and specific tests that you can run to
verify the RODC installation, see RODC Post-Installation Configuration
(http://go.microsoft.com/fwlink/?LinkId=152749).
5. As a security best practice, delete all system state backups or snapshots from the original
domain controller after you remove Active Directory from it. You can retain the secret-less
installation media for additional RODC installations.

Step 6: Complete Additional Steps for

Configuring an RODC
After you install Active Directory Domain Services (AD DS), complete the following configuration
tasks. For additional configuration tasks that you might have to complete after you install a read-
only domain controller (RODC), see RODC Post-Installation Configuration
(http://go.microsoft.com/fwlink/?LinkId=152749).

58
• Verify that the NETLOGON and SYSVOL shared folders are present on the domain
controller.
At an elevated command prompt, type net share, and then press ENTER. If the NETLOGON
shared folder is not listed, complete the steps in article 947022 in the Microsoft Knowledge
Base (http://go.microsoft.com/fwlink/?LinkId=123014).
• Reconfigure the Domain Name System (DNS) client settings of RODCs in branch
offices if a Group Policy setting is not already applied to do this.
By default, an RODC is not configured to point to itself as its preferred DNS server. Change
the default settings so that the RODC points to itself as the preferred DNS server and DNS
lookups can be resolved locally in the branch office. Set the alternate DNS server to be a
DNS server in a hub site.
• If applicable, specify a user—or, preferably, a group—as the delegated RODC
administrator account, and add the user or group to the Allowed list for the Password
Replication Policy (PRP) of the RODC.
You may have completed this step during RODC installation. After you specify the account
and add it to the Allowed list, replicate the passwords for accounts in the Allowed list to the
RODC by having the accounts log on to a workstation in the site with the RODC or by
prepopulating the passwords by using the Active Directory Users and Computers snap-in or
Repadmin.exe. This ensures that accounts in the Allowed list, including the delegated RODC
administrator, can log on to the RODC even if the network is not available. For more
information, see Administering the Password Replication Policy
(http://go.microsoft.com/fwlink/?LinkID=133488).
• If necessary, change the DsrmAdminLogonBehavior registry entry value.
The DsrmAdminLogonBehavior registry entry controls whether you can use the Directory
Services Restore Mode (DSRM) Administrator account to log on to a domain controller if the
domain controller was started normally but the AD DS service is stopped for some reason
and no other domain controller can be contacted to service the logon request. This situation
can arise in a branch office that has an RODC when the wide area network (WAN) link
between the branch office and a hub site is unavailable. By default, the DSRM Administrator
account cannot be used to log on to a domain controller that has the AD DS service stopped.
For more information about the DsrmAdminLogonBehavior registry entry, see the
Restartable AD DS Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=88649).
• Follow best practices for running antivirus software on a domain controller.
For more information, see "Running Virus Scans on Domain Controllers" in Establishing
Secure Domain Controller Build Practices (http://go.microsoft.com/fwlink/?LinkId=123016).
• Configure port requirements for Windows Server 2008 and RODCs.
AD DS has port requirements for replication and other operations. There are also port
requirements for services that AD DS depends on. Furthermore, your deployment might have
other applications and services that depend on AD DS, and they can have their own set of
port requirements. For more information about configuring ports for an RODC, see
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
(http://go.microsoft.com/fwlink/?LinkId=150053).

59
 On domain controllers that run Windows Server 2003 with Service Pack 1 (SP1) or Service
Pack 2 (SP2) or Windows Server 2008, Windows Firewall is enabled by default. You might
have to configure the firewall settings on these domain controllers to allow Active Directory
operations. For more information, see article 224196 in the Microsoft Knowledge Base
(http://go.microsoft.com/fwlink/?LinkId=123020).

Note
The dynamic client port range for outgoing connections in Windows Vista and in
Windows Server 2008 is increased from earlier versions of Windows. The new
default start port is 49152, and the default end port is 65535. Earlier versions of
Windows used a default port range of 1025 through 5000.
Before you deploy Windows Server 2008 domain controllers, test for connectivity over the
new port range. AD DS requires TCP/IP availability. For more information, see article 929851
in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=123021).

Step 7: Raise the Domain and Forest

Functional Levels to Windows Server 2008
When you deploy a read-only domain controller (RODC) in a branch office, you should raise the
domain and forest functional levels of your environment to Windows Server 2008 as soon as
possible. The Windows Server 2008 functional levels are required so that you can migrate from
File Replication Service (FRS) replication to Distributed File System (DFS) Replication of
SYSVOL. For more information about DFS Replication of SYSVOL, see Plan for DFS Replication
for SYSVOL.
For more information about other features that are available at the Windows Server 2008 domain
and forest functional levels, see Understanding AD DS Functional Levels
(http://go.microsoft.com/fwlink/?LinkID=139786).

Administering RODCs in Branch Offices

This topic provides guidelines for common administrative tasks for read-only domain controllers
(RODCs) in branch offices:
• Using Remote Desktop to administer RODCs in branch offices
• Reestablishing replication for an RODC
• Checking the lastLogonTimeStamp attribute on an RODC to discover stale accounts in a
branch office
• Resolving an account lockout problem in a branch office with an RODC
• Performing backups of an RODC

60
Using Remote Desktop to administer RODCs in
branch offices
You have to enable Remote Desktop on an RODC to be able to log on to the RODC remotely. By
default, Remote Desktop is disabled on servers that run Windows Server 2008.

Security Note
If you log on by using Remote Desktop to any computer that you do not trust, make sure
that you do not log on as a Domain Admin or use other privileged credentials. As a best
practice, you should never expose Domain Admin credentials to a computer that is not
fully trusted.
If possible, enable Remote Desktop for an RODC as part of any automated
Windows Server 2008 operating system installation. For example, if you use Sysprep.exe to
install servers, update the Sysprep answer file to enable Remote Desktop.
If you do not enable Remote Desktop as part of the operating system installation and you
administer only a few RODCs, you can enable it by using the graphical user interface (GUI) or by
using Registry Editor.

To enable Remote Desktop by using the GUI

1. Click Start, right-click Computer, and then click Properties.
2. Click Remote settings.
3. Click the Remote tab.
4. If you will administer the RODC from a computer that runs Windows Vista or
Windows 7, click Allow connections only from computers running Remote Desktop
with Network Level Authentication (more secure).
If you will administer the RODC from a computer that runs an earlier version of Windows,
click Allow connections only from computers running any version of Remote
Desktop (less secure).

To open a firewall to enable Remote Desktop by using the command line, run the following netsh
commands:
• To open the firewall to allow access to an RODC by using Remote Desktop, at an
elevated command prompt, type the following command, and then press ENTER:
netsh advfirewall set publicprofile settings remotemanagement enable

• To open the firewall to allow use of Microsoft Management Console (MMC) snap-ins,
such as Event Viewer, remotely, at a command prompt, type the following command, and
then press ENTER:
netsh firewall set service remoteadmin enable

To enable Remote Desktop by using Registry Editor

1. Click Start, click Run, type regedit and then click OK.
2. Navigate to the following key

61
 HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal Server
3. In the details pane, double-click fDenyTSConnections, and change the DWORD
value to 0.
4. If you will manage the RODC from a workstation that Windows Vista or Windows 7,
navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Terminal
Server\WinStations\RDP-Tcp
5. In the details pane, double-click UserAuthentication, and change the DWORD value
to 1.
6. Close Registry Editor and restart the RODC to make the changes effective.

If you do not enable Remote Desktop as part of the operating system installation and you need to
administer many RODCs, you can enable Remote Desktop by editing the Default Domain
Controllers Policy. However, using this Group Policy object (GPO) enables Remote Desktop for
all domain controllers in the domain.

To create a GPO that allows the use of Remote Desktop to administer RODCs in branch
offices
1. Click Start, click Administrative Tools, and then click Group Policy Management.
2. In the console tree, right-click Default Domain Controllers Policy and click Edit.
Where?
Forest:
Forest name\Domains\Domain name\Domain Controllers\Default Domain Controllers Poli
cy
3. Navigate to the following folder:
Computer Configuration\Policies\Administrative Templates\Windows Components\Termin
al Services\Terminal Server\Connections
4. Double-click Allow users to connect remotely using Remote Desktop Services.
5. Click Enabled, and then click OK.

Reestablishing replication for an RODC

If the site where you add an RODC is not included in a site link or if the site link is accidentally
deleted, complete the following steps to get the RODC replicating again.

Note
There is no specific event that is logged to indicate that a site that has an RODC is not
included in a site link. However, event ID 1311 is logged on the RODC indicating that the
Knowledge Consistency Checker (KCC) cannot build a complete spanning tree for
replication.
1. On a writable domain controller, place the site with the RODC in a site link. Make sure
that the site link contains a site with a writable domain controller.
62
 2. Force replication of the configuration partition to the RODC by using either the
Active Directory Sites and Services snap-in or Repadmin.exe, as described in the following
procedures.
3. Run the repadmin /kcc command on the RODC to trigger the KCC. The KCC will then
maintain replication to the RODC.

To use Active Directory Sites and Services to force replication of the configuration
partition to an RODC
1. Open the Active Directory Sites and Services snap-in (Dssite.msc). To open
Active Directory Sites and Services, click Start, click Administrative Tools, and then
click Active Directory Sites and Services. If the User Account Control dialog box
appears, enter the appropriate credentials (if requested), confirm that the action it
displays is what you want, and then click Continue.
2. Double-click Sites, double-click the name of the site that has the RODC, double-click
Servers, double-click the name of the RODC, right-click NTDS Settings, and then click
Replicate configuration to the selected DC.
3. Click OK to close the message indicating that AD DS has replicated the connections.

To use Repadmin.exe to force replication of the configuration partition to an RODC

1. To create a replication link manually on an RODC from the command line, open an
elevated command prompt, and then run the following commands:
repadmin /add <configuration partition> <name of the RODC> <FQDN of the source
domain controller> /readonly /selsecrets

repadmin /replicate <RODC> <FQDN of the source domain controller> <configuration

partition>

Where:
<configuration partition> is the distinguished name of the configuration partition. For
example, cn=configuration,DC=contoso,DC=com.
<name of the RODC> is the single-label computer name of the RODC.
<FQDN of source domain controller> is the fully qualified domain name (FQDN) of the
domain controller that the RODC will replicate from, for example,
<GUID>._mscdcs.<domain>.

Note
You can perform these same steps for a site that has a writable domain controller. If you
use the repadmin /add command to replicate the configuration partition to a writable
domain controller, you do not have to use the /readonly or /selsecrets parameters.

63
Checking the lastLogonTimeStamp attribute on an
RODC to discover stale accounts in a branch
office
Some organizations periodically check the lastLogonTimeStamp attribute of user and computer
accounts to help discover accounts that have been inactive. The lastLogonTimeStamp attribute
indicates the time that a user last logged on to the domain. This attribute is replicated to all
domain controllers. Therefore, you can easily query accounts that are not being used. For more
information about creating a script to retrieve lastLogonTimeStamp, see the Script Center
(http://go.microsoft.com/fwlink/?LinkID=47965).
The domain functional level must be at least Windows Server 2003 before you can check
lastLogonTimeStamp.
All domain controllers use the same algorithm to determine whether lastLogonTimeStamp for an
account must be updated. However, because updates are not replicated from an RODC, any
updates that an RODC makes to lastLogonTimeStamp are handled slightly differently than they
are for a writable domain controller.
If an account has its credentials cached by an RODC and the RODC authenticates the logon, the
RODC first writes a new value for lastLogonTimeStamp locally for the account and then
forwards the new value to a writable domain controller. This write operation is one of a limited set
of write operations that are performed locally on an RODC. During the next scheduled replication
cycle, the value on the RODC is overwritten because the value that is replicated from the writable
domain controller will have a slightly later time stamp.
If the RODC only forwards the logon attempt to a writable domain controller (because the account
credentials are not cached), the writable domain controller evaluates whether a new value for
lastLogonTimeStamp for the account should be written and performs the write operation, if
applicable.
If you are using scripts to discover stale accounts in your environment, you might update the
scripts in the following way to deal with accounts whose lastLogonTimeStamp might be updated
on an RODC but not on any writable domain controller. This condition occurs in a situation in
which the RODC does not have connectivity with a writable domain controller when the
lastlogontimestamp of a user must be updated as identified during a logon. To determine
whether an account is stale, do the following:
1. Check a writable domain controller in the hub site to determine whether the account is
stale. If a writable domain controller in the hub site indicates that lastLogonTimeStamp has
not been updated recently, continue with the next steps. You must define for your own
organization how recently an account must have logged on before the account is considered
to be stale.
2. Check the msDS-RevealedListBL attribute for the account to determine which domain
controller was used to authenticate the account. This is the back-link that corresponds to the
msDS-RevealedList attribute that is maintained on an RODC account to get an accurate list
of the accounts that are cached on that RODC.

64
 3. If msDS-RevealedListBL indicates the distinguished name of one or more RODCs, try to
connect to those RODCs and check whether the lastLogonTimeStamp has been updated
on any of them but not yet replicated to a writable domain controller in the hub site.
You have to check lastlogonTimeStamp only on the RODCs that cache the user’s password
because other RODCs have to forward any authentication request for that user to a writable
domain controller in a hub site, on which lastLogonTimeStamp will be updated.

Resolving an account lockout problem in a branch

office with an RODC
If the wide area network (WAN) link between the RODC and its writable replication partner is not
available, the RODC can lock out an account that it has cached and the lockoutTime attribute
will not be updated on the primary domain controller (PDC) emulator operations master and
replicated to any other domain controllers. For more information about how the PDC emulator is
updated with account lockout information, see How Operations Masters Work
(http://go.microsoft.com/fwlink/?LinkId=147799).
To manually unlock the account in this situation, unlock the account on the writable domain
controller that is the replication partner of the RODC. (Do this despite the fact that the account
does not appear to be locked out on that domain controller.) As an alternative, you can unlock the
account on the PDC emulator for the domain. When the user tries to log on—even if the unlock
has not yet replicated to the RODC, a retry will happen on the PDC emulator, which ensures that
the user can successfully access his computer.
However, when an account is locked out on a branch RODC while the WAN is offline, the account
can be unlocked only when either the WAN comes back online or the lockout duration expires.
Complete the following procedure when you need to manually unlock an account that is locked
out in a branch office that has an RODC.
Membership in Domain Admins, or equivalent, is the minimum required to complete this
procedure. Review details about using the appropriate accounts and group memberships at
http://go.microsoft.com/fwlink/?LinkId=83477.

To manually unlock an account in a branch office

1. Determine which site the user is in.
2. Determine which domain controller is the PDC emulator. To do this, run the following
command at an elevated command prompt:
netdom query fsmo

Note
To open an elevated command prompt, right click Command Prompt, and then
click Run as Administrator.
3. In the Active Directory Users and Computers snap-in, right click the domain, and then
click Change Domain Controller to target the operation on the PDC emulator. If the
PDC emulator is not available, change domain controllers to target the operation on the

65
 writable Windows Server 2008 domain controller that is the replication partner of the
RODC or on another writable Windows Server 2008 domain controller in the site that is
nearest to the site that has the RODC.
4. Type a new password for the user account, and then select the Unlock the user’s
account check box.

Performing backups of an RODC

Windows Server 2008 includes a new backup application named Windows Server Backup.
Windows Server Backup is not installed by default. You must install it by using the Add Features
option in Server Manager before you can use the Wbadmin.exe command-line tool or Windows
Server Backup on the Administrative Tools menu.
You can back up system state data on a domain controller that runs Windows Server 2008 only
by using the Wbadmin.exe command-line tool. To back up a domain controller, use the wbadmin
startsystemstatebackup command to back up system state data. If you use the wbadmin
startsystemstatebackup command, the backup contains only system state data, which
minimizes the size of the backup. This method provides system state data backups that are
similar to the system state backups that the Ntbackup tool provides in previous versions of
Windows Server.
As a best practice, create a backup volume on a dedicated internal or external hard drive. You
cannot store a system state backup on a network shared drive. In addition, the target volume for
a system state backup cannot be a source volume by default. A source volume is any volume that
has a file that is included in the backup. To change that behavior, you can add the
AllowSSBToAnyVolume registry entry to the server. You must also verify that the following
prerequisites are met before you perform a system state backup to a critical volume:
• The volume that you use to store the system state backup must have twice the amount of
free space as the size of the system state backup, until the backup completes.
• Make sure that the target volume has no shadow copy before the backup starts.
• If a system state backup is stored on a source volume, backup settings should be
configured for full backups. By default, these settings are configured for full backups.
• Periodically check that no other user or program maintains a shadow copy on the target
volume.
• Do not keep volume-level backups and system state backups in the same location.
For more information about adding the AllowSSBToAnyVolume registry entry, see Known
Issues for AD DS Backup and Recovery (http://go.microsoft.com/fwlink/?LinkId=153623).
As an alternative to performing a system state backup, you can use the wbadmin start backup
command with the -allcritical parameter or use Windows Server Backup to perform a backup of
all critical volumes, rather than only backing up system state data. However, this method backs
up all the critical volumes entirely, which can require more disk space than a system state
backup. A volume is considered critical if any system state file is reported on that particular
volume, such as the volumes that host the Active Directory database or SYSVOL.

66
For more information about backing up and restoring domain controllers that run
Windows Server 2008, including how to schedule a regular full server backup, see the AD DS
Backup and Recovery Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=93077).

Monitoring Your Branch Office Environment

This topic contains guidelines for monitoring Active Directory Domain Services (AD DS) and
domain controllers that run Windows Server 2008. These domain controllers may be writable
domain controllers in hub sites or read-only domain controllers (RODCs) in branch offices. Many
of the guidelines presented here are updated from the monitoring guidelines in the
Windows Server 2003 Active Directory Branch Office Planning and Deployment Guide
(http://go.microsoft.com/fwlink/?LinkID=28523).
Determining what to monitor
Using Windows Reliability and Performance Monitor
Monitoring SYSVOL replication
Using System Center Operations Manager

Determining what to monitor

We recommend that you monitor all domain controllers regularly. Domain controllers manage the
directory service and ensure that the information that is stored in the directory is as up to date as
possible. Domain controllers do this by communicating with one another and replicating updates
among themselves. If problems exist that prevent replication from occurring, information that is
stored in the directory might become outdated. Outdated directory data can result in problems,
such as users being unable to access network resources because updated account information is
not available. In addition, a directory that is not up to date is a security risk because a domain
controller might not have the information that an account has been deleted, disabled, or removed
from a security group that is used to grant permissions to resources. In this case, a user might be
granted access to resources even though the account is no longer valid.
Monitoring domain controllers gives you the best opportunity to detect problems before they
jeopardize your environment and the ability of your users to access network resources. Schedule
daily automated health checks for your domain controllers, and monitor the following aspects of
the Active Directory environment on all domain controllers in the deployment:
• General domain controller health (specifically, CPU utilization and disk space use)
• Directory service performance

Monitoring domain controller performance

To monitor the general performance of domain controllers, observe performance counters for
CPU utilization and disk space availability. Monitor these performance counters regularly on all
bridgehead servers. If you experience problems with a branch office domain controller, monitor
these performance counters on that domain controller.

67
Windows Server 2008 and Windows Vista both include Windows Reliability and Performance
Monitor (Perfmon.msc). You can use this tool to monitor these performance counters. However,
we recommend that you use a more comprehensive monitoring solution, such as Microsoft
System Center Operations Manager 2007. For more information about using System Center
Operations Manager 2007 to monitor AD DS, see the Active Directory Management Pack Guide
(http://go.microsoft.com/fwlink/?LinkID=139785).

Monitoring CPU utilization

Monitor CPU utilization on your domain controllers to determine whether the domain controllers
are overloaded by logon traffic or whether bridgehead servers are overloaded by replication
requests. You can also monitor CPU utilization to verify that you are meeting your service-level
agreements.
To monitor a domain controller’s CPU utilization, use Windows Reliability and Performance
Monitor to monitor the Processor\% Processor Time counter.

Monitoring available disk space

Problems can occur with your domain controllers if the partition that stores any of the following
runs out of disk space:
• Active Directory database files
• Active Directory log files
• The SYSVOL folder
Consequently, you must monitor the available disk space for these partitions.
By default, these files and the folder are stored in either C:\WINDOWS\NTDS or
C:\WINDOWS\SYSVOL. To monitor the free disk space on the partition that contains these files
and the folder, use Windows Reliability and Performance Monitor to monitor the LogicalDisk\Free
Megabytes counter.

Monitoring disk utilization

Performance problems can occur if the hard disk on the domain controller cannot keep up with all
the disk read-write requests that it receives. As requests are received, they are queued and
processed when the server has time to service the requests. If the requests are not being
processed fast enough, the queue begins to fill up with the backlog of requests. Monitoring the
size of the queue provides you with the opportunity to detect this situation before a problem
occurs.
Use Windows Reliability and Performance Monitor to observe the queue length. Specifically, use
the PhysicalDisk object and the Avg. Disk Queue Length counter. We recommend that the
outstanding requests on a domain controller not average more than 10. If the queue length
consistently exceeds 10 outstanding requests, you might want to consider using a higher-
performance disk configuration or reducing the workload on the domain controller.

68
Monitoring memory utilization
Make sure that the domain controller has sufficient memory available at all times. You can use the
Available Mbytes counter in the Memory object in Windows Reliability and Performance Monitor
to monitor the amount of memory available. We recommend that domain controllers always have
at least 50 megabytes (MB) of available memory.

Note
The process that runs AD DS is LSASS.exe. This process is designed to maximize the
utilization of available memory but release memory to other processes as they request it.
The result is that if you examine memory utilization through Task Manager, it appears that
LSASS.exe is monopolizing the memory. On a domain controller, this is expected
behavior that helps AD DS run more efficiently.

Monitoring directory service performance

Monitoring directory service performance involves monitoring the amount of information that the
directory service is reading and writing to the directory database, as described in the previous
section, and it also involves monitoring replication traffic between domain controllers. The
following section explains how to monitor Active Directory replication.

Monitoring Active Directory replication

Besides monitoring the domain controllers themselves, you should also monitor replication traffic
between them. Problems with the network can interfere with replication. Network problems can
cause replication to slow down or stop, resulting in backlogs of replication data and inconsistency
among domain controllers. Regular, ongoing monitoring helps you detect problems that might
occur in your Active Directory replication environment. It also gives you the opportunity to correct
these problems before they affect the directory or the users. While you can use Windows
Reliability and Performance Monitor to monitor directory replication from the perspective of the
volume of data traffic, there are additional tools available that you can use to monitor other
aspects of the replication topology. The following table lists the areas of the replication
environment that you should monitor, along with some tools that you can use.

Area Tool Tool notes

Domain Name System
(DNS) and network
configuration
dcdiag /test:<testName>
Performs the following tests:
• Connectivity
• DNS
• RegisterinDNS
These Dcdiag tests replace the
tests that you could perform by
using Netdiag.exe in previous
versions of Windows Server.
Netdiag.exe is not included in
Windows Server 2008 or Remote
Server Administration Tools
(RSAT).

Replication activity Repadmin.exe Replmon.exe, which was

previously included in Windows

69
 Dcdiag.exe Support Tools, is not included in
Windows Server 2008 or RSAT.

Domain controller Windows Reliability and Windows Reliability and

performance Performance Monitor Performance Monitor is included
in Windows Server 2008 and
Windows Vista. Each
performance counter is
individually specified.

Repadmin.exe and Dcdiag.exe are tools that you can use to monitor replication activity between
domain controllers. These tools make it easier to detect problems within the replication topology
by showing the current status of the various replication connections between domain controllers.
These tools are available on servers that run Windows Server 2008 and that have the AD DS
server role installed. The tools are also available in RSAT. For more information about RSAT, see
RODC Administration (http://go.microsoft.com/fwlink/?LinkID=133521) and Installing Remote
Server Administration Tools (http://go.microsoft.com/fwlink/?LinkId=153624).

Repadmin
You can use Repadmin.exe to view the replication topology from the perspective of an individual
domain controller and to diagnose replication problems. In addition, you can use the repadmin
command to force replication events between domain controllers and to view both the replication
metadata and the up-to-dateness vectors. On each domain controller, you can use the
/showrepl, /showconn, /replsummary, and /showutdvec switches with the repadmin
command to monitor replication information. To organize the repadmin /showrepl output in a
more readable, comma-separated value (CSV) format, you can also use the /csv option. For
more information about using the /csv option, see Repadmin Requirements, Syntax, and
Parameter Descriptions (http://go.microsoft.com/fwlink/?LinkId=147380).
/showrepl
Specifying the /showrepl switch displays both inbound and outbound replication partners for
each directory partition that a domain controller hosts. (In the tool, each directory partition is
referred to as a “naming context.”) You can examine the replication partners to determine whether
the domain controller has the correct connection objects.
For each replication partner, /showrepl also displays the last time that replication was attempted
and whether the attempt was successful. For more information about using /showrepl, see
Display Replication Partners and Status of a Domain Controller (http://go.microsoft.com/fwlink/?
LinkId=124353).
/showconn
Specifying the /showconn switch displays the connection objects on the domain controller. You
can examine the connection objects to determine whether the domain controller is configured to
replicate with the correct bridgehead servers in the hub site. In addition, you can use this switch
to verify that the connection is enabled, to identify the transport being used, and to check when
the connection object was created and when it was last changed. For more information about

70
using /showconn, see Can I Look at My Connection Objects and Schedule Details?
(http://go.microsoft.com/fwlink/?LinkId=124354).
/replsummary
Specifying the /replsummary switch can be a very useful way to check the replication health of
your deployment and determine where potential issues might be. To create this summary,
repadmin contacts each domain controller in the forest and collects replication status
information.
The information that is collected is summarized, and two views are generated: one from the
source perspective and one from the destination perspective. The information is presented in
three columns: Source DC, Largest Delta, and Fails/total.
From the source domain controller perspective, the columns can be interpreted as follows:
• Source DC: The domain controller that other domain controllers are attempting to
replicate from.
• Largest Delta: The amount of time that has elapsed since all replication partners
successfully replicated from this domain controller.
• Fails/total: A number that shows how many of the total number of replica links are failing.
A high ratio of fails to total may indicate that the source domain controller is probably causing
a problem.
From the destination domain controller perspective, the columns can be interpreted as follows:
• Destination DC: The domain controller on which the replica links that specify inbound
replication are located.
• Largest Delta: The amount of time that has elapsed since this domain controller last
successfully replicated with each replication partner.
• Fails/total: A number that shows how many of the replication links on the destination
domain controller are failing. A high ratio indicates that the failure is likely attributable to the
destination domain controller.
In general, the source domain controller perspective is often more useful because a 100-percent
failure rate indicates that the source domain controller cannot be reached by any of its replication
partners and that it is offline or experiencing network issues. For more information about using
/replsummary, see Monitor Forest-Wide Replication (http://go.microsoft.com/fwlink/?
LinkId=124355).
/showutdvec
Examining the up-to-dateness (UTD) vector from time to time on one bridgehead server is
another good way to ensure that replication is healthy. The UTD vector shows the last time that a
domain controller has received updates from each replication partner for a particular naming
context. The UTD vector is transitive in that one domain controller does not have to communicate
directly with another domain controller to receive an update from it.

Note
/showutdvec shows the health of only inbound replication, which is sufficient for an
RODC.

71
The output of this switch is a list of dates and times indicating the last time that inbound
replication of the Configuration container occurred from each domain controller. If an excessive
amount of time has passed since replication last took place, it could indicate a problem and there
is reason to be concerned.
The entries are listed by domain controller. Occasionally, a globally unique identifier (GUID)
appears instead of the name of a domain controller. It is safe to ignore the GUID entries because
they indicate invocation IDs for domain controllers that have been demoted or rebuilt. These
entries do not affect the health of the topology.

Note
The invocation ID is the server database GUID that domain controllers use to ensure
replication consistency after a restore operation. For more information, see article 885875
in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=137184).

Dcdiag
You can use Dcdiag.exe to analyze the state of a domain controller and its interaction with other
domain controllers. Dcdiag.exe performs the following tests and reports both status and
problems:
• Connectivity
• Replication
• Topology Integrity
• Check NC Head Security Descriptors
• Check Net Logon Rights
• Locator Get Domain Controller
• Intersite Health
• Check Roles
• Trust Verification
To monitor Active Directory replication, use the following switches with the dcdiag command.

Switch Description

/v Provides verbose results, which makes

troubleshooting errors easier.

/f:<LogFile> Redirects output to the specified log file.

/ferr:<ErrLog> Redirects fatal error output to a separate log

file.

For more information about Dcdiag, see Dcdiag (http://go.microsoft.com/fwlink/?LinkID=133110).

72
When to monitor branch office domain controllers
Monitoring should be part of your daily operations. Implementing a regular monitoring solution
helps you track the health of your environment on a daily basis. Checking monitoring feedback on
a daily basis makes it much easier to spot potential problems early and gives you a better chance
to diagnose them before they affect the functionality of the directory.
Monitoring should be integrated into your deployment plan. Building your monitoring solution into
your deployment plan provides two key benefits:
• Makes it possible to monitor your deployment
If you are able to discover problems during the deployment process, you can address them
as they are revealed. If necessary, you can pause the deployment operations so that you can
solve problems that might not have been discovered during your deployment testing.
Monitoring during your deployment helps to ensure that your new environment is operating as
expected.
• Makes it easier to deploy your monitoring solution
Having your monitoring plan in place during the deployment operations means that you
already know where your monitoring components must be located. Therefore, you might be
able to use your deployment process to also distribute your monitoring components. In this
way, newly deployed computers will already have their monitoring components in place when
they are brought online at their new locations. Implementing your monitoring solution during
deployment eliminates the need for a second deployment operation to implement monitoring
after the initial deployment is complete.
After the deployment is complete, continue to perform daily monitoring operations and keep
track of the daily health of your directory environment. The items that you should monitor are
described in other sections of this topic. Over time, you will determine which items you need
to track in your particular environment. It is not likely that everyone will need to track every
option all the time. Rather, you will learn over time which items are useful to you for your
particular circumstances. When your environment is stable, continue your monitoring
activities on a daily basis. Monitoring is something that you should continue to perform
throughout the lifetime of your directory.

Scheduling
If your branch office domain controllers replicate with the bridgehead servers in the hub site only
once a day, schedule the daily quality assurance check to occur after the replication cycle
completes. You can then verify that the day’s replication was successful, detect problems that
might have occurred, and correct those problems before the next replication cycle begins. If the
quality assurance check is performed before the daily replication cycle, you might not detect
problems for up to 24 hours, which might allow the problem to have a greater effect on your
environment.

73
Using Windows Reliability and Performance
Monitor
Windows Reliability and Performance Monitor is a built-in tool for monitoring various performance
counters that are built into Windows Server 2008. You can use Windows Reliability and
Performance Monitor to monitor CPU utilization, memory utilization, disk use, and Active Directory
database performance, as described in Monitoring domain controller performance.
To monitor the general performance of domain controllers, use Windows Reliability and
Performance Monitor to observe performance counters for CPU utilization and disk space
availability. Monitor these performance counters regularly on all bridgehead servers. If you
experience problems with a branch office domain controller, monitor these counters on that
domain controller.
Using Windows Reliability and Performance Monitor involves collecting monitoring data over a
period of time and then viewing the results. For example, to monitor whether a server is regularly
receiving and applying directory replication updates, you can select one or more counters from
the NTDS performance object and then view the current activity in Windows Reliability and
Performance Monitor.
Monitor the counters of the following performance objects:
• NTDS object counters
• Database object counters
When they are monitored over time, the NTDS and Database performance counters should all
show some activity. However, the amount of activity depends on your environment. Factors that
affect activity include the number of branch office domain controllers and clients in your
environment, how often replication is scheduled, the number of directory changes that occur, and
so on.

Installing performance objects and running the Active Directory

Diagnostics Data Collector Set
The NTDS and Database object counters are not installed by default. This section explains how
to install the NTDS and Database object counters and how to run the Active Directory Diagnostics
Data Collector Set to capture NTDS and Database object data over time.

To install NTDS and Database object counters

1. Click Start, click Administrative Tools, and then click Reliability and Performance
Monitor.
2. Double-click Monitoring Tools, right-click Performance Monitor, and then click
Properties.
3. Click the Data tab, and then click Add.
4. Double-click the name of the Performance object whose counters you want to install,
click the name of each counter, and then click Add. For example, double-click NTDS, and
then click each counter that is listed in the following section. After you select the

74
 appropriate counters, click Add.
5. Click OK to close the Add Counters dialog box, and then click OK to close
Performance Monitor Properties.

To start the Active Directory Diagnostics Data Collector Set

1. Click Start, click Administrative Tools, and then click Reliability and Performance
Monitor.
2. Double-click Data Collector Sets, double-click System, right-click Active Directory
Diagnostics, and then click Start.
3. To stop the data collection, right-click Active Directory Diagnostics, and then click
Stop.

Using NTDS object counters

Use NTDS performance object counters to monitor the performance of AD DS. The NTDS
performance object includes counters that provide information about Active Directory replication
activity between domain controllers, Lightweight Directory Access Protocol (LDAP), and
authentication. The following table describes the NTDS counters that you can use to monitor
AD DS.

Object\counter Description Guidelines

NTDS\DRA Inbound Bytes Indicates the total number of This counter should show activity
Total/sec bytes received per second over time. If it does not, the
through inbound replication. network is probably slowing
This number is the sum of replication.
the bytes of uncompressed
and compressed data
received during inbound
replication.

NTDS\DRA Inbound Object
Updates Remaining in Packet
Indicates the number of
object updates received in
the most recent directory
replication update packet
that have not yet been
applied to the local server.
This counter indicates that the
monitored server is receiving
changes, but it is taking a long time
to apply them to the database. This
counter should be as low as
possible. If it is not, it usually
indicates that server hardware is
slowing replication.

NTDS\DRA Outbound Bytes Indicates the total number of This counter should show activity
Total/sec bytes sent per second over time, except on an RODC,
during outbound replication. where outbound replication does
This number is the sum of not occur. If this does not show

75

NTDS\DRA Pending
Replication Synchronizations
NTDS\ATQ Threads LDAP
NTDS\ATQ Threads Total
NTDS\Kerberos
Authentications/sec
NTDS\LDAP Bind Time
NTDS\LDAP Client Sessions
NTDS\LDAP Searches/sec
bytes of uncompressed and
compressed data.
Indicates the number of
directory synchronizations
that are queued for this
server. This counter helps
identify replication backlogs
—the higher the number,
the larger the backlog.
Indicates the number of
threads that are being used
by the directory service.
Indicates the number of
threads that are being used
by the directory service.
Indicates the number of
Kerberos authentications
that the domain controller
services per second.
Indicates the time in
milliseconds (msec) that
was required to complete
the last successful LDAP
binding.
Indicates the number of
sessions of connected
LDAP clients.
Indicates the number of
activity, either server hardware or
network problems are slowing
replication.
This counter should be as low as
possible. If it is not, the server
hardware is probably slowing
replication.
If values for this counter and the
NTDS\ATQ Threads Total counter
are equal, a queue is likely building
on the LDAP port, which will result
in long response times. If the two
counters are always equal, use
Server Performance Advisor to
troubleshoot the problem.
If values for this counter and
NTDS\ATQ Threads LDAP counter
are equal, a queue is likely building
on the LDAP port, which will result
in long response times. If the two
counters are always equal, use
Server Performance Advisor to
troubleshoot the problem.
This counter should show activity
over time. If it does not and the
clients use the Windows Server 
2008 operating system, network
problems are indicated.
This counter should be as low as
possible. If it is not, hardware or
network-related problems are
indicated.
This counter should show activity
over time. If it does not, it usually
indicates that network-related
problems are occurring.
This counter should show activity
76
 search operations over time. If it does not, network
performed by LDAP clients problems are probably hindering
per second. the processing of client requests.

NTDS\NTLM Authentications
Indicates the number of
NTLM authentications
serviced by the domain
controller per second.
This counter should show activity
over time. If it does not and the
clients use the Windows® 98 or
Windows NT® operating systems,
network-related problems are
indicated.

NTDS\DS Directory Indicates how many This counter should show activity
Searches/sec searches are occurring. over time. If it does not, network
problems are probably hindering
the processing of client requests.

NTDS\DS Search Sub-
operations/sec
Indicates how “large” the
directory service search
operations are.
This counter should show activity
over time. If it does not, network
problems are probably hindering
the processing of client requests. If
the ratio of this counter to
DS Directory Searches/sec is very
high, the server might be getting
bogged down by a large number of
expensive queries. You can run the
Active Directory Diagnostics Data
Collector Set to analyze the load
on the server to see if the load is
expected.

Using Database object counters

Use Database performance object counters for advanced monitoring of the Active Directory
database. The Database performance object monitors the Extensible Storage Engine (ESENT),
which is the transaction-based database system that stores all Active Directory objects. The
Database counters provide information about the performance of the database cache, files, and
tables. You can use some of these counters to determine whether you need additional hard disks
to store Active Directory data. The following table describes the Database counters that you can
use to analyze the Active Directory database.

Object\counter Description Guidelines

Database\Database Cache % Hit Indicates the percentage of This counter should show
page requests for the activity over time. If it does not,
database file that were the server does not have

77
 fulfilled by the database enough free memory. In this
cache without causing a file case, add more memory.
operation.

Database\Database Page Fault Indicates the number of This counter should be 0. If it is

Stalls/sec page faults that occur per not, the server probably needs
second that cannot be more memory.
serviced because no pages
are available in the database
cache for allocation.

Database\Database Page Indicates memory pressure If this counter is too high, the
Evictions/sec on the database cache. Active Directory host computer
needs more memory.

Database\Database Cache Size
Indicates the current amount
of memory that AD DS uses
to cache its database.
If the amount of memory that
AD DS uses is low and the
Database Page Eviction rate is
high, the host computer might
need more memory.

Database\Log Threads Waiting
Indicates the number of
threads that are waiting for
data to be written to the log
so that updates to the
database can be written.
This counter should be as low
as possible. If it is not, the
server probably needs more
memory or a faster hard disk.

Monitoring SYSVOL replication

This section explains how to use Distributed File System (DFS) Replication tools to monitor
replication of SYSVOL. You can use DFS Replication to replicate SYSVOL if the domain
functional level is Windows Server 2008. If the domain functional level is not
Windows Server 2008, you can only use File Replication Service (FRS) to replicate SYSVOL. If
you are using FRS to replicate SYSVOL, you can use a tool such as Ultrasound to monitor FRS.
For more information about using Ultrasound, see the Windows Server 2003 Active Directory
Branch Office Guide (http://go.microsoft.com/fwlink/?LinkID=28523).
You can use the DFS Management snap-in to administer DFS Replication. DFS Management is
not installed by default. You can use the following procedure to install it.

To install DFS Management

1. Click Start, and then click Server Manager.
2. Click Add Features.
3. Double-click Remote Server Administration Tools, double-click Role
Administration Tools, double-click File Services Tools, select the Distributed File

78
 System Tools check box, and then click Next.
4. Click Install, and when the installation is complete, click Close.

You can use the DFS Management snap-in to create a health report about DFS Replication of
SYSVOL.

To create a health report about DFS Replication of SYSVOL

1. Click Start, click Administrative Tools, and then click DFS Management.
2. Double-click Replication, right-click Domain System Volume (SYSVOL), click
Create Diagnostic Report, and then follow the instructions in the Diagnostic Report
Wizard.

Using System Center Operations Manager

We recommend System Center Operations Manager 2007 services for monitoring the servers
that reside in your data center site. System Center Operations Manager 2007 is the suite of
Microsoft enterprise monitoring software. You can purchase System Center Operations
Manager 2007 as an additional package that provides a comprehensive, enterprise-wide
monitoring solution. After you deploy System Center Operations Manager 2007, you can
download management packs from the Microsoft Web site. For more information about System
Center Operations Manager, see Microsoft System Center Operations Manager
(http://go.microsoft.com/fwlink/?LinkId=124356).
Management packs are preconfigured, technology-specific monitoring solutions that are loaded
into the System Center Operations Manager 2007 environment so that you can monitor specific
aspects of your deployment. For example, in a branch office environment, you can use the
Active Directory Management Pack to monitor the domain controllers in your organization’s data
center. For more information about using System Center Operations Manager 2007 to monitor
AD DS, see the Active Directory Management Pack Guide (http://go.microsoft.com/fwlink/?
LinkID=139785).

79