Logon Request Validation Process

A workstation logon request is validated more or less efficiently, depending on whether the request is validated by a local domain controller, or one outside the site. Put another way, the user logon request is most efficiently validated by the domain controller closest to it.

When the local domain controller initiates replication for a naming context with one of its partners, the highest USN for that partner from the domain controller's highwatermark vector for the naming context is one of the pieces of information sent to the replication partner. The replication partner compares that value with its current highest USN for the naming context to help determine what changes should be sent to the domain controller. This logic is further refined by the up-to-dateness vector, as described in the next section.

The (UTDV) up-to-dateness vector is a table maintained independently by every domain controller to assist in efficient replication of a naming context. Specifically, it is used for replication dampening to reduce needless replication traffic and endless replication loops.
There is one table for every naming context the domain controller maintains a replica of, at a minimum, every domain controller will have at least three of these tables. Each table stores the highest originating update USN the domain controller has received from every other domain controller that has ever existed in the forest, as well as the date/time at which the domain controller last successfully completed a replication cycle with the given replication partner and naming context.
The up-to-dateness vector is used in conjunction with the high-watermark vector to reduce replication traffic. When the replication request for a naming context is passed to the replication partner, the destination domain controller's up-to-dateness vector for the naming context is also in the request. The source partner can then zero in on changes that it has not previously sent and then further filter out any changes that the destination may have already received from other replication partners. In this way, it guarantees that a single change is not replicated to the same domain controller multiple times; this is called propagation dampening.

The writable domain controller that the RODC contacts must be running Windows Server 2008 or newer. If only Windows Server 2003 domain controllers are available, the logon request will fail.
Windows Server 2008 introduced the ability to start and stop Active Directory like a normal Windows service.
This allows you to perform most offline operations without restarting the domain controller. While Active Directory is stopped, it will not respond to logon requests. If the domain controller is hosting Active Directory (integrated DNS zones), it will also not respond to queries for these zones. While the Active Directory service is stopped, you can perform all of the offline tasks outlined in this chapter with the exception of restoring from a backup. Restoring still requires that you boot into Directory Services Restore Mode.
Once you have stopped the Active Directory service, you can log into the domain controller with domain credentials if another domain controller is available to service the request. If another domain controller is not available to service the request, you will not be able to log in. If you want to have the option of using the Directory Services Restore Mode password, you must modify the registry.