Read Windows Server 2008 R2 Unleashed Online
Authors: Noel Morimoto
understand and troubleshoot.
Choosing Replication Scheduling
Replication traffic can potentially consume all available bandwidth on small or saturated
WAN links. By changing the site link replication schedule for off-hours, you can easily
force this type of traffic to occur during times when the link is not utilized as heavily. Of
course, the drawback to this approach is that changes made on one side of the site link
would not be replicated until the replication schedule dictates. Weighing the needs of the
WAN with the consistency needs of your directory is, therefore, important. Throttling the
replication schedule is just another tool that can help to achieve these goals.
210
CHAPTER 7
Active Directory Infrastructure
Choosing SMTP or IP Replication
By default, most connections between sites in AD DS utilize IP for replication because the
default protocol used, RPC, is more efficient and faster. However, in some cases, it might
be wiser to utilize SMTP-based replication. For example, if the physical links on which the
replication traffic passes are not always on (or intermittent), SMTP traffic might be more
ideal because RPC has a much lower retry threshold.
A second common use for SMTP connections is in cases where replication needs to be
encrypted so as to cross unsecured physical links, such as the Internet. SMTP can be
encrypted through the use of a Certificate Authority (CA) so that an organization that
requires replication across an unsecured connection can implement certificate-based
encryption.
NOTE
SMTP replication cannot be used as the only method of replicating to a remote site. It
can only be used as a supplemental replication transport, as only certain aspects of
domain replication are supported over SMTP. Subsequently, the use of SMTP replication
as a transport is limited to scenarios where this form of replication is used in addition
to RPC-based replication.
ptg
Windows Server 2008 R2 Replication Enhancements
The introduction of Windows 2000 provided a strong replication topology that was adap-
tive to multiple environments and allowed for efficient, site-based dissemination of direc-
tory information. Real-world experience with the product has uncovered several areas in
replication that required improvement. Windows Server 2008 R2 addressed these areas by
including replication enhancements in AD DS that can help to increase the value of an
organization’s investment in AD.
Domain Controller Promotion from Media
An ingenious mechanism in Windows Server 2008 R2 allows for the creation of a domain
controller directly from media such as a burnt CD/DVD, USB drives, or tape. The upshot
of this technique is that it is now possible to remotely build a domain controller or global
catalog server across a slow WAN link by shipping the media to the remote site ahead of
time, effectively eliminating the common practice of building a domain controller in the
central site and then shipping it to a remote site after the fact.
The concept behind the media-based GC/DC replication is straightforward. A current,
running domain controller backs up the directory through a normal backup process. The
backup files are then copied to a backup media, such as a CD/DVD, USB drive, or tape,
and shipped off to the remote destination. Upon their arrival, the dcpromo command can
be run, and Advanced mode can be chosen from the wizard. In the Advanced mode of the
wizard, the dialog box shown in Figure 7.7 allows for dcpromo to be performed against a
local media source.
Planning Replication Topology
211
FIGURE 7.7
Dcpromo from media.
After the dcpromo command restores the directory information from the backup, an
ptg
incremental update of the changes made since the media was created will be performed.
Because of this, there still needs to be network connectivity throughout the dcpromo
process, although the amount of replication required is significantly less. Because some
dcpromo operations across slow WAN links have been known to take days and even
weeks, this concept can dramatically help to deploy remote domain controllers.
7
NOTE
If the copy of the global catalog that has been backed up is older than the tombstone
date for objects in the AD DS (by default, 60 days from when an object was last validat-
ed as being active), this type of dcpromo will fail. This built-in safety mechanism pre-
vents the introduction of lingering objects and also ensures that the information is
relatively up to date and no significant incremental replication is required.
Identifying Linked-Value Replication/Universal Group Membership
Caching
Previously, all groups in AD DS had their membership listed as a multivalued attribute.
This meant that any time the group membership was changed, the entire group member-
ship needed to be rereplicated across the entire forest. Windows Server 2008 R2 includes
an incremental replication approach to these objects, known as linked-value replication.
This approach significantly reduces replication traffic associated with AD DS.
Directly associated with this concept, Windows Server 2008 R2 allows for the creation of
domain controllers that cache universal group membership. This means that it is no
longer necessary to place a global catalog server in each site. Any time a user utilizes a
212
CHAPTER 7
Active Directory Infrastructure
universal group, the membership of that group is cached on the local domain controller
and is utilized when the next request comes for that group’s membership. This also lessens
the replication traffic that would occur if a global catalog was placed in remote sites.
One of the main sources of replication traffic was discovered to be group membership
queries—hence, the focus on fixing this problem. In Windows 2000 Active Directory,
every time a client logged on, the client’s universal group membership was queried,
requiring a global catalog to be contacted. This significantly increased logon and query
time for clients who did not have local global catalog servers. Consequently, many organi-
zations stipulated that every site, no matter the size, must have a local global catalog
server to ensure quick authentication and directory lookups. The downside of this was
that replication across the directory was increased because every site received a copy of
every item in the entire AD, even though only a small portion of those items was refer-
enced by an average site.
Universal group caching solved this problem because only those groups that are commonly
referenced by a site are stored locally, and requests for group replication are limited to the
items in the cache. This helps to limit replication and keep domain logons speedy.
Universal group caching capability is established on a per-site basis through the follow-
ing technique:
ptg
1. Open Active Directory Sites and Services.
2. Navigate to Sites\
3. Right-click NTDS Site Settings and choose Properties.
4. Check the Enable Universal Group Membership Caching check box, as shown in
Figure 7.8.
Optionally, you can specify from which site to refresh the cache.
5. Click OK to save the changes.
Removing Lingering Objects
Lingering objects, also known as zombies, are created when a domain controller is down
for a period of time that is longer than the tombstone date for the deletion of items.
When the domain controller is brought back online, it never receives the tombstone
request and those objects always exist on the downed server. These objects could then be
rereplicated to other domain controllers, arising from the dead as “zombies.” Windows
Server 2008 R2 has a mechanism for detecting lingering objects, isolating them, and
marking them for cleanup.
Disabling Replication Compression
By default, intersite AD replication is compressed so as to reduce the bandwidth consump-
tion required. The drawback to this technique is that extra CPU cycles are required on the
domain controllers to properly compress and decompress this data. Windows Server 2008
R2 allows designers the flexibility to turn off this compression, if an organization is short
on processor time and long on bandwidth, so to speak.
Outlining Windows Server 2008 R2 IPv6 Support
213
FIGURE 7.8
Enabling universal group caching in a site.
ptg
Understanding How AD Avoids Full Synchronization of Global Catalog
with Schema Changes
In the original version of Active Directory, any schema modifications would force a
complete resynchronization of the global catalog with all domain controllers across an
7
enterprise. This made it extremely ominous to institute any type of schema modifications
because replication modifications would increase significantly following schema modifica-
tions. Windows Server 2003 or 2008 environments do not have this limitation, however,
and schema modifications are incrementally updated in the global catalog.
Intersite Topology Generator Algorithm Improvements
The intersite topology generator (ISTG) portion of the Knowledge Consistency Checker
(KCC) has been updated to allow AD environments to scale to site structures of up to
5,000 sites. Previous limitations to the Windows 2000 ISTG essentially kept AD implemen-
tations effectively limited to 1,000 sites. This improvement, however, is available only
when all domain controllers in your AD DS environment are at least Windows Server
2003 systems and the forest functional level has been raised to Windows Server 2003 or
2008 level.
Outlining Windows Server 2008 R2 IPv6 Support
When the original structure of the Internet was taking shape, an addressing scheme was
formulated to scale to a large number of hosts. From this thinking came the original
design of the Internet Protocol, which included theoretical support for around 4 billion
214
CHAPTER 7
Active Directory Infrastructure
addresses, or 232. The thinking at the time was that this would be more than enough
addresses for all hosts on the Internet. This original design gave birth to the IP address
structure that is common today, known as dotted-decimal format (such as
12.155.166.151). At the time, this address space filled the addressing needs of the Internet.
However, it was quickly discovered that the range of addresses was inadequate, and
stopgap measures such as Network Address Translation (NAT) were required to make more
efficient use of the available addresses.
In addition to an inadequate supply of available addresses, the Internet Protocol version 4
(IPv4), as it is known, did not handle routing, IPSec, and QoS support very efficiently. The
need for a replacement to IPv4 was evident.
In the early ’90s, a new version of the Internet Protocol, known as Internet Protocol
version 6 (IPv6), was formulated. This design had several functional advantages to IPv4,
namely a much larger pool of addresses from which to choose by allowing for 2128 theoret-
ical IP addresses, or over 340 undecillion, which gives more than enough IP addresses for
every square centimeter on the earth. This protocol is the future of Internet addressing,
and it’s vitally important that an operating system support it.
Windows Server 2008 R2 comes with a version of IPv6 installed, and is fully supported as