Windows
Server 2008 R2 improvements in AD DS replication are directly drawn
from lessons learned in Windows 2000, Windows Server 2003, and Windows
Server 2008. Read-Only
Domain Controllers (RODCs) can be created in remote sites to reduce
replication and increase security. Replication compression can now be
disabled in well-connected sites, enabling designers to sacrifice
bandwidth for processor utilization in domain controllers (DCs). In
addition, concepts such as DC promotion from media allow global catalog
servers to be created from CDs or other media, which greatly increases
DC placement flexibility. Other improvements, such as universal group
caching on domain controllers, allow remote domain controllers to
function as global catalog servers by caching frequently used universal
group membership locally.
Many of these
improvements to AD DS replication were introduced with Windows Server
2008 and, although there are few new replication-specific improvements
in Windows Server 2008 R2, this latest version cements these new
features and fixes design limitations that have thwarted replication
plans in the past. Problems with replication design can potentially
cripple a network; therefore, it is wise to put some serious thought
into the proper layout and design of an effective replication scheme.
Understanding the Role of Replication in AD DS
All enterprise directory
environments must include mechanisms to synchronize and update directory
information across the entire directory structure. In Windows Server
2008 R2 AD DS, this means that every domain controller must be updated
with the most recent information so that users can log on, access
resources, and interact with the directory accurately.
AD DS differs from many
directory services implementations in that the replication of directory
information is accomplished independently from the actual logical
directory design. The concept of AD DS sites is completely independent
from the logical structure of AD DS forests, trees, and domains. In
fact, a single site in AD DS can actually host domain controllers from
different domains or different trees within the same forest. This allows
for the creation of a replication topology based on a wide area network
(WAN) structure, while the directory topology can mirror the
organization’s structure.
Outlining Multimaster Topology Concepts
AD DS was specifically
written to allow for the creation, modification, and deletion of
directory information from multiple domain controllers. This concept,
known as multimaster replication, allows no one domain controller to be
authoritative. If any domain controllers go out of service, any one of
the rest of the writable domain controllers can make changes to
directory information. Those changes are then replicated across the
domain infrastructure. Of course, there needs to be some level of
control on this type of replication so that only the most recent changes
take precedence. This type of control is realized in AD DS through the
concept of Update Sequence Numbers (USNs).
Explaining Update Sequence Numbers (USNs)
All enterprise directory
services implementations require a mechanism to handle the incremental
storage of changes made to directory objects. In other words, whenever a
password is changed, that information must be accurately passed to all
domain controllers in the domain. This mechanism must also be able to apply only those changes that occurred at the most recent intervals.
Many directory
services implementations relied on exact time synchronization on all
domain controllers to synchronize information. However, keeping the
clocks of multiple servers in sync has been proven to be extremely
difficult, and even slight variations in time could affect replication
results.
Thus was born the concept
of the Update Sequence Number. AD DS utilizes USNs to provide for
accurate application of directory changes. A USN is a 64-bit number that
is maintained by each domain controller in AD DS. The USN is
sequentially advanced upon each change that is made to the directory on
that specific server. Each additional domain controller also contains a
copy of the last-known USN from its peers. Updates are subsequently made
to be more straightforward. For example, when requesting a replication
update from Server2, Server1 will reference its internal table for the
most recent USN that it received from Server2 and request only those
changes that were made since that specific number. The simplicity of
this design also ensures accuracy of replication across the domain
environment.
The integrity of replication
is ensured with USNs because the USN number is updated only upon
confirmation that the change has been written to the specific domain
controller. This way, if a server failure interrupts the replication
cycle, the server in question will still seek an update based on its USN
number, ensuring the integrity of the transaction.
Describing Replication Collisions
The concept of USNs does not
completely eliminate the role of proper time synchronization in AD DS.
It is still important to maintain accurate time across a domain
environment because of the possibility of replication collisions. A
replication collision is an inaccuracy in replicated information that
takes place because of changes that are enacted on the same object, but
before that change has been replicated to all domain controllers. For
example, if an administrator resets a user’s password on Server1, and
another administrator resets the same user’s password on Server2 before
Server1 has had a chance to replicate that change, a replication
collision will occur. Replication collisions are resolved through the
use of property version numbers.
Understanding Property Version Numbers
Property version numbers are
applied as an attribute to all objects within AD DS. These numbers are
sequentially updated and time-stamped whenever a change is made to that
object. If a replication collision occurs, the property version number
with the latest time stamp will be enacted, and the older change will be
discarded. In the example from the preceding section, the password
change with the latest time stamp will be applied to the user.
This concept
subsequently requires accurate time synchronization to be a priority for
an AD DS domain—although it is not as critical as in other directory
services implementations that rely on it for all replication activity.
|
Time
is an important aspect in AD DS. Kerberos is the native authentication
mechanism used by Windows AD DS and bases its ticketing system on an
accurate time source. If two machines in the same domain differ by more
than five minutes, authentication will break. As such, accurate time
must be shared among domain members.
Windows Server 2008 R2
utilizes the Windows Time Service and the domain hierarchy to maintain a
consistent source of time among all the domain controllers throughout
the domain.
One server, the PDC emulator, is responsible for getting accurate time from a manual trusted source, such as NIST, time.windows.com, pool.ntp.org,
or a GPS clock. This trusted source is known as stratum 0. The PDC
emulator is stratum 1. Stratum 2 goes to all other DCs in the same site
as the PDC emulator. The bridgehead server in remote sites is stratum 3
and all other DCs in the same remote site are stratum 4.
Member computers will try to get
time from the lowest stratum DC in their own site. If that DC is not
serving time, they will use the next highest stratum.
Domain computers always
honor this system, which explains why the clock will reset to the domain
time automatically, even if you change the local clock. Time normally
syncs at startup and every 45 minutes thereafter for three consecutive,
successful times, and then the interval check period is increased to 8
hours.
It is important that administrators configure and test the manually configured external time source on the PDC emulator.
|
Describing Connection Objects
Connection objects are
automatically generated by the AD DS Knowledge Consistency Checker (KCC)
to act as pathways for replication communication. They can be manually
established, as well, and essentially provide a replication path between
one domain controller and another. If, for example, an organization
wants to have all replication pushed to a primary domain controller
(PDC) before it is disseminated elsewhere, direct connection objects can
be established between the two domain controllers.
Creating a connection object is a
straightforward process. After one is created, Windows Server 2008 R2
does not attempt to automatically generate a new one across the same
route unless that connection object is deleted. To manually set a
connection object to replicate between domain controllers, perform the
following steps:
1. | Open Active Directory Sites and Services.
|
2. | Expand
Sites\<Sitename>\Servers\<Servername>\NTDS Settings, where
Servername is the source server for the connection object.
|
3. | Right-click NTDS Settings and choose New Active Directory Domain Services Connection.
|
4. | Select the target domain controller, and click OK.
|
5. | Name the connection object, and click OK.
|
6. | Right-click
the newly created connection object, and select Properties to open a
properties page for the object. You can then modify the connection
object to fit any specific schedule, transport, and so on.
|
Note
The connection
objects that appear as automatically generated were created by the KCC
component of AD DS to provide for the most efficient replication
pathways. You must, therefore, have a good reason to manually create
these pathways because the automatically generated ones usually do the
trick.
Understanding Replication Latency
Administrators who are
not accustomed to AD DS’s replication topology might become confused
when they make a change in AD and find that the change is not replicated
immediately across their environment. For example, an administrator
might reset a password on a user’s account, only to have that user
complain that the new password does not immediately work. The reason for
these types of discrepancies simply lies in the fact that not all AD
changes are replicated immediately. This concept is known as replication
latency. Because the overhead required in replicating change
information to all domain controllers immediately is large, the default
schedule for replication is not as often as might be desired.
Replication of critical information can be forced through the following
procedure:
1. | Open Active Directory Sites and Services.
|
2. | Drill
down to Sites\<Sitename>\Servers\<Servername>\ NTDS
Settings, where Servername is the server that you are connected to and
that the desired change should be replicated from.
|
3. | Right-click each connection object, and choose Replicate Now.
|
Another useful tool that can be
used to force replication is the repadmin command-line tool. This tool
is installed as part of a default Windows Server 2008 R2 domain
controller install. After being installed, repadmin can be used to force
replication for the entire directory, specific portions of the
directory, or to sync domain controllers across site boundaries. If the
bandwidth is available, a batch file can be effectively written to force
replication between domain controllers, converging the directory as
quickly as possible.
The default replication schedule
can be modified to fit the needs of your organization. For example, you
might decide to change the default schedule of 180 minutes to a
schedule as low as every 15 minutes. To make this change, perform the
following steps:
1. | Open Active Directory Sites and Services.
|
2. | Drill down to Sites\Inter-Site Transports\IP.
|
3. | Right-click the site link that requires schedule changes and choose Properties.
|
4. | Change the Replicate every field to the new replication interval, as shown in Figure 1.
|
5. | Click OK to save any schedule changes.
|
Of course, changing this
schedule comes with some caveats, namely watching for increased
frequency of high network bandwidth utilization. You should match the
trade-off of your organization’s needs with the increased resource
consumption levels required.
