Windows Server 2008 R2 Unleashed (49 page)

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