Overview of Change Tracking Techniques

There are several dimensions on which mechanisms for tracking changes can differ:

• Scope for tracking changes. An application might want to track changes to a single attribute of a single object, to all objects in a domain, or something in between. If the mechanism matches an application's needs, the application will receive a minimum of irrelevant information, enhancing overall performance.
• Timeliness. An application might want to see every change as it happens, or might be content to see the net effect of changes that have accumulated over a period of minutes or hours.

  Processing less timely data may be more efficient, because several changes may be collapsed into one. For instance, if an attribute changes three times within a one hour interval, an application that is satisfied with changes that have accumulated over an hour will see just one attribute change, not three.

  When thinking about timeliness it is important to consider the effect of replication latency. An update that originates on one domain controller does not replicate to another domain controller instantly. Requiring change-tracking timeliness much better than the expected replication latency often gives no real benefit to the application.

• Polling versus notification. With polling an application periodically makes a request to a domain controller to receive change tracking information. With notification the domain controller sends changes to the application only when changes have happened.

  The overhead of polling is obvious: The application may request change tracking information when nothing of interest has changed. The overhead of notification is more subtle. The server must maintain information about notification requests and must consult this information to decide whether or not to send a notification. This can add overhead to normal update requests. In effect, normal updates pay some of the price of notifications.

• Expressing the application's knowledge: persistent versus ephemeral. Every change tracking mechanism must include some method for the server holding the information being tracked to understand the application's state of knowledge, so that the idea of "change" is well defined. For instance, the application's state of knowledge might be expressed as "I am fully up to date with all changes that took place on DC d before time t." A mechanism based on this way of expressing an application's state of knowledge would provide an efficient way for the application to obtain changes that have occurred later than a specified time.

  If the expression of the application's knowledge can be persisted (that is, stored recoverably, as in a file or database), application restart is less expensive and simpler than if it cannot. In the example above, the expression of the application's knowledge can be persisted by recording the DC d and the time t. Some change notification mechanisms don't allow this information to be persisted. The server and application must synchronize with some other mechanism when the application starts. This is expensive if many objects are involved, and can involve complicated programming.

You can use the following techniques to track changes in Active Directory.

• Use the change notification control to initiate a persistent asynchronous search for changes that match a specified filter. See Change Notifications in Active Directory.
• Use a directory synchronization (DirSync) search to retrieve changes that have occurred since the previous DirSync search. See Polling for Changes Using the DirSync Control.
• Use the USNChanged attribute to search for objects that have changed since the previous search. See Polling for Changes Using USNChanged.

The change notification control is designed for programs or services that want reasonably prompt notification of infrequent changes. An example is a service or program that stores configuration information in Active Directory™ and wants to be notified promptly when a change occurs. Note that there are limitations of the notification control.

• The promptness of notifications depends on replication latency and where the change was made. You may be notified promptly when a change replicates into the replica you are monitoring. But the change may have originated much earlier on some other replica.
• The control is restricted to monitoring a single object or the immediate children of a container. Applications that need to monitor multiple containers or unrelated objects can register up to five notification requests.
• If too many clients are listening for changes that occur frequently, it will impact the performance of the server. In general, applications should limit their use of this control for performance reasons on the server. If you don't need to know about changes immediately, it may be best to periodically poll for changes instead of using change notification.

The DirSync and USNChanged search techniques are designed for applications that maintain consistency between data in Active Directory™ and corresponding data in some other storage. These techniques are used by applications that periodically poll for changes. The DirSync technique is based on an LDAP server control that you can use through ADSI or LDAP APIs. The disadvantages of the DirSync control are that it can only be used by a highly privileged account, such as a domain administrator

• The DirSync control can only be used by a highly-privileged account, such as a domain administrator.
• The DirSync control can only monitor an entire naming context. You cannot limit the scope of a DirSync search to monitor only a specific subtree, container, or object in a naming context.

The USNChanged technique does not have these limitations, although it is somewhat more complicated to use than DirSync.