Use this Knowledge Script to monitor Active Directory replication latency. Replication latency represents the amount of time a change made to an Active Directory partition takes to be reflected on another domain controller.
Replication latency is a significant metric in most typical service level agreements (SLAs) for Active Directory. To end-users, replication latency represents the maximum amount of time they have to wait after the Help Desk makes a requested change, such as a password reset. For example, an IT organization might want new user accounts or password resets to take effect a maximum of 30 minutes after the service-desk personnel initiate the change. This script can help you measure such service-level goals, despite the challenge of measuring replication latency through all the paths it can take.
For an environment with fewer than 30 domain controllers, you can allow this script to periodically inject a small change in the Active Directory partitions representing every DC and measure how long it takes to replicate that change to other DCs. For environments with thousands of DCs, this script allows even these large Active Directory topologies to get replication latency data with virtually no data overhead. For more information, see Section 3.41.4, Examples of How this Script Is Used: Example 1.
This script measures the time it takes to replicate a change from Point A to Point B and compares that amount of time to the thresholds you set. Changes are injected to the replication object by updating an object property. You can set parameters to determine where to store this data, what user authentication credentials to use, and how often to inject changes to check latency.
The script defines two roles: the Injector, which makes the change, and the Monitor, which waits for the replication data to arrive. A single domain controller can be both an Injector and a Monitor, but if you define one DC as an Injector, you need to run this script on a second DC and designate it as the Monitor. The script injects a very tiny change to one object in a location you select. Every script interval, the script checks the selected folder and computes latency by reading every object and doing the following calculation:
Latency = Arrival time - Injection time
Based on the thresholds you set, this script raises an event based on the result of this calculation.
Injection frequency is determined by both the schedule and the value you set for the Change injection frequency parameter. For example, if this script runs every 17 minutes and the Change injection frequency is 24, a change is injected every 408 minutes (or every 24 job iterations).
If you choose to collect data, make sure you enable the appropriate Collect data for... parameter on a computer serving in the Monitor role or serving as both Injector and Monitor.
Active Directory domain controller.
The default interval for this script is Daily schedule, Every 17 minutes.
Set the following parameters as needed:
|
Parameter |
How to Set It |
|---|---|
|
General Settings |
|
|
Raise event if job fails |
|
|
Event severity when job fails |
Set the severity level, from 1 to 40, to indicate the importance of an event in which the ReplicationLatency job fails. The default is 35. |
|
Authenticate using alternate credentials? |
Select Yes to use an alternative username and password for creating and accessing a container to test replication latency. |
|
Username |
Specify the username of the alternative account. Use the following format: [domain name]\[username] Leave blank to use the AppManager agent account. |
|
Password |
Specify the password of the alternative account. Leave blank to use the AppManager agent password. |
|
Monitor Active Directory replication latency |
|
|
Role |
Select the role of the server where you ran the script: Injector, Monitor, or Both. The default is Both. The role you select determines whether the server injects changes, monitors for changes (and measures latency), or does both. The Injector can inject changes to domain, configuration, and application partitions. If you select Injector or Monitor, you should at minimum run the job on one server acting as an Injector and a second server acting as a Monitor. If you select Both, run the job on a minimum of two servers. Run this script on multiple servers to properly monitor replication latency. |
|
Change injection frequency |
Enter a value, from 1 to 360, to determine how frequently changes are injected to test replication latency, the number of monitoring intervals between injections. The value you enter is a divisor of the interval you selected on the Schedule tab. For example, the default schedule for this script is Every 17 minutes (Daily schedule). With this schedule, if you enter 24 for this parameter, a change is injected every 408 minutes. The default is one change for every 24 monitoring intervals. NOTE:This parameter is only applicable when you select Injector or Both for the Role parameter. |
|
Monitor changes from servers that are |
Select the type of servers to monitor for changes: Intersite, Intrasite, or Both. The default is Both. |
|
Partitions |
|
|
Change/monitor domain partition? |
Select Yes to monitor the domain partition. The default is Yes. |
|
Change/monitor configuration partition? |
Select Yes to monitor the configuration partition. The default is unselected. |
|
Change/monitor application partitions? |
Select Yes to monitor application partitions. The default is Yes. |
|
Monitor global catalog partitions? |
Select Yes to monitor global catalog partitions. The default is Yes. |
|
Path to container relative to partition root |
Specify any location where the container should be created. By default, the container is created in the root of the partition. For example, say the domain of the domain controller is company.local. If you set this parameter to CN=AppManager and enabled monitoring of domain and configuration partitions, the domain partition path would be: CN=AppManager,DC=company,DC=local and the configuration partition path would be: CN=AppManager,CN=configuration,DC=company,DC=local |
|
Container name |
Supply a name for a container that will be created in each of the partitions you selected for monitoring above. NOTE:You can specify a parent container, however you must first create that parent container with the appropriate security rights to allow creation of sub-objects using the credentials of the AppManager agent (by default) or the credentials you specified for the Username and Password parameters. The default container name is AMReplicationLatencyObjects. |
|
Event Notification |
|
|
Raise event if latency threshold exceeded? |
Select Yes to raise an event if the amount of intersite replication latency exceeds the threshold you set. The default is Yes. |
|
Threshold -- Maximum intersite latency |
Specify the maximum amount of intersite replication latency that can be measured before an event is raised. The default is 540 minutes. |
|
Threshold -- Maximum intrasite latency |
Specify the maximum amount of intrasite replication latency that can be measured before an event is raised. The default is 15 minutes. |
|
Event severity when latency exceeds threshold |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which intersite or intrasite latency exceeds the thresholds you set. The default is 10. |
|
Raise event if time skew detected? |
Select Yes to raise an event if the creation time of an object used for replication latency monitoring appears to be earlier than the time of the corresponding monitoring job. The default is Yes. NOTE:If you notice this event, verify that the report servers are synchronized to a common time source. |
|
Event severity when time skew detected |
Set the severity level, from 1 to 40, to indicate the importance of an event in which object creation time is out of sync with the monitoring job.The default is 10. |
|
Raise event if object not updated within threshold time? |
Select Yes to raise an event if an object is not updated within the threshold interval, which indicates that replication is not occurring. The default is Yes. NOTE:If you stop a server from injecting changes, delete the replication objects that represent it. |
|
Threshold -- Maximum time for object to be updated |
Specify the maximum amount of time that can be taken for an object update to be completed before an event is raised. The default is 24 hours. |
|
Event severity when object not updated within threshold time |
Set the event severity level, from 1 to 40, to indicate the importance of an event in which the time it takes to update an object exceeds the threshold. The default is 10. |
|
Data Collection |
|
|
Collect data for replication latency? |
Select Yes to collect data for charts and reports. If enabled, data collection returns the replication latency in minutes. The default is unselected. If enabled, data streams are generated indicating the latency of the injected objects for all of the selected partitions to be monitored. NOTE:This parameter is only valid if you selected Monitor or Both for the Role parameter. |
|
Collect data for lost data due to latency? |
Select Yes to collect data for charts and reports. If enabled, data collection returns the number of lost changes. The default is unselected. |
You have an Active Directory forest named company.local. It contains the server cdc1.company.local (the primary domain controller and global catalog server) and cdc2.company.local (the secondary domain controller). This forest also contains a child domain named sales.company.local, which has the domain controllers scdc1.sales.company.local and scdc2.sales.company.local.
To use the ReplicationLatency script to verify that replication is occurring among all the domain controllers (DCs) in this forest, you could run it on all of the DCs listed above, designating each one as “Both” Injector and Monitor for the Role parameter. You could set the schedule and the Change injection frequency parameter so that Active Directory data would be injected at each monitoring interval into each of the partition types selected.
Acting as the Injector, each DC creates a lightweight replication object, a contact object, in each selected, writeable partition. The replication object is created in the container specified by the Container name and Path to container relative to partition root parameters.
If the container for the replication objects does not exist on the local partition, the DC attempts to create the container on a DC that hosts a writeable copy of the partition. The replication object is not created locally until the container is replicated to the local partition.
At every injection interval, the Injector changes the “description” property of the replication object. The timestamp of the change on the Injector (Injection time) is stored in the description property. Active Directory replication propagates the change to DCs that host a copy of the partition.
Acting as the Monitor, the DC checks the local container specified by the Container name and Path to container relative to partition root parameters for replication objects, created and changed by each Injector. As the Monitor, it computes the latency by measuring the difference between the Arrival time (the “whenChanged” property) and the Injection time for each replication object.
Instead of running the ReplicationLatency script with the default setting, which places target servers in the roles of both Injector and Monitor, you could run the script on pairs of Active Directory servers. You could run it on the domain controllers scdc1.sales.company.local and scdc2.sales.company.local, designating one DC in each pair as an Injector and the other as a Monitor.
You would then enable data collection on the Monitor in each pair to measure replication latency. You would need to do the same thing for the pair cdc1.company.local and cdc2.company.local.
Extending the example introduced in Section 3.41.4, Examples of How this Script Is Used: Example 1 to a very large Active Directory topology, the ReplicationLatency script could be used to selectively inject changes at a few key sites, while measuring changes at all the remote sites.
Suppose there are two main company sites, Corporate and Sales, where Help Desk personnel routinely handle user account and password resets. In addition, there are several thousand branch office sites, parts of a department store chain. A single DC from the Corporate site and one from the Sales site would act as both Injector and Monitor. Then a single DC from each of the branch office sites would run as a Monitor. This configuration would ensure that replication latency remained below the threshold you specified and would also cover the entire Active Directory topology, while minimizing the number of event notifications and the amount of collected data.
To isolate replication latency monitoring to intersite replication, you can deploy the ReplicationLatency script to a bridgehead server at each Injector and Monitor site.