Download May 2010 - Center

The most common environments for RODCs using AD DS are still branch offices. These
types of environments are typically end points in a hub-and-spoke network topology. They
are widely distributed geographically, in large numbers, and they individually host small
user populations, connect to hub sites by slow, unreliable network links, and often lack
local, experienced administrators.
For branch offices already hosting writable DCs, it’s probably unnecessary to deploy RODCs.
In this scenario, however, RODCs may not only meet existing AD DS-related requirements,
but also exceed them with regard to tighter security, enhanced management, simplified
architecture and lower total cost of ownership (TCO). For locations where security or
manageability requirements prohibit using DCs, RODCs can help you introduce DCs into the
environment and provide a number of beneficial, localized services.
Although the new features and benefits make evaluating RODCs compelling, there are
additional factors to consider, like application compatibility issues and service impact
conditions. These could render RODC deployments unacceptable for certain environments.
For example, because many directory-enabled applications and services read data from AD
DS, they should continue to function and work with an RODC. However, if certain
applications require writable access at all times, an RODC may not be acceptable. RODCs
also depend on network connectivity to a writable DC for write operations. Although failed
write operations may be the cause of most well-known application-related issues, there are
other issues to consider, such as inefficient or failed read operations, failed write-read-back
operations, and general application failures associated with the RODC itself.
Besides application issues, fundamental user and computer operations can be affected
when connectivity to a writable DC is disrupted or lost. For example, basic authentication
services may fail if account passwords are not both cacheable and cached locally on the
RODC. You can easily mitigate this issue by making accounts cacheable through an RODC’s
Password Replication Policy (PRP), and then caching the passwords through prepopulation. Performing these steps also requires connectivity to a writable DC.
Along with other authentication issues, password expirations and account lockouts are
significantly impacted when connectivity to a writable DC is unavailable. Password change
requests and any attempts to manually unlock a locked account will continue to fail until
connectivity to a writable DC is restored. Understanding these dependencies and
subsequent changes in operational behavior is critical to ensuring your requirements and
any service level agreements (SLAs).
There are several general scenarios in which you can deploy RODCs. They’re useful in
locations that don’t have existing DCs, or in locations that currently host DCs that will either
be replaced or upgraded to a newer version of Windows. Although there are comprehensive
planning considerations specific to each scenario, we’ll focus here on non-specific
approaches. They are, however, distinct to RODCs, rather than to traditional writable DCs.
4