There are several ways that change tracking mechanisms can differ:
Processing less timely data may be more efficient, because several changes may be collapsed into one. For example, if an attribute changes three times within a one hour interval, an application notified of changes accumulated over an hour will be notified of just one attribute change, not three.
When thinking about timeliness, 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.
The overhead of polling is obvious: The application may request change tracking data when nothing significant has occurred. The overhead of notification is more subtle. The server must maintain data about notification requests and must consult this data to decide whether or not to send a notification. This can add overhead to normal update requests.
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 resource intensive 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 do not allow this data to be persisted. The server and application must synchronize with some other mechanism when the application starts. This is resource-intensive if multiple objects are involved, and can involve complex programming.
Use the following techniques to track changes in Active Directory:
The change notification control is designed for applications or services that require reasonably prompt notification of infrequent changes. An example is a service or program that stores configuration data in Active Directory® and must be notified promptly when a change occurs. Be aware that there are limitations of the notification control.
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 following is a list of limitations of DirSync control:
The USNChanged technique does not have these limitations, although it is somewhat more complicated to use than DirSync.