2.3 Active Directory replication

---

As with the Exchange 5.5 Directory Store (DS), the AD replicates data concerning users, contacts, distribution lists (groups), and configuration between servers. Replication is the term that describes the propagation of data from an originating server to other connected servers, in this case within a Windows 2000/2003 domain or forest of domains. We could spend a lot of time delving into the details of how AD replication works, but this topic deserves its own book. Instead, we will look at the basics of AD replication between domain controllers and Global Catalog servers.

Understanding how AD replicates information is important for Windows and Exchange administrators alike. If replication cannot happen, Exchange or any other AD-enabled application will have problems. Successful Exchange projects invariably have a solid AD deployment in place before the installation of the first Exchange server.

2.3.1 Replication basics

The goal of any replication mechanism is to propagate data as quickly as possible so that all participants in replication receive updates and can build their own synchronized copy of the data. After replication has finished, all copies should be consistent. In a fast-moving networked environment, where users and computers update data all the time, it is difficult to achieve a state of perfect replication, so you can consider the AD partition hosted on any individual DC to be in a state of loose consistency. In other words, while the vast majority of the data in the AD is consistent and synchronized with the server's replication partners, it is likely that outstanding replication operations are en route somewhere in the network. In a perfect world, we would have only one copy of the directory (unlikely a worldwide deployment) or be able to freeze changes for a time to allow all servers to perform any outstanding replication operations to achieve perfect synchronization throughout the network. Unfortunately, we do not live in a perfect world, so we have to be satisfied that the AD is loosely consistent at any point in time.

DCs are responsible for initiating and participating in replication operations. Each DC holds a complete read/write copy of the objects for its domain and acts since a replication partner for other DCs. Replication only occurs between DCs, since member servers do not hold a copy of the AD.

GCs hold a partial read-only copy of the objects for the other domains in the forest as well as the fully writable set of objects for its own domain. We say partial copy, because the GC replicates a subset of the full attribute set of objects from domains other than its own. You can change the AD schema to force replication of additional attributes.

When you compare the replication mechanisms used by Exchange 5.5 and the AD, you find many similarities, but there are important differences in the details of implementation. For example, the AD improves on the way the DS replicates information by implementing attribute-level replication, incorporating a multithreaded replication agent, and through the concept of high watermark vectors.

Attribute-level replication reduces the amount of data that a replication partner sends or receives after a change has occurred. The Exchange 5.5 DS replicates complete objects, even if only a single attribute is changed. This means that the DS must send between 4,000 and 6,000 bytes to each replication partner for every changed object. The AD only replicates the content of changed attributes, plus the GUID to identify the object and data to track replication. For example, if you change the display name for a user account, then the AD only sends that attribute to replication partners. The net effect is that the AD throttles back network traffic to only the size of the changed data and a buffer (perhaps 600 bytes in total, depending on the attribute that you update). In addition, the AD uses a multithreaded replication agent to be able to handle a high volume of replication requests.

To help monitor and control the flow of replication, the AD maintains a high watermark vector table on each DC. The table contains a row for every replication partner of the DC and includes the partner's highest known USN. A USN is a 64-bit number maintained by each controller to indicate how many changes have occurred on the domain controller. The AD also maintains USNs for every object in the directory and for every attribute in an object, so multiple USNs are involved in the replication process. Maintaining USNs at an attribute level allows the AD to control replication at that level rather than replicating complete objects.

