Active Directory

Managing replication

Replication makes it possible for changes that are made on one AD DS domain controller to be replicated to other domain controllers in the domain and, in some cases, to other domain controllers in the forest. Rather than replicating the AD DS database in its entirety, the replication process is made more efficient by splitting the database into logical partitions. Replication occurs at the partition level, with some partitions only replicating to domain controllers within the local domain, some partitions replicating only to enrolled domain controllers, and some partitions replicating to all domain controllers in the forest. AD DS includes the following default partitions:

• Configuration partition This partition stores forest-wide AD DS structure information, including domain, site, and domain controller location data. The configuration partition also holds information about DHCP server authorization and Active Directory Certificate Services certificate templates. The configuration partition replicates to all domain controllers in the forest.

• Schema partition The schema partition stores definitions of all objects and attributes as well as the rules for creating and manipulating those objects. There is a default set of classes and attributes that cannot be changed, but it’s possible to extend the schema and add new attributes and classes. Only the domain controller that holds the Schema Master FSMO role is able to extend the schema. The schema partition replicates to all domain controllers in the forest.

• Domain partition The domain partition holds information about domain-specific objects such as organizational units, domain-related settings, user, group, and computer accounts. A new domain partition is created each time you add a new domain to the forest. The domain partition replicates to all domain controllers in a domain. All objects in every domain partition are stored in the Global Catalog, but these objects are stored only with some, not all, of their attribute values.

• Application partition Application partitions store application-specific information for applications that store information in AD DS. There can be multiple application partitions, each of which is used by different applications. You can configure application partitions so that they replicate only to some domain controllers in a forest. For example, you can create specific application partitions to be used for DNS replication so that DNS zones replicate to some, but not all, domain controllers in the forest.

Active Directory supports attribute-level replication. Rather than replicate the entire object when a change is made to an attribute on that object, such as when group membership changes for a user account, only the attribute that changes is replicated to other domain controllers. Attribute-level replication substantially reduces the amount of data that needs to be transmitted when objects stored in AD DS are modified.

Understanding multimaster replication

AD DS uses multimaster replication. This means that any writable domain controller is able to make modifications to the AD DS database and to have those modifications propagate to the other domain controllers in the domain. Domain controllers use pull replication to acquire changes from other domain controllers. A domain controller may pull changes after being notified by replication partners that changes are available. A domain controller notifies its first replication partner that a change has occurred within 15 seconds and additional replication partners every 3 seconds after the previous notification. Domain controllers also periodically poll replication partners to determine whether changes are available so that those changes can be pulled and applied to the local copy of the relevant partition. By default, polling occurs once every 60 minutes. You can alter this schedule by editing the properties of the connection object in the Active Directory Sites And Services console.

Knowledge Consistency Checker (KCC)

The Knowledge Consistency Checker (KCC) runs on each domain controller. The KCC is responsible for creating and optimizing the replication paths between domain controllers located at a specific site. In the event that a domain controller is added or removed from a site, the KCC automatically reconfigures the site’s replication topology. The KCC topology organization process occurs every 15 minutes by default. Although you can change this value by editing the registry, you can also trigger an update using the repadmin command-line tool with the KCC switch.

Store and forward replication

AD DS supports store-and-forward replication. For example, the Canberra and Melbourne branch offices are enrolled in a custom application partition. These branch offices aren’t connected, but they are connected to the Sydney head office. In this case, changes made to objects stored in the application partition at Canberra can be pulled by the domain controller in Sydney. The Melbourne domain controller can then pull those changes from the domain controller in Sydney, as shown in Figure 4-19.

Figure 4-19 An example of store-and-forward replication

Conflict resolution

In an environment that supports multimaster replication, updates may be made to the same object at the same time in two or more different places. Active Directory includes sophisticated technologies that minimize the chance that these conflicts will cause problems, even when conflicting updates occur in locations that are distant from each other.

Each domain controller tracks updates by using update sequence numbers (USNs). Each time a domain controller updates, either by processing an update performed locally or by processing an update acquired through replication, it increments the USN and associates the new value with the update. USNs are unique to each domain controller, as each domain controller processes a different number of updates to every other domain controller.

When this happens, the domain controller that wrote the most recent change, known as the last writer, wins. Because each domain controller’s clock might not be precisely synchronized with every other domain controller’s clock, the last write isn’t simply determined by a comparison of time stamps. Similarly, because USNs are unique to each domain controller, a direct comparison of USNs is not made. Instead, the conflict resolution algorithm looks at the attribute version number. This is a number that indicates how many times the attribute has changed and is calculated using USNs. When the same attribute has been changed on different domain controllers, the attribute with the higher attribute version number wins. If the attribute version number is the same, the attribute modification time stamps are compared, with the most recent change being deemed authoritative.

If you add or move an object to a container that was deleted on another domain controller at the same time, the object is moved to the LostAndFound container. You can view this container when you enable the Advanced Features option in the Active Directory Users and Computers console.

RODC replication

The key difference between an RODC and a writable domain controller is that RODCs aren’t able to update the Active Directory database, and they only host password information for a subset of security principals. When a client in a site that only has RODCs needs to make a change to the Active Directory database, that change is forwarded to a writable domain controller in another site. When considering replication, remember that all RODC-related replication is incoming and that other domain controllers do not pull updates from the AD DS database hosted on an RODC.

RODCs use the usual replication schedule to pull updates from writable domain controllers, except in certain cases, RODCs perform inbound replication using a replicate-single-object (RSO) operation. These cases include

• The password of a user whose account password is stored on the RODC is changed.

• A DNS record update occurs where the DNS client performing the update attempts to use the RODC to process the update and is then redirected by the RODC to a writable DC that hosts the appropriate Active Directory Integrated DNS zone.

• Client attributes, including client name, DnsHostName, OsName, OsVersionInfo, supported encryption types, and LastLogonTimeStamp, are updated.

These updates occur outside the usual replication schedule because they involve objects and attributes that are important to security. An example is when a user at a site that uses RODCs calls the service desk to have their password reset. The service desk staff member, located in another site, resets the password using a writable domain controller. If a special RSO operation isn’t performed, it’s necessary to wait for the change to replicate to the site before the user is able to sign on with the newly reset password.

Monitor and manage replication

You can use the Active Directory Sites And Services console to trigger replication. You can trigger replication on a specific domain controller by right-clicking the connection object and selecting Replicate Now. When you do this, the domain controller replicates with all of its replication partners.

You can also monitor replication as it occurs using DirectoryServices performance counters in Performance Monitor. Through Performance Monitor, you can view inbound and outbound replication, including the number of inbound objects in the queue and pending synchronizations.

Repadmin

You can use the repadmin command-line tool to manage and monitor replication. This tool is especially useful at enabling you to diagnose where there are problems in a replication topology. For example, you can use repadmin with the following switches:

• replsummary Generates information showing when replication between partners has failed. You can also use this switch to view information about the largest interval between replication events.

• showrepl Views specific inbound replication traffic, including objects that were replicated and the date stamps associated with that traffic.

• prp Determines which user account passwords are being stored on an RODC.

• kcc Forces the KCC to recalculate a domain controller’s inbound replication topology.

• queue Enables you to display inbound replication requests that a domain controller must make to reach a state of convergence with source replication partners.

• replicate Forces replication of a specific directory partition to a specific destination domain controller.

• replsingleobj Use this switch when you need to replicate a single object between two domain controllers.

• rodcpwdrepl Enables you to populate RODCs with the passwords of specific users.

• showutdvec Displays the highest USN value recorded for committed replication operations on a specific DC.