As you can see in Figure 2.4, the AD tracks the changes made to an object; you can see both the USN value when the AD created the object (135,721) and the current USN (70,162,237). These USN values are specific to a DC; you will see other values if you connect to different DCs in the same domain. However, if we take the figures at face value, then this DC (part of HP's cpqcorp.net forest) processed over 70 million separate changes that it replicated to this domain controller in 33 months. Some of these changes originated on the DC, but given the size of HP's AD, the majority of changes are likely to have originated on other DCs. Another way of looking at this is that the domain controller processed nearly 71,000 changes in each of the 989 days since it originally created this object.

Figure 2.4: Active Directory USNs.

It is common to see such a heavy volume of changes in a large organization and this illustrates the replication traffic that the AD can handle, plus the wisdom of using a 64-bit number (a GUID) to hold USNs. Technically, when the number overflows because of the number of changes applied to a controller, the USN reverts to one and starts over again. This will provoke a huge amount of replication within a network, since the controller will ask its replication partners for "any change since USN 1," but you shouldn't worry too much about this situation, since it is extremely unlikely to occur in our lifetime (just like Y2K!).

2.3.2 When Active Directory replication happens

As with Exchange 5.5, the AD does not dispatch replication data immediately after changes occur. If this were to happen, updates might swamp the network if a program applied many changes over a short period. Consider what happens when you synchronize data from an external directory with the AD. Normally, synchronization processes update AD entries by applying instructions in an LDIF load file or through a direct LDAP connection to directory synchronization process using a tool such as MMS or HP's LDSU. The AD can process these instructions to add, change, or delete objects very quickly (programs have been written to add objects at well over 200 per second), and if replication were triggered after each individual update, everything would halt. Instead, the replication mechanism gathers changes together and sends out packages of replication data that its replication partners can apply. The exact method depends on whether the AD is replicating within a Windows site or between Windows sites, but in all cases the AD packages data instead of sending changes to individual objects.

Any change to the AD provokes some replication activity. The basic operations are:

• Object creation: for example, when you create a new user object, contact, or group.

• Object modification: for example, when you add a new SMTP address to a user, add a user or contact to a mail-enabled group, or if you move a user from one organizational unit to another.

• Object deletion: AD does not remove an object immediately. Instead, just as with Exchange 5.5, the AD creates a tombstone for the object and replicates this to other DCs to inform them that it has deleted the object. Tombstones have a default expiration time of 60 days, and, after this time, the AD permanently removes all trace of the object and completes the deletion by replicating the final state change.

The AD makes a distinction between two types of write operations. When you initiate an operation on a DC, the update that the AD applies to its local copy is an originating write. A replicated write is an operation that occurs as the result of incoming data that arrives from a replication partner for application to the local AD database. For example, if we increase the mailbox quota for a user on the HPDC1 DC and the AD then replicates the information to the HPDC2 DC, we refer to the update applied on HPDC2 as a replicated write.

The AD uses two internal GUIDs for each controller: one for the server itself and one for the database. The server GUID remains constant, even if the server name changes. The AD allocates a unique Server GUID to each DC and uses it to reference and identify specific DCs during replication operations.

The AD also creates a GUID to identify the copy of a database on a DC and sets it to be the same value as the server GUID. If you ever need to restore a database from a backup, the AD alters the database GUID to inform other DCs that you have restored the database and may therefore be in an inconsistent state and need to backfill and recover some previously replicated data.

2.3.3 Active Directory naming contexts

In Windows 2000, the AD organizes data into three separate naming contexts (NC). Windows 2003 introduces the application NC. A naming context is a tree of objects. In some definitions of directory terminology, a naming context represented the level of replication or referral within the directory, as follows:

• The configuration NC contains the objects that represent the structure of the directory (controllers, site topology, etc.). Because it uses the AD as its repository and stores information about its organization (connectors, servers, administrative groups, etc.) in the configuration NC, this part of the AD is very important to Exchange 2000/2003.

• The schema NC contains all the classes and attributes that define individual objects and their attributes.

• The domain NC defines all the other objects, such as users, groups, contacts, and computers. A separate domain NC exists for each domain in the forest.

Domains act as partitions within the AD. To some degree, domains also act as a replication boundary, but not for the schema, which the AD shares throughout the forest, or for the partial set of domain data that the AD replicates to GCs. Of course, if your deployment manages to use just one domain across a high-speed network, then the replication issue becomes very simple indeed and you will probably not have to worry about where you replicate data to and how long it takes to get there. On the other hand, even a single domain can run into replication issues if low-bandwidth links connect the sites and the topology is overly complex. Most corporate deployments will use multiple domains arranged into an AD forest. In these scenarios, the scope of replication becomes a very important issue, especially when you deploy an application that makes extensive use of the AD (such as Exchange) on top of the basic Windows infrastructure. For example, if AD replication does not work predictably across the forest, then the contents of the GAL will be inaccurate.

Naming contexts set boundaries for data replication. The configuration and schema are unique within a forest, which means that the AD must replicate these contexts to every DC in the forest, so they have a forest-wide scope. The AD only replicates domain objects to the controllers within a domain, so this naming context has a domain-wide scope. Besides storing the domain NC of its own domain, the AD includes a partial replica of all other domain NCs in the database held by a GC to build a complete picture across the forest. The partial replica of a domain NC contains roughly 30 percent of the data stored in the full replica of the NC, so each GC that you create incurs a replication penalty that grows with the number of domains in the forest.

Exchange exploits the fact that the GC provides a full view of the user objects in a forest to build address lists such as the GAL through LDAP filters that it applies to the copy of the AD hosted by a GC. The LDAP filter essentially "finds" every mail-enabled object known to the GC whose show-InAddressBook flag is set to true. Because its content forms the basis of the GAL, the GC is extremely important to Exchange. For example, when Outlook clients want to look up an address in the GAL, behind the scenes Exchange fetches the information from the GC and responds to the client. The Exchange Routing Engine makes heavy use of GC data, because it needs to check email addresses in message headers to decide how best to route messages.

While Exchange makes heavy use of the GC for address validation and message routing, it also needs to access configuration data for management and other operational purposes. For example, you cannot navigate through a complete view of the organization if ESM cannot read it from the data held in the Microsoft Exchange container in the configuration NC. Figure 2.5 illustrates how Exchange stores information about connectors in the configuration NC. Exchange's DSAccess component manages the interaction between Exchange and the various DCs and GCs that are available to a server.

Figure 2.5: Exchange routing information in the configuration NC.

As you can see in Figure 2.5, the AD holds Exchange configuration data in a container called "Microsoft Exchange" under the "Services" container. A separate container holds the configuration data for the Active Directory Connector, if you install this component. The structure of the Exchange configuration data is similar to the structure you see when you view the organization through ESM. When you use ESM to manage Exchange, ESM reads the configuration data from the nearest DC. Generally, the larger the Exchange organization, the slower ESM performs, because of the amount of data it fetches from the AD.

You should only work with Exchange configuration data through ESM, mostly because its user interface will protect you from making mistakes, such as deleting an essential container. Sometimes, the need might arise to eradicate completely all traces of Exchange from an AD forest, perhaps because you have made a mistake (such as using the wrong organization name) when you first installed Exchange and you want to start over. You can use the ADSIEDIT utility (see section 2.10) to remove Exchange from an organization very quickly. Simply select the "Microsoft Exchange" container, right-click, and select "Delete" from the menu. Afterward, you need to wait for replication to occur to complete the removal of Exchange from the forest. This action will not roll back the schema changes that Exchange makes to the AD, but it does mean that you can restart the deployment of a brand new organization with ForestPrep. Note that removing Exchange in this way is a very drastic option, so be sure that you have good reason to remove the organization in this manner before you proceed. The best idea is to deinstall all Exchange servers from the organization, which should remove the organization when you remove the last server. Failing this, Knowledge Base article 312878 documents the approved Microsoft method to remove an Exchange organization from AD, while article 260378 provides some useful background information.

2.3.4 Transforming DCs to GCs

You turn DCs into GCs by changing the server's NTDS Settings property through the Active Directory Sites and Services console. Navigate to the site that holds the server, select the server, and view its NTDS Settings properties, as shown in Figure 2.6. Check the "Global Catalog" box to make the controller start to pull information from other domains. If you clear the checkbox, the server will revert to a DC and the AD will flush data from other domains from the local database. This process may not happen quickly, because it depends on the number of objects from other domains that exist in the local database. The KCC removes these objects every time it runs and spreads the load by deleting about 8,000 objects an hour. It is, therefore, obvious that it can take some days before a DC finally purges data for other domains from its database and, during this time, you cannot reverse the process and make the DC a GC again. In large forests, it may be faster to remove the DC, reinstall the server from scratch, and then reload the AD from media-but only if you run Windows 2003!

Figure 2.6: Setting the Global Catalog property for a DC.

As discussed earlier, changing a DC to a GC obviously generates replication activity. If you add a second GC to a site, the new GC always copies the partial replicas of other domain NCs from the existing GC. This avoids the need to broadcast replication requests outside the site boundary and thus potentially generate a flood of replication data within the forest. Otherwise, the exact impact on a network and Windows infrastructure depends on the complexity of the site topology, the number of domains in the forest, and the number of controllers involved in the replication process. Another point to consider is that changing a Windows 2000 controller to a GC updates the way that MAPI clients access the server through NSPI, and you have to reboot the server before clients can use it as a GC.

There is no good answer to how quickly the AD can replicate data from one part of a forest to another. Microsoft recommends using tools such as the Performance Monitor to review the performance of the NTDS Objects (such as DRA Outward Bytes Total and DRA Inward Bytes Total, or the total bytes consumed in outward and inward replication activity). However, this is a rudimentary approach to the problem, and it is better to use the more sophisticated tools from companies such as NetIQ, Quest, or NetPro. In addition, to help gain an insight into potential problem areas for replication between sites and controllers, system integrators such as HP develop tools such as ADlatency and the OpenView Active Directory replication monitor to measure end-to-end replication latency and the overall effectiveness of replication inside a forest.

Exchange's dependency on GC availability and AD replication in general illustrates the point that unlike Windows NT domain designs, you cannot approach a design exercise for the AD in isolation from the applications that will use the infrastructure. This is a major and far-reaching change for any company that traditionally keeps infrastructure design teams separated from application design teams. It is common to find design teams that only focus on a specific part of the infrastructure and never consult anyone outside their immediate sphere of influence. The close and almost intimate dependency of Exchange 2000/2003 on the AD means that successful design teams treat the infrastructure as a whole rather than as separate parts. It is worth noting that while Exchange has a tremendous dependency on proper AD deployment and operation, you also have to manage other Windows and network components to bring everything together. For example, if you do not deploy DNS properly, DSAccess may not be able to locate DCs and GCs to fetch configuration and recipient information.

2.3.5 USNs and replication

As mentioned earlier, the AD uses USNs to track changes made to its objects. This is a variation of the mechanism used in Exchange 5.5 DS, which also uses USNs to track changes. The major difference between the two directories is that USNs are stored on a per-attribute basis to allow attribute-level replication to work. As with Exchange 5.5, there are two different USNs maintained for each object. The DC sets the value of the USNCreated attribute for a new object to the value of the server USN when it creates the object and then updates the USNChanged attribute each time it processes an update for the object. In this case, the AD sets the value of USNChanged to the current value of the server USN where the originating write occurs. You can see the value of a server USN by examining server properties, as shown in Figure 2.7. Now that we know the basics, we can track what happens during a simple set of replication operations.

Figure 2.7: Server USN.

This scenario uses two controllers in a domain called HPDC1 and HPDC2. The servers have been in operation for some time, so the values of the server USNs reflect the number of AD updates. For this example, we assume that HPDC1 begins with USN 10,925 and HPDC2 starts with 11,933.

We begin replication by creating a new user object on HPDC1. The AD automatically allocates the next USN in sequence based on the server USN, or 10,926. Note that the allocation of a USN is a one-time operation and the USN can never be reused, even if the create operation is interrupted and fails to complete. The next update on HPDC1 increases the USN by one. Table 2.1 lists a subset of the values maintained in the user object table in the database on HPDC1.

Table 2.1: User Table in Active Directory (1)

Attribute	Value	USN	Version	Timestamp	Originating DC GUID	Originating USN
First name	John	10,926	1	200208311245	HPDC1 GUID	10,926
Surname	Doe	10,926	1	200208311245	HPDC1 GUID	10,926
Mailbox server	HPDC1	10,926	1	200208311245	HPDC1 GUID	10,926
SMTP address	[e-mail]	10,926	1	200208311245	HPDC1 GUID	10,926

The following extract illustrates a number of important points:

• The DC automatically adds a number of values to each attribute to control replication.

• Each attribute populated as the AD creates the new user object receives the USN allocated to the object. The "Originating" USN is set to the same value, because the operation is initiated on the local server. This value will change as the AD updates attributes.

• The AD populates the "Originating DC GUID" with the GUID from the server where it creates the object. Again, this value can change if another DC updates an attribute.

• The version number is set to 1, because the DC has just created the object. This number is incremented as updates are applied. The AD uses the version number to resolve replication conflicts that might occur if two or more controllers attempt to update the same attribute at roughly the same time. Conflicts are resolved by accepting the update with the highest version number. This is especially important when resolving conflicts for multivalued attributes (such as groups)- for example, if you make two changes to a group on one DC that overwrites a single change made to the same group on another DC later on.

• A timestamp (stored as a quadword) taken from the current date and time on the server is saved. The AD uses timestamps as a last resort to resolve replication conflicts that might occur if two or more controllers attempt to update the same attribute at roughly the same time and end up with a version number that is the same. Conflicts are resolved by accepting the last update according to the timestamps, using the timestamp from the originating write to arbitrate the conflict.

Note also that the AD assigns the new object the current value of the server USN (10,926) in its USNCreated and USNChanged attributes. We now replicate the information to HPDC2, which inserts the new information into its copy of the directory. Table 2.2 shows the values from HPDC2.

Table 2.2: User Table in Active Directory (2)

Attribute	Value	USN	Version	Timestamp	Originating DC GUID	Originating USN
First name	John	11,934	1	200208311247	HPDC1 GUID	10,926
Surname	Doe	11,934	1	200208311247	HPDC1 GUID	10,926
Mailbox server	HPDC1	11,934	1	200208311247	HPDC1 GUID	10,926
SMTP address	[e-mail]	11,934	1	200208311247	HPDC1 GUID	10,926

The AD changes the USN to reflect the server USN on HPDC2. The AD also assigns this value (11,934) to the USNChanged attribute, because this is the initial creation of the object on this controller. The timestamp now contains the date and time when HPDC2 applied the update. The originating DC GUID and the originating USN are still the values from HPDC1, because this is the controller where the update originated. We now see the difference between an originating write and a replicated write.

Table 2.3 demonstrates what happens after you update the user's title on HPDC2. We populate a previously blank attribute, which forces the USN on HPDC2 to move to 11,935. The AD also updates the USNChanged value to 11,935. The AD then sets the originating DC GUID for this attribute to HPDC2, because the update originates from this controller, so the AD also updates the originating USN to the USN from HPDC2. Eventually, replication will occur back to HPDC1, which results in the values shown in Table 2.4. The timestamp is set to the value of the originating write.

Table 2.3: User Table in Active Directory (3)

Attribute	Value	USN	Version	Timestamp	Originating DC GUID	Originating USN
First name	John	11,934	1	200208311245	HPDC1 GUID	10,926
Surname	Doe	11,934	1	200208311245	HPDC1 GUID	10,926
Mailbox server	HPDC1	11,934	1	200208311245	HPDC1 GUID	10,926
Title	Consultant	11,935	1	200208311255	HPDC2 GUID	11,935
SMTP address	[e-mail]	11,934	1	200208311245	HPDC1 GUID	10,926

Table 2.4: User Table in Active Directory (4)

Attribute	Value	USN	Version	Timestamp	Originating DC GUID	Originating USN
First name	John	10,926	1	200208311245	HPDC1 GUID	10,926
Surname	Doe	10,926	1	200208311245	HPDC1 GUID	10,926
Mailbox server	HPDC1	10,926	1	200208311245	HPDC1 GUID	10,926
Title	Consultant	10,927	1	200208311255	HPDC2 GUID	11,935
SMTP address	[e-mail]	10,926	1	200208311245	HPDC1 GUID	10,926

The important things here are that the USN has been incremented according to the server USN for HPDC1, but because the write originated on HPDC2, the AD takes its server GUID and USN and uses them to update the database on HPDC1. The AD also updates the timestamp. However, the AD leaves the USNCreated value for the object unaltered at 10,926 but updates the USNChanged value to 10,927. Note that the AD leaves all the other attributes alone, since it only needs to update the value of the Title attribute.

While it may seem obvious to keep track of the controller that last updated an attribute by holding the server GUID, the role of the originating USN might be more obscure. The way that the AD uses the originating USN becomes more important as you increase the number of DCs that participate in replication. In fact, the AD uses the originating USN for propagation dampening, or the ability to stop replication operations from progressing if the AD has already updated the local database after an interchange of replication data with another controller. Propagation dampening is very important in large networks, since it eliminates unnecessary traffic and reduces the amount of system resources that are required to keep the directory in a consistent state.

2.3.6 Urgent replication

The normal replication process is sufficient to ensure that the AD replicates updates to attributes, such as telephone numbers, titles, or even email addresses between DCs, reasonably quickly. Two situations exist when fast replication is required. These are when a user account is locked out and when a new set of identifiers is issued by the RID master.

AD supports the concept of "forced" replication to get updates to domain controllers as quickly as possible after you lock out or disable accounts. This feature exists to prevent users from moving between domain controllers and logging in after an administrator has disabled or locked their accounts. If AD depended on normal replication in these instances, the danger exists that the newly locked out user could still authenticate against a controller that has not yet received the update and so continue to access resources. You should realize that this mechanism does not prevent users who previously logged on to the network from accessing the resources until their Kerberos ticket lifetime expires. In case of NTLM authentication, the users can continue to access resources until they log off.

Note that AD does not consider password updates as urgent. When you update your password, the controller that you make the change with replicates the new password to the PDC emulator master, which then replicates the updated password to other domain controllers in the next replication cycle. Note that the site topology might prevent a controller from communicating with the PDC emulator, but normal intersite replication will eventually get the change through.

Finally, if the RID master issues a new set of identifiers to a DC to allow it to generate unique identifiers for new accounts, the AD must send that information quickly to its destination. In all these cases, fast replication or rather a faster form of replication is performed by immediately sending out change notifications to replication partners, which then respond by pulling the update from the originating controller.

2.3.7 Intra-and intersite replication

Exchange 4.0 introduced the concept of a site to reflect locality in terms of network connectivity. The AD also uses the concept of a site but with some subtle differences. An Exchange site is a collection of servers that share good network connectivity, often because all the servers in the site are in a common location (office, city, country, or even continent). The definition of a Windows site is somewhat stricter. A Windows site is composed of a collection of one or more IP subnets, but, as with an Exchange site, a Windows site usually shares good bandwidth between the servers-preferably at least 256 KB.

In logical terms, as shown in Figure 2.8, a Windows infrastructure builds sites on top of the physical network, and sites map the physical network to create the AD site topology. Another way of thinking about this is to remember that sites are collections of servers in a location, whereas domains are collections of objects that may exist across multiple sites. In actuality, when you deploy your first Windows domain, it goes into the default site (called "default-first-site"). New DCs that join the domain also go into the same site unless you decide to create other sites to accommodate the requirements of the network. You introduce a domain into a site by creating a replica (DC) for the domain in the site. A domain may span many sites, and a site can host multiple domains as long as a DC for each domain is present in the site.

Figure 2.8: Windows domains, sites, and the network.

Windows limits domain NC replication to synchronous RPCs. This means that you can only include servers in a domain if they can establish RPC connectivity with the other servers in the domain. The connection is not limited to a LAN, but within a WAN you find that RPCs are sensitive to latency and network availability and may time out or otherwise fail to complete. The requirement to support RPC connectivity means that some designs use domains to restrict replication and end up with more domains than strictly necessary. The AD can replicate the configuration and schema NCs through asynchronous SMTP messages, so replication can truly span the world. In this case, the AD uses the Windows SMTP service to send the messages containing replication data.

When you first create the forest, Windows creates a default site link. You cannot create a site without associating it with at least one site link, so you can either use the default link or create a new one. Site links connect together to allow replication to proceed. The existence of a site link indicates that network connectivity is available between the two sites. Unlike the automatic connection objects created by Windows to replicate data between two partners in a specific NC, you must create site links before intersite replication can proceed.

The Knowledge Consistency Checker (KCC) manages the creation of the intrasite topology and works with the Intersite Topology Generator (ISTG, a subprocess of the KCC) to ensure that Windows optimizes AD replication. The KCC is a service that runs on every DC to generate and optimize the AD replication topology by creating connection agreements between DCs. Costs range from 1 to 32,767, with 100 being the default. In general, the lower the cost, the better the network connectivity that exists between sites. Because they link sites, which are IP subnets, you can think of site links as WAN connections. Each site link has a cost, and the ISTG uses the cost and site link schedule to determine which connection objects it must create to enable replication. The connection objects created by ISTG to link the different sites form a spanning tree, designed to avoid message looping, since updates flow between bridgehead servers in the sites. This is important with asynchronous replication, where messages that contain replication data may take some time to reach their final destination. Administrators can also create connection objects, but the usual approach is to let the ISTG create a default set and only interfere if necessary afterward.

Because good network connectivity is assumed, directory replication occurs automatically and frequently inside and between sites. Replication partners notify each other when they have updates, and the partners then pull the data from the originating server to update their directories. Even if no updates exist for replication, the DCs in a site exchange details of their latest USNs to update their vector tables and ensure that they miss no data. The AD uses the same pull mechanism for intersite replication. In this case, bridgehead servers hold data until their replication partners (bridgehead servers in other sites) request updates and then pull the data.

Because the AD assumes good connectivity exists between servers in a site, it never compresses replication data and uses RPCs to communicate between servers. By default, two DCs in a site replicate every five minutes. If more than three DCs exist in the same site, the KCC will set up the replication connections to ensure that changes from any DC within the site reach all other DCs within three hops. That is, any changes replicate to all DCs within 15 minutes. On the other hand, the AD always performs intersite replication according to a schedule, which allows administrators to distribute changes when they feel appropriate. If replication data is over 50 KB, the AD compresses it to between 10 percent to 15 percent of its original size before transmission, trading network consumption against the processing to compress and decompress the data.

The AD can replicate synchronously or asynchronously between sites. Synchronous replication occurs between two bridgehead servers within the same NC. The bridgehead server acknowledges receiving the data and then distributes it to other DCs in the site. Synchronous replication can only happen over a reliable and relatively high-speed connection. Asynchronous replication allows replication to occur over slow or unreliable links by sending SMTP messages using a component called Intersite Messaging (ISMSMTP). ISM generates messages containing replication data and sends them through the basic SMTP service included in every Windows. However, you cannot replicate the domain NC over SMTP, and the experience gained in enterprise deployments demonstrates that few if any large companies use SMTP replication with the AD. Because AD replication is so important, most large companies deploy DCs within the high-speed core parts of their networks to ensure that replication works predictably. The reduced cost of network seen since Microsoft introduced Windows 2000 has also reduced the attractiveness of asynchronous replication, so to some degree you can consider this a feature that may help in very specific circumstances (AD deployments over extended low-speed networks), but one that has hardly been proved in practice. Table 2.5 summarizes the differences between intra-and intersite replication for the AD.

Table 2.5: Characteristics of Active Directory Replication

	Intrasite	Intersite
Transport	RPC	RPC or SMTP
Topology	Ring	Spanning tree
Replication Timing	Automatic when necessary (every five minutes by default)	According to schedule as defined by administrator
Replication Model	Notify and pull	Store and forward
Compression	None	Full (if over 50 KB)

Within a site, Windows sets the default schedule for DCs to send notifications of updates to their replication partners to 300 seconds (five minutes). You can change this interval for all members of a site, but there is little reason to do this normally unless you want to tune back the amount of replication traffic that the AD generates. One exception to the rule is when you want to send changes to the bridgehead server in the site so that it begins to replicate with its partner sites as soon as possible. This technique can propagate changes faster within a distributed AD, but you need to test and measure results before committing it to deployment.

Each site link and connection object has a schedule (Figure 2.9), which defines when the DCs associated with the connection object will replicate. Each time a replication slot occurs in the schedule, the DCs inside the site exchange information with each other to establish whether they need to replicate. The site link schedule takes precedence over the connection object schedule for intrasite replication. By default, site link schedules replicate every 180 minutes, so the bridgehead servers will "wake up" and attempt to replicate every three hours, which is usually enough to keep the directory up-to-date.

Figure 2.9: Connection object schedule.

2.3.8 High watermark vector tables and up-to-date vector tables

The AD incorporates a number of propagation dampening mechanisms to control the amount of replication within the network. Propagation dampening means that a DC can suppress or ignore unnecessary replication under specific circumstances. In other words, if a DC receives information that it already knows, such as a request to create a new user object in its copy of the AD, the DC can discard the update. Elimination of unnecessary replication activities becomes more important as the number of controllers increases. Duplicating some work between two controllers is probably unimportant, but involving 100 or 200 controllers in a replication mechanism that generates "n" unnecessary activities per replication partner is a recipe for disaster.

Windows uses two tables to control propagation: the high watermark vector table and the up-to-date vector table (also sometimes called the state vector table) and maintains the two tables on every DC. The contents of the tables represent the current state of replication known to an individual DC.

The AD increments the controller USN as it performs each change, no matter whether it is to add, update, or delete an object. It then stores the USN with the object and any updated attributes. Increments also happen for unsuccessful operations, such as the failure to create a user account.

The high watermark vector table tracks the highest known USN from each replication partner. This information allows a DC to know whether it needs to request additional information from a replication partner to backfill data that may be missing, perhaps because of a failure to replicate properly in the past. The AD uses the high watermark vector table to detect recent changes on a replication partner. If a DC has not received a recent update from a replication partner, it broadcasts its highest known USN to the partner. The receiving DC can then verify this data against its own high watermark vector table to discover whether any outstanding replication exists. If this is true, the DC can then request the information from a replication partner.

Knowing the USN from a replication partner also allows a controller to request precisely the data required to update its own directory without having to request "all changes." For example, if the highest known USN on controller DC20 is 17,754, and a replication notification arrives from DC20 saying that its current USN is 17,794, then the receiving controller knows that it still has to apply 40 updates to its copy of the directory and is able to issue a request to DC20 to provide the missing information.

The up-to-date vector table maintains a list of all replication partners and the highest originating write on each. When Windows has fully synchronized all of the controllers in a domain, the up-to-date vector table is the same everywhere. Each DC sends its up-to-date vector table to its replication partners as part of the replication cycle. The replication partner matches the USN in the up-to-date vector table with its high watermark vector table to identify any missing data. If the replication partner finds that some replication operations are outstanding, it will request updates. Otherwise, if the replication partner has already received the data-through replication with another DC-it makes no further attempt to replicate because of propagation dampening.

Within a small domain, these tables are not very important. However, their importance grows in line with the number of DCs. Each DC is likely to have a set of different replication partners, so replication data can flow along many different paths. If no mechanisms were in place to stop unnecessary replication, a DC might process updates multiple times after it contacts different replication partners, all of which want to provide the DC with the same information.

2.3.9 AD replication changes in Windows 2003

Windows 2003 introduces many AD upgrades, enhancements, and fixes. With respect to replication, the following are the most important changes:

• You can now promote a Windows 2003 server to become a domain controller using a copy of the AD on removable media. This makes it much easier to deploy controllers in a large network, because it removes the replication load necessary for the AD to populate a database on a new DC. For example, within HP's forest, network-based replication could take between three and five days to complete to promote a new controller. With load from media, a new controller is online within an hour.

• The AD is better at cleaning up "lingering" objects (ones that do not disappear completely in all controllers after the replication process completes) that remain in the database after deletion.

• Intersite replication is more efficient and consumes less bandwidth.

• The overall size of the AD database is usually smaller, because the database engine is more efficient and uses mechanisms such as single-instance storage of security descriptors. For example, when HP moved its Windows forest into native Windows 2003 mode, the DIT file shrank from 12 GB to 7.5 GB.

• GCs do not commence a full synchronization when you add new attributes to the partial attribute set in the AD schema. Large forests feel the effect of this change most, because of the number of controllers that participate in replication. Whereas changes to the partial attribute set in Windows 2000 might create a replication storm over five days before all of the GCs have a fully populated database, now you can assume that replication completes in under a day-assuming no network outages.

• Last logon timestamps are replicated.

• ITSG makes better decisions about the site connections that it creates.

• The AD now supports per-value replication for multivalue attributes. This is very important for groups (and Exchange makes extensive use of distribution groups) that hold group membership in a single multivalue attribute. Therefore, any change to group membership used to force the AD to replicate the complete membership now just replicates the changed value.

Administrators have gained a great deal of experience from managing directory replication for Exchange that they can apply to the AD. In particular, we know that it is easy to swamp a network with unnecessary and unwanted traffic if you allow directory information to replicate too frequently, and the same type of planning has to go into the AD. One immediate difference is that the AD replicates time-critical information, such as account disabling, as fast as reasonably possible.

While the AD is a critical component of successful Windows infrastructures, it is not the only component to manage. File Replication Services (FRS), which replicates SYSVOL and policies, are also a dependency for many applications. For example, if FRS replication is not working properly, the changes to server security policies applied by the Exchange installation program will not replicate from the server that you perform the installation on to other servers in the domain. One side effect of this failure is that you may be able to start the set of Exchange services on other servers, but you will not be able to mount the Store databases, because the services will not possess the necessary privileges!

---