Active Directory Management Pack Scripts

The tables in this section and in the next section describe each of the monitoring scripts that are included with a default Active Directory Management Pack (ADMP) installation, the purpose of the script, the rule that starts the script, and the default frequency for running the script. The sections that follow the tables describe each script in detail.

Script	Purpose	Rule	Default Frequency
AD CPU Overload	This script provides monitoring of CPU utilization for Active Directory (as represented by LSASS.exe) on each domain controller. Because brief-duration CPU spiking on domain controllers is a common occurrence, this script contains logic to prevent the unwanted and unnecessary over-reporting of CPU bottlenecks.	Script - AD CPU Overload	Once per minute
AD Database and Log File	This script helps ensure that every domain controller being monitored has sufficient free disk space for the Active Directory database. The script monitors both the size of the Active Directory database, as well as the amount of free disk space on the volume on which the Active Directory database is stored. By monitoring both of these conditions, this script helps prevent problems that occur when the database grows too quickly (as a result of the proliferation of new objects), when programs other than Active Directory are filling up the volume, or when a denial-of-service attack on the directory might be occurring.	Script - AD Database and Log File	Every 15 minutes
AD DNS Verification	This script checks whether the domain that the monitored computer is joined to is a single-label domain name (that is, a DNS name that does not include a suffix such as .com, .net, or .org).	Script - AD DNS Verification	Once per day
AD Essential Services	This script monitors the services outside Active Directory that are essential to the proper operation of Active Directory. On each domain controller being monitored, this script makes sure that each of the following services is running, and the script generates an Error alert if a service is not available: File Replication (ntfrs) Intersite Messaging (IsmServ — required on Windows 2000 Server domain controllers and Windows Server 2003 domain controllers that are not operating at the Windows Server 2003 forest functional level) Kerberos Key Distribution Center (kdc) Net Logon (Netlogon) Windows Time (W32Time) In addition, this script determines the availability of the SYSVOL share on the domain controller, and it checks that the domain controller Locator is functioning properly.	Script - AD Essential Services Running	Every 11 minutes
AD General Response	This script determines the general responsiveness of Active Directory within a domain by determining the time that is required to complete a search of rootDSE. The script contacts the domain (using a serverless bind) and measures the response time for an Active Directory Service Interfaces (ADSI) bind to the rootDSE object of a domain controller in the domain. The script records this response time as performance data. Performance rules monitor the response-time data being recorded, and they generate alerts if response times exceed specified thresholds.	Script - AD General Response	Every five minutes
AD Global Catalog Search Response	This script monitors the responsiveness of the global catalog to help ensure that directory clients can search for directory objects in a forest in a timely manner.	Script - AD Global Catalog Search Response	Every five minutes
AD Lost and Found Object Count	This script monitors the number of Active Directory objects in the Lost and Found container, and it generates an alert when the number of objects in this container exceeds the threshold. The threshold for a Warning alert is 10, and the threshold for an Error alert is 100.	Script - AD Lost and Found Object Count	Every two hours
AD Monitor Trusts	Trust problems in Active Directory can result in many other types of problems, including authentication failures and the inability to access resources. This script enumerates the trusts on each domain controller, queries the status and validates the state of those trusts, and generates alerts if any problems exist. This script uses the TrustMon WMI provider.	Script - AD Monitor Trusts	Every 17 minutes
AD No GC Logon Information	This script applies only to Windows Server 2003 domain controllers, and it monitors problems with No GC Logon functionality. No GC Logon in Windows Server 2003 allows users to log on to the network, even if a global catalog is not available. This script generates an alert anytime an event that is associated with No GC Logon occurs, and it collects information that may be useful in troubleshooting those events.	Group Cache Refresh has reached the user limit for this domain controller – And – Group Refresh updates are falling behind	Runs when the following events appear in the Directory Services event log: NTDS General: 1669 NTDS General: 1670
AD Op Master Response	This script monitors Active Directory operations masters and determines whether they are responsive. The response time for each role holder is recorded as performance data, and the script generates alerts if the thresholds associated with the script are exceeded.	Script - AD Op Master Response	Every five minutes
AD Topology Discovery	This script collects information about the site link replication topology for the forest. The information that is collected by this script is displayed in the Site Links topology diagram.	Script - AD Topology Discovery	Every 30 minutes
AD Remote Topology Discovery	This script collects information about the connection object health and topology for each domain controller. The information that is collected by this script is displayed in the Connection Objects topology diagram.	Script - AD Remote Topology Discovery	Every five minutes
AD Replication Monitoring	This script injects a small directory change on each domain controller being monitored, and it then monitors replication for failures and latency, based on the replication of the injected change. This script also queries the ReplProv WMI provider to get the status of the last replication attempt for each incoming connection object.	Script - AD Replication Monitoring	Once per hour
AD Replication Partner Count	For Active Directory replication to work properly, each domain controller must have an accurate record of the replication topology. This script monitors domain controllers for problems that can adversely affect the replication topology. It does this by counting and tracking over time the number of replication partners a domain controller has and by generating alerts when too many — or too few — replication partners exist.	Script - AD Replication Partner Count	Every two hours
AD Replication Partner Op Master Consistency	For Active Directory to work properly, all domain controllers in a domain or forest must agree on the identity of the domain controllers that hold the operation master roles for their respective domain or forest. This script monitors the consistency of operation masters in a domain or forest.	Script - AD Replication Partner Op Master Consistency	Once per hour
AD Server Moved Site	This script monitors domain controllers and generates a message alert when a domain controller has recently moved to a different site. An administrator can then determine if the move was intentional.	Script - AD Server Moved Site	Once per day

For the client-side monitoring scripts in the following table to run, you must manually add one or more computers to the Active Directory Client-Side Monitoring computer group.

Script	Purpose	Rule	Default Frequency
AD Client Update DCs	Each computer that is being used for client-side monitoring targets a specific set of domain controllers to monitor, depending on its monitoring configuration. This script is used to update a list of domain controllers being monitored by each of the computers that are being used for client-side monitoring.	Script - AD Client Update DCs	Once per day
AD Client Connectivity	This script determines if the domain controllers that are being monitored by a client-side monitoring computer are currently available and working, from the perspective of the client. The tests that are used by the script to make this determination include the following: Internet Control Message Protocol (ICMP) ping net use (to SYSVOL) LDAP ping ADSI binding and searching Serverless bind	Script - AD Client Connectivity	Every five minutes
AD Client GC Availability	This script discovers and connects to global catalogs in the forest and ensures that at least a minimum number of global catalogs are available.	Script - AD Client GC Availability	Every five minutes
AD Client Serverless Bind	It is generally recommended that directory clients authenticate and perform directory searches against domain controllers that are located in the same site as the clients to reduce wide area network (WAN) traffic and to ensure good response times for the client. For computers that are being used for client-side monitoring, this script determines if the domain controllers that are responsible for the site that is being monitored by the clients are located in the same site as the clients. The script does this by performing a serverless bind against each of its target domain controllers and by generating an alert when a domain controller is not available, responding too slowly, or located in a different site.	Script - AD Client Serverless Bind	Every 15 minutes
AD Client PDC Response	If the PDC emulator operations master role holder for a forest is not available to a client, clients in that forest cannot log on. For each computer that is being used for client-side monitoring, this script discovers, pings, and binds to the PDC emulator operations master, and it generates an alert if the ping or bind fails.	Script - AD Client PDC Response	Every 10 minutes

On This Page

AD CPU Overload
AD Database and Log File
AD DNS Verification
AD Essential Services
AD General Response
AD Global Catalog Search Response
AD Lost and Found Object Count
AD Monitor Trusts
AD No GC Logon Information
AD Op Master Response
AD Topology Discovery
AD Remote Topology Discovery
AD Replication Monitoring
AD Replication Partner Count
AD Replication Partner Op Master Consistency
AD Server Moved Site

AD CPU Overload

The AD CPU Overload script monitors domain controller and LSASS CPU utilization by sampling a number of performance counters and then averaging the samples over a predefined period.

Parameters

The AD CPU Overload script can be configured using the script parameters in MOM 2005. The following table describes the configurable parameters.

Parameter Name	Default Value	Valid Range	What It Does
LSASSThreshold	80	1 through 100	Average sampled CPU usage for the LSASS process, above which CPU usage is considered excessive.
NumSamples	10	1 through 100	The number of samples that are averaged before comparing each performance counter with the supplied thresholds. This parameter, along with the frequency with which the script is run, determines the sampling period.
MaxFrequency	15	1 through 720	The minimum number of minutes between messages that are generated by this script for a given condition: either total CPU usage or LSASS CPU usage. This controls the maximum frequency at which messages are generated by the script.
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished executing successfully. This can be useful for debugging purposes.

Performance Counters

The AD CPU Overload script samples performance counters using the WMI providers and properties in the following table.

Provider	Instance	Counter
Win32_PerfRawData_PerfProc_Process	LSASS	Timestamp_Sys100NS
Win32_PerfRawData_PerfProc_Process	LSASS	PercentProcessorTime

This script collects samples from the TimeStamp_Sys100NS and PercentProcessorTime performance counters at predefined intervals and stores them in memory. The number of stored samples is defined by the NumSamples script parameter. When the script collects the defined number of samples from each performance counter, it takes the first samples from each and the last samples from each and uses a formula to determine the actual CPU usage from the time that the first sample was taken until the time that the last sample was taken.

For example, the PercentProcessorTime counter represents the number of processor ticks on an LSASS thread. To determine actual PercentProcessorTime over a specific period, the script collects the number of samples that is defined by the NumSamples parameter. Each sample has a time stamp so that the start and end of the period are recorded, along with the tick count at each end of the period. Using these values, PercentProcessorTime can be computed as:

If multiple event rules run this script, the script will not function correctly. In addition, if the MOM service restarts, the data in memory is lost, and the script must start collecting data from scratch.

Note

The PercentProcessorTime counter is not normalized. That is, it represents the amount of CPU time that is used across all CPUs in the system. All thresholds, as well as all other CPU counters, are normalized. Therefore, before this property is compared to thresholds, it is normalized using the number of CPUs that are defined in the system. The number of CPUs in the system is read from the following registry key: HKLM\SYSTEM\CurrentControlSet\Control\
SessionManager\Environment\NUMBER_OF_PROCESSORS

Permissions

For the AD CPU Overload script to run successfully, the Agent Action Account must have Read access to the Timestamp_Sys100NS and PercentProcessorTime performance counters as well as the following registry key: HKLM\SYSTEM\CurrentControlSet\Control
\SessionManager\Environment\NUMBER_OF_PROCESSORS

How the Script Works

Initially, the AD CPU Overload script checks all parameters for a valid value, based on the associated valid range. If a parameter is outside its valid range, the script sets the parameter to the default value, and an event is created that identifies the problem to the user. The performance counters are then sampled and stored in the buffer. When an alert occurs within a certain number of minutes of the previous alert as determined by the MaxFrequency parameter, the script exits immediately, without doing anything else.

The samples in the circular buffer are validated and then averaged. (The buffer must be full before the averages are calculated.) These averages are compared against the user-defined threshold of the LSASSThreshold parameter. If the threshold of the LSASSThreshold parameter is exceeded, an event is generated that indicates the average CPU usage by LSASS over the sampling period.

Events

The AD CPU Overload script generates the events in the following table.

Event Number	Purpose
20066	An invalid parameter was defined. The event describes the invalid parameter and how to correct it.
21000	During execution of the script, an error was encountered that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors when binding to rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20071	This is the LSASS process, high-CPU-usage event. This event indicates that the average LSASS process CPU usage has exceeded the threshold of the LSASSThreshold parameter over the sampling period. The event message describes the threshold and the current average value.
20099	This event is logged to indicate that the script successfully completed running. This event is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD CPU Overload script generates alerts using the rules in the following table.

Rule	Description
The LSASS process is using a high percentage of available CPU time	Generates a Warning alert when event ID 20071 occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain. No responses are run with respect to this rule.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Database and Log File

The AD Database and Log File script monitors database and log file size and available free space on the associated disk volumes. By default, the script runs every 15 minutes, and it calls the OOMADs Component Object Model (COM) object to obtain data.

Note

The ADMP COM helper object, OOMADs, is used by several ADMP monitoring scripts for making system calls that are not available in Microsoft Visual Basic® Scripting Edition (VBScript). The information pertaining to the OOMADs COM object in this document is provided for informational purposes only. Microsoft does not provide programming support for the use of OOMADs.

Parameters

The AD Database and Log File script can be configured using the script parameters in MOM 2005. The following table describes the configurable parameter for this script.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished executing successfully. This parameter can be useful for debugging purposes.

Permissions

For the AD Database and Log File script to run successfully, the Agent Action Account must have Read access to the location of the Active Directory database and log files as well as to the following registry keys:

HKLM\SYSTEM\CurrentControlSet\Services
\NetLogon\Parameters\SYSVOL

HKLM\SYSTEM\CurrentControlSet\Services
\NTDS\Parameters\DSA Database file

HKLM\SYSTEM\CurrentControlSet\Services
\NTDS\Parameters\Database log files path

How the Script Works

The AD Database and Log File script first calls OOMADs.GetDatabaseInfo. If that call succeeds, the script stores the returned values for drive free space and database size as performance data. The script then calls OOMADs.GetLogFileInfo. If that call succeeds, the script stores the returned values for drive free space and database log size as performance data. If both calls succeed, the script attempts to determine if a significant decrease has occurred in the amount of free space on either drive, and, if possible, it identifies the cause of the reduction of free space.

To make this determination, the script records the following data:

• Active Directory Database (DIT) Size

• Log Size

• Free DB Space

• Free Log Space

• SYSVOL Size

• Last Execution Time

Database and Log File Growth

When a domain controller is not in its first replication cycle, the AD Database and Log File script performs a test to determine whether excessive growth in either the database or the log files is occurring.

Note

Immediately after Active Directory is installed and a computer becomes a domain controller, an initial, complete replication cycle must occur before the domain controller begins advertising its services on the network. During this initial replication cycle, the database and log file sizes are expected to grow significantly. This growth is not reported by the script as an error. However, for a new domain controller, the script still reports any low-disk-space conditions.

To determine whether the domain controller is in its initial replication cycle, an attempt is made to read the replUpToDateVector attribute on the LDAP://RootDSE object of the local computer. If the attribute exists, the domain controller has already completed its first replication cycle.

A comparison of the current and previous values for database and log file size is used to determine whether the database or log has grown more than 20 percent since the last time that the script ran. If excessive growth has occurred, an event is generated that indicates the amount of growth and the time difference (in minutes) between the current and previous measurements.

Note

The 20-percent value is fixed, and it cannot be configured by the user.

Free Space

Required free space

If the database and log files reside on separate logical drives, the script verifies that the logical drive holding the database file has the greater of 500,000 kilobytes (KB) or 20 percent of the current database size available. The script also verifies that the logical drive holding the log file has the greater of 200,000 KB or 5 percent of the current database size available.

If the database and log files reside on the same logical drive, the script verifies that the greater of 700,000 KB or 25 percent of the current size of the database is available on the drive.

Free-space algorithm

First, the script determines whether the database and log files reside on the same logical drive. The script makes this determination by comparing the first two characters of the file path for both the database and the log files. (If one path uses a Universal Naming Convention (UNC) path name and the other path uses a drive\directory path name, the check fails.)

If both files reside on the same drive, the amount of free space that is required on the database drive is added to the amount of free space on the log drive.

The required amount of free space is then checked against the available free space. If the required free space is greater than the available free space, an event is generated. The event contains the current free space on the drive and the calculated, required free space on the drive.

Events

The AD Database and Log File script generates the events in the following table.

Event Number	Purpose
20066	An invalid parameter was defined. The event describes the invalid parameter and how to correct it.
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors when binding to the rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20023	An error occurred while the script was obtaining information about the database.
20024	An error occurred while the script was obtaining information about the log file.
20333	Space available warning. This indicates that one of the drives that either the database or log files are on has a low-space condition.
20334	DIT Growth Warning. This indicates that the database has grown quickly and unexpectedly. This should be investigated.
20335	Log File Growth Warning. This indicates that the log file has grown quickly and unexpectedly. This should be investigated.
20099	This event is logged to indicate that the script successfully completed running. It is only logged when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Database and Log File script generates alerts using the rules in the following table.

Rule	Description
Database and Log File Drive Space - Error	This rule generates an error message from event 20333. The alerts are suppressed on the following fields: Event Number, Source Name, and Computer.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD DNS Verification

The AD DNS Verification script checks whether the domain that the monitored computer is joined to has a single-label domain name (that is, a DNS name that does not include a suffix such as .com, .net, or .org).

Parameters

The AD DNS Verification script can be configured using the script parameters in MOM 2005. The following table describes the configurable parameter for this script.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True or False	Indicates whether to log a success event when the script has completed successfully.

Permissions

For the AD DNS Verification script to run successfully, the Agent Action Account must have the required access to instantiate an instance of the Win32_OperatingSystem WMI class.

How the Script Works

The AD DNS Verification script checks whether the domain that the monitored computer is joined to has a single-label domain name. If the domain name is not a single-label name, the script takes no action. If the script detects that the domain name is a single-label name, the script checks for the presence and value of the following registry keys:

On Windows 2000 Service Pack 4 (SP4) and later: HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters

On Windows Server 2003:
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNS\Client

These registry keys are used to enable registrations to domains with single-label names. Registrations to single-label domains are turned off by default to prevent update requests from being sent to computers that host the .com, .net, and .org DNS zones. However, registrations are enabled when the single-label domain name belongs to an Active Directory domain. In any case, the use of single-label domain names is not recommended.

If the registry key is absent, an Error alert is generated. If the registry key is present, but the value is set to False, an Error alert is also generated.

Events

The AD DNS Verification script generates the events in the following table.

Number	Purpose
20072	This event indicates that you have a single-label name and that the registry key is not set.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD DNS Verification script generates alerts using the rules in the following table.

Rule	Description
DNS registration of essential domain controller records is failing because the Active Directory domain is a single label domain for Windows 2000 SP4 and 2003	This rule generates an Error alert when event 20072 occurs. The alerts are suppressed on the following fields: Computer and Domain.
The Active Directory Management Pack does not support the agentless management mode	This rule generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Essential Services

The AD Essential Services script monitors the following five services that are essential to Active Directory:

• File Replication (ntfrs)

• Intersite Messaging (IsmServ — required on Windows 2000 domain controllers and Windows Server 2003 domain controllers that are not operating at the Windows Server 2003 forest functional level)

• Kerberos Key Distribution Center (kdc)

• Net Logon (Netlogon)

• Windows Time (W32Time)

In addition, this script determines the availability of the following:

• The SYSVOL share

• The domain controller Locator service

This script runs every 11 minutes by default. The script uses an 11minute interval, rather than a 5-minute interval, to avoid an excessive number of monitoring scripts running at 5-minute intervals.

Parameters

The AD Essential Services script can be configured using the script parameter in the following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether the script logs an event indicating that the script completed successfully, which can be useful for debugging purposes.

Permissions

For the AD Essential Services script to run successfully, the Agent Action Account must have Read access to the SYSVOL share, as well as the access required to instantiate an instance of the Win32_Service, Win32_OperatingSystem,
Win32_NetworkAdapterConfiguration, and
Win32_PerRawData_PerOS_System WMI classes.

How the Script Works

The AD Essential Services script checks the status of the essential Active Directory services. If one of the services is not running or if the script cannot determine the status of a service, the script generates an event indicating the current state of the service.

If the script finds a service that is not running, the script records the service status in a MOM 2005 variable. If the service is running, any previous value in the variable is erased, and the script generates an informational event indicating that the service has resumed running.

After the script checks the status of the services, it tests the availability of the domain controller by attempting to map a network drive using the path \127.0.0.1\SYSVOL, which represents the SYSVOL directory on the domain controller. If the script is unable to map a network drive, it generates an event indicating the error that is returned from the attempt. In addition, the script sets a MOM variable indicating that a failure has occurred.

If the script is able to map a network drive to the domain controller, it will not generate an event, and it will subsequently remove the mapped drive. In addition, if the MOM variable indicates that a previous failure has occurred, the script clears the variable and generates an informational event indicating that the SYSVOL directory is now available.

If the Net Logon service is running and if the system has been running for more than 20 minutes, the script calls GetAnyDCName on an instance of the ADSystemInfo object, which indirectly calls the DsGetDCName API to check the domain controller Locator. The script then compares the name that is returned with the name of the local domain controller. If the names do not match, the script generates an error message indicating that the domain controller is not advertising and sets a MOM variable indicating that a failure has occurred. If the names match and if a MOM variable was set previously, the script clears the variable and generates an event indicating that the domain controller Locator is now working.

Events

The AD Essential Services script generates the events in the following table.

Event Number	Purpose
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
38901	When this event is reported as an Error, FRS is not running. When this event is reported as Information, FRS has resumed running.
38902	When this event is reported as an Error, the Net Logon service is not running. When this event is reported as Information, the Net Logon service has resumed running.
38903	When this event is reported as an Error, the Kerberos Key Distribution Center service is not running. When this event is reported as Information, the Kerberos Key Distribution Center service has resumed running.
38904	If this event is reported as an Error, the Windows Time service is not running. If this event is reported as Information, the Windows Time service has resumed running.
38905	If this event is reported as an Error, the Intersite Messaging service is not running. If this event is reported as Information, the Intersite Messaging service has resumed running.
38906	Mapping the network drive \\127.0.0.1\SYSVOL failed. The error is included as part of the event description.
38907	When this event occurs, domain controller location failed. The local domain controller name was not returned from the call to GetAnyDCName. The local domain controller name and the name that is returned from GetAnyDCName are included as part of the event description.
38910	This event indicates that the script completed successfully. The event is only logged when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by a MOM event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Essential Services script generates alerts through the rules in the following table.

Rule	Description
AD Essential Services Running Consolidation Rule	This rule consolidates all events, which are generated by the script, that match the following criteria: Event Number; Event Type (Information, Warning, Error, and others); Source Name; Agent; and Source Domain. Events are consolidated over a 3,600-second (one-hour) period.
Cannot connect to local SYSVOL share	This rule generates an Error alert when event 38906 occurs. The alerts are suppressed on the following fields: Source Name, Event Number, and Computer.
File Replication Service has resumed running	This rule generates an Information alert when event 38901 of the severity level Information occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
File Replication Service is not running	This rule generates an Error alert when event 38901 of the severity level Error occurs. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, Computer, and Logging Domain.
Intersite Messaging Service has resumed running	This rule generates an Information alert when event 38905 of the severity level Information occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Intersite Messaging Service is not running	This rule generates an Error alert when event 38905 of the severity level Error occurs. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, Computer, and Logging Domain.
Kerberos Key Distribution Center Service (KDC) has resumed running	This rule generates an Information alert when event 38903 of the severity level Information occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Kerberos Key Distribution Center Service (KDC) is not running	This rule generates an Error alert when event 38903 of the severity level Error occurs. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, Computer, and Logging Domain.
NetLogon Service has resumed running	This rule generates an Information alert when event 38902 of the severity level Information occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
NetLogon Service is not running	This rule generates an Error alert when event 38902 of the severity level Error occurs. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, Computer, and Logging Domain.
The domain controller is not advertising. Clients will not be able to locate this domain controller	This rule generates an Error alert when event 38907 occurs. The alerts are suppressed on the following fields: Source Name, Event Number, and Computer.
Windows Time Service has resumed running	This rule generates an Information alert when event 38904 of the severity level Information occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Windows Time Service is not running	This rule generates an Error alert when event 38904 of the severity level Error occurs. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, Computer, and Logging Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD General Response

The AD General Response script determines the general responsiveness of Active Directory within a domain by determining the time that is required to complete a search of rootDSE. This script contacts a domain controller in the domain (using a serverless bind) and measures the response time for an ADSI bind to the rootDSE object on the domain controller. The script records this response time in MOM 2005 as performance data. Performance rules monitor the response time data being recorded, and they generate alerts if response times exceed specified thresholds. This script runs every five minutes by default.

Parameters

The AD General Response script accepts two parameters, as described in the following table. If the value of the FailureThreshold parameter falls outside the valid range, the script resets the value to the default, and it generates an event indicating the invalid configuration.

Parameter Name	Default Value	Valid Range	What It Does
FailureThreshold	4	1 through 20	Indicates the number of consecutive failures that are required before an alert is generated.
LogSuccessEvent	False	True/False	Determines whether to log an event indicating the script finished successfully, which can be useful for debugging purposes.

Permissions

No special permissions are required to run the AD General Response script.

How the Script Works

The AD General Response script performs a serverless ADSI bind to rootDSE. If the bind fails, the script generates an event indicating the failure, and it increments two counters. The first counter indicates the number of consecutive failures. The second counter indicates the number of failures per day. If the number of consecutive failures reaches the value of the FailureThreshold parameter, an event is generated that contains the reason for each of the consecutive failures.

If the bind succeeds, the first counter (for consecutive failures) is reset to 0, and the script generates performance data. MOM stores the performance data (measured in seconds) in the ActiveDirectoryMP/Active Directory Last Bind performance counter.

Events

The AD General Response script generates the events in the following table.

Event Number	Purpose
20066	An invalid parameter was defined. This event describes the invalid parameter and how to correct it.
21000	An error was encountered during execution of the script that the script does not specifically handle. Such errors include errors that are returned by the WMI provider, errors in binding to rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20025	This event is logged to indicate that the script completed successfully, and it is logged only when the value of the LogSuccessEvent parameter is set to True.
20002	This event is logged to indicate that the script was not run by an event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The rules in the following table are associated with the AD General Response script.

Rule	Description
Active Directory Last Bind - Threshold Exceeded	When the average of the last five samples of the specified counter is greater than 30 seconds, a Critical alert is generated. The alert indicates the average over the last five samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – When the average of the last five samples of the specified counter is greater than 15 seconds, an Error alert is generated. The alert indicates the average over the last five samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – When the average of the last five samples of the specified counter is greater than 5 seconds, an Information alert is generated. The alert indicates the average over the last five samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Global Catalog Search Response

The AD Global Catalog Search Response script searches a global catalog and measures search response time. This script can be run only by an event rule, and it can be run only on a domain controller.

Parameters

The AD Global Catalog Search Response script accepts the parameters that are described in the following table. When the value of the FailureThreshold parameter falls outside the valid range, the script resets the value to the default value and generates an event. The script does not validate the query that is provided in the Query parameter, but an invalid search results in an event indicating the failure.

Parameter Name	Default Value	Valid Range	What It Does
FailureThreshold	4	1 through 8	Indicates the number of consecutive failures required before an alert is generated.
Query	(objectCategory=DMD)	Any valid LDAP filter	Indicates the query to run against the global catalog.
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished successfully, which can be useful for debugging purposes.

Note

The default value of the Query parameter has been carefully determined, based on the need for a reliably successful query (that is, at least one object is always returned by the query) that also has a low performance impact (that is, only a small number of objects are returned by the query). If you decide to change the default value of the Query parameter for any reason, it is recommended that you choose the new value carefully.

Permissions

To run the AD Global Catalog Search Response script successfully, the Agent Action Account must have Read access to the global catalog.

How the Script Works

The AD Global Catalog Search Response script creates an instance of the OOMADs COM object and calls the OOMADs.SearchGlobalCatalog method, passing the script parameter Query into the method call and executing the search on the nearest global catalog. The script then counts the number of results that are returned by the search.

If the call to OOMADs.SearchGlobalCatalog fails, the script generates an event indicating the error and increments a consecutive errors counter. If the number of consecutive errors equals the value of the FailureThreshold parameter, the script generates an alert event that contains the error descriptions for the previous consecutive errors.

If the call to OOMADs.SearchGlobalCatalog succeeds, and if the number of consecutive errors is greater than the value of the FailureThreshold parameter, the script generates an event indicating that the global catalog search has resumed after a certain number of consecutive failures, and it causes a Success alert to be generated in MOM 2005. Finally, the consecutive failures count is reset to 0.

When it completes successfully, the script generates performance data and stores it in MOM 2005. The data, which is stored in the ActiveDirectoryMP/Global Catalog Search Time counter, represents the length of time (in seconds) that is required to complete the search on the global catalog.

Events

The AD Global Catalog Search Response script generates the events in the following table.

Event Number	Purpose
21026	This event indicates the number of consecutive failures that occurred during the script. The event includes the event descriptions of the consecutive failures, along with the times at which the failures occurred. This event serves as a summary of consecutive 21027 events.
21027	This event indicates that a failure occurred during the running of the script. The event includes the error description and the operation that the script was performing when the error occurred. One event is generated per failure.
20066	This event indicates that an invalid parameter was defined. The event describes the invalid parameter and the proper corrective action.
21000	The script encountered an error that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed successfully, and it is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Global Catalog Search Response script generates global catalog response alerts through the rules in the following table.

Rule	Description
Global Catalog Search Time - Threshold Exceeded	This rule generates a Critical Error alert when the average value of the ActiveDirectoryMP/Global Catalog Search Time counter exceeds 30 over five samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average value of the ActiveDirectoryMP/Global Catalog Search Time counter exceeds 15 over 5 samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates a Warning alert when the average value of the ActiveDirectoryMP/Global Catalog Search Time counter exceeds 5 over five samples. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Lost and Found Object Count

The Lost and Found container in Active Directory contains objects that have been orphaned. Administrators should examine each object in the Lost and Found container to determine whether to delete the object or move it to another container.

Orphaned objects are typically generated as follows. Assume that two domain controllers (DC1 and DC2) exist, each with a replicated copy of a given container. On DC1, a child is created in the container, while on DC2 (before replication can happen) the container is deleted. When DC1 replicates changes to DC2, the child object discovers it has no parent container available. Therefore, DC2 adds the child to the Lost and Found container.

The AD Lost and Found Object Count script counts the number of objects in the Lost and Found container on the local domain controller and reports the information as performance data.

Parameters

The AD Lost and Found Object Count script accepts the parameter in the following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished executing successfully. This can be useful for debugging purposes.

Permissions

For the AD Lost and Found Object Count script to run successfully, the Agent Action Account must have Read access to the Lost and Found container (CN=LostandFound) and the Domain container.

How the Script Works

The AD Lost and Found Object Count script creates an instance of the OOMADs COM object, sets the Server property to the local computer, and calls the OOMADs.BindLostFoundContainer method to bind to the Lost and Found container. After this bind, the script iterates and counts the objects in the Lost and Found container. If the call to OOMADs.BindLostFoundContainer fails, an event is generated indicating the nature of the error.

If the call to OOMADs.BindLostFoundContainer succeeds, the script writes performance data to MOM 2005 indicating the number of objects in the Lost and Found container.

If the value of the LogSuccessEvent parameter is True, the script generates an event indicating that the script completed successfully, the time necessary to complete the run, and the number of items in the Lost and Found container.

Events

The AD Lost and Found Object Count script generates the events in the following table.

Event Number	Purpose
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20028	This event is logged to indicate that the script completed execution successfully. It is logged only when the value of the LogSuccessEvent parameter is True. It includes the time the script took to run and the number of items in the Lost and Found container.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Lost and Found Object Count script generates alerts through the threshold rules in the following table.

Rule	Description
Active Directory Lost Objects - Threshold Exceeded	Generates an Error alert when the value of the ActiveDirectoryMP\Active Directory Lost Objects MOM performance counter exceeds 100. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates a Warning alert when the value of the ActiveDirectoryMP\Active Directory Lost Objects MOM performance counter exceeds 10. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Monitor Trusts

TrustMon, which is included on Windows Server 2003 domain controllers, is the WMI trust monitoring provider. The AD Monitor Trusts script uses TrustMon to enumerate the trusts on the local domain controller, and it generates alerts if any problems are found. (Currently, the TrustMon provider has not been validated for Windows 2000.)

Parameters

The AD Monitor Trusts script accepts the parameter in the following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished executing successfully. This can be useful for debugging purposes.

Permissions

For the AD Monitor Trusts script to run successfully, the Agent Action Account must have Administrator credentials on the domain controller that is being monitored.

How the Script Works

The AD Monitor Trusts script configures the TrustMon WMI provider to return all trusts, and then it queries for all instances of the Microsoft_DomainTrustStatus object in the \root\MicrosoftActiveDirectory WMI namespace.

For each object that is returned; if the TrustType property of the object is not Downlevel or Uplevel (the other options are Kerberos Realm and DCE, which cannot be monitored effectively by TrustMon), the trust is ignored.

If the TrustType of the object indicates that it can be monitored, the TrustStatus property of the object is checked. If TrustStatus is not 0, it indicates that the trust is in an error state and that the trust and its TrustStatusString (a textual description of the current state of the trust) are formatted and added to the TrustErrors string.

After all the Microsoft_DomainTrustStatus objects have been processed, the local domain is obtained from the \root\MicrosoftActiveDirectory:Microsoft_LocalDomainInfo object.

If the TrustErrors string has data in it, an event is generated indicating that the local domain and the trusts are in error states, including the reason for each error.

If the value of the LogSuccessEvent parameter is True, the script generates an event indicating that the script completed successfully and how long it took to run.

For more information about the TrustMon provider, see TrustMon Provider on the MDSN Web site at https://go.microsoft.com/fwlink/?LinkId=18079.

Events

The AD Monitor Trusts script generates the events in the following table.

Event Number	Purpose
20082	This event details all the trusts that cannot be monitored because they are not Windows trusts. (The code to generate this event is currently commented out because it has no perceived value.)
20083	This event details each trust that is in an error state. It includes the identity of each trust, the domain that the trust connects to, and the error description.
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed running successfully. It is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Monitor Trusts script generates alerts through the rules in the following table.

Rule	Description
A Problem Has Been Detected with the Trust Relationship Between Two Domains	Generates an Error alert whenever event 20083 is created by the AD Monitor Trusts script. The alerts are suppressed on the following fields: Alert Description, Source Name, Event Number, and Logging Domain. (Multiple alert fields from different domain controllers within the same domain with the same description are suppressed.)
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD No GC Logon Information

No GC Logon is a feature of the Windows 2003 Server family. The AD No GC Logon script runs in response to a No GC Logon event. The AD No GC Logon script collects data that may be useful to an administrator in diagnosing an error that is generated when a problem occurs with the No GC Logon functionality in Windows Server 2003.

Parameters

The AD No GC Logon script accepts the parameter in the following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished executing successfully. This can be useful for debugging purposes.

Permissions

For the AD No GC Logon script to run successfully, the Agent Action Account must have Read access to the registry and the registry keys that are listed in the following section.

How the Script Works

The AD No GC Logon script collects information that may be helpful to an administrator when an event occurs that is relevant to No GC Logon.

This script reads the following registry keys, ignoring any errors that occur during the process:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Cached Membership Site Stickiness (minutes)

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Cached Membership Staleness (minutes)

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Cached Membership Refresh Interval (minutes)

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Cached Membership Refresh Limit

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\
AutoSiteCoverage

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\
DnsAvoidRegisterRecords

HKLM\SYSTEM\CurrentControlSet\Control\
LSA\SamNoGcLogonEnforceKerberosIpCheck

HKLM\SYSTEM\CurrentControlSet\Control\
LSA\SamNoGcLogonEnforceNTLMCheck

After each registry key is read, its value or values are added to a string that is used to collect No GC Logon data.

Two searches are performed against the local computer. The search filters are as follows:

• (msDS-Site-Affinity=*)

• (&(msDS-Site-Affinity=*)(msDS-Cached-Membership=*)(msDS-Cached-Membership-Time-Stamp< Time )), where Time is the current time plus the number of minutes defined by the following registry key value: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
  Cached Membership Staleness (minutes)

The first search counts the number of objects with site affinity to the local site. The second search counts the number of objects with site affinity to the local site and to sites that have expired cache memberships.

All the data that is collected from the registry and the two searches is formatted into a string, along with descriptions of what each value means. The collected data is used as the event description for event 20090.

Events

The AD No GC Logon script generates the events in the following table.

Event Number	Purpose
20090	This event contains details of all the data that is collected by the AD No GC Logon script. This information may be useful in diagnosing and fixing errors in No GC Logon.
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed running successfully. It is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD No GC Logon script generates alerts through the rules in the following table.

Rule	Description
AD No GC Logon Information Event	This rule generates an Information alert when event 20090 from the AD No GC Logon script occurs. The alerts are suppressed on the following fields: Alert Description, Alert Source, Severity, Source Name, Event Number, Category, Description, Event Type, Computer, Logging Domain, Message DLL, Message DLL File Version, Provider Name, and User Name.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Op Master Response

The AD Op Master Response script monitors Active Directory operations masters. Operations masters are domain controllers that hold one or more of the flexible single master operations roles (also known as FSMO) in Active Directory. These roles are critical to the health and availability of Active Directory. The operations master roles include the following:

• Schema operations master

• Domain naming operations master

• Infrastructure operations master

• Relative ID (RID) operations master

• Primary domain controller (PDC) emulator operations master

This script runs every five minutes to determine the responsiveness of the operations masters. The response time for each role holder is recorded as performance data.

Parameters

The AD Op Master Response script parameters in the following table control threshold limits for alerts that are generated by this script.

Parameter Name	Default Value	Valid Range	What It Does
FailureThreshold	4	1 through 20	Indicates the number of consecutive failures for a specific test that must occur before an alert is generated.
SuccessCount	3	1 through 48	The number of times that a particular test is skipped following successful completion of that test. This parameter does not affect the testing of the PDC emulator operations master, which is tested each time that the script runs. The PDC emulator operations master must be available at all times for the domain to remain healthy.
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished successfully, which can be useful for debugging purposes.

When this script runs, it validates the SuccessCount and FailureThreshold parameters. If the value of either of these parameters is outside the valid range, the parameter is set to the default value, and an event is generated indicating which parameter was invalid.

Permissions

For the AD Op Master Response script to run successfully on Windows Server 2003 domain controllers, the Agent Action Account must be a member of the Administrators group.

How the Script Works

For each operations master, the AD Op Master Response script determines when that operations master was last tested successfully. If the number of script runs since the last successful test is greater than or equal to the SuccessCount parameter, the test is performed again (with the exception of the PDC emulator master, which is tested during each script run). An operations master is also tested if the previous test of the same operations master failed or if the operations master has not been tested since the MOM service started.

If the script tests an operations master and the test fails, the script generates an event and increments a counter that is associated with the domain controller being tested. If the counter equals the FailureThreshold parameter, the script generates another event, and it generates a Warning alert indicating that multiple consecutive failures have occurred.

When the script tests an operations master and the test completes successfully, the failure counter for that domain controller is reset to 0, and a success event is generated. The script also generates an Information alert.

Testing an operations master

For each operations master role, this script determines the domain controller that holds the role by calling the appropriate method on the OOMADs COM object. Internally, the COM object determines the role holder, as described in article 235617, “How to Find the FSMO Role Owners Using ADSI and WSH,” in the Microsoft Knowledge Base at https://go.microsoft.com/fwlink/?LinkId=16462

Before it performs any tests, the script determines the IP address of the domain controller. If this test fails, no further tests are performed. Using the IP address, the script performs a ping. Following a successful ping, the script performs a bind to the rootDSE object on the domain controller through ADSI. If the ping fails, the script tries once more, following a short (100millisecond) delay. Similarly, if the bind fails, the script also tries again after a 100millisecond delay. If either of these tests fails on the second attempt, the script considers the test of that operations master to have failed.

When the test succeeds, the script records the response time of the operations master as performance data. The script records the ping response time as ActiveDirectoryMP:Op Master XXXX Last Ping, where XXXX represents the operations master (PDC emulator, schema, and so on). The script records the bind response time as ActiveDirectoryMP:Op Master XXXX Last Bind, where XXXX represents the operations master (PDC emulator, schema, and so on).

Information gathering in the event of a failure

If the ping fails, the script discovers the DNS servers that are in use by the domain controller by using instances of the WMI Win32_NetworkAdapterConfiguration class and by using the default gateway. After obtaining the default gateway, the script attempts to ping the gateway.

The script generates an event that indicates the DNS servers that are configured for the computer, the IP address of the default gateway, and whether the default gateway is reachable. The error number and the description of the error that occurs during the tests (if available) are also included in the event description.

Events

The AD Op Master Response script generates the events in the following table.

Event Number	Purpose
20011	(Warning) Consecutive errors were encountered in contacting the PDC emulator operations master. The error descriptions are included in the event description. (Information) The tests against the PDC emulator operations master have succeeded following consecutive failures. (Both of these events cause alerts to be generated.)
20012	An error was encountered in contacting the PDC emulator operations master. (This event does not cause an alert to be generated.)
20003	(Warning) Consecutive errors were encountered in contacting the domain naming operations master. The error descriptions are included in the event description. (Information) The tests against the domain naming operations master have succeeded following consecutive failures. (Both of these events cause alerts to be generated.)
20004	An error was encountered in contacting the domain naming operations master. (This event does not cause an alert to be generated.)
20007	(Warning) Consecutive errors were encountered in contacting the infrastructure operations master. The error descriptions are included in the event description. (Information) The tests against the infrastructure operations master have succeeded following consecutive failures. (Both of these events cause alerts to be generated.)
20008	An error was encountered in contacting the infrastructure operations master. (This event does not cause an alert to be generated.)
20015	(Warning) Consecutive errors were encountered in contacting the RID operations master. The error descriptions are included in the event description. (Information) The tests against the RID operations master have succeeded following consecutive failures. (Both of these events cause alerts to be generated.)
20016	An error was encountered in contacting the RID operations master. (This event does not cause an alert to be generated.)
20019	(Warning) Consecutive errors were encountered in contacting the schema operations master. The error descriptions are included in the event description. (Information) The tests against the schema operations master have succeeded following consecutive failures. (Both of these events cause alerts to be generated.)
20020	An error was encountered in contacting the schema operations master. (This event does not cause an alert to be generated.)
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed running successfully. It is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The AD Op Master Response script generates alerts through the rules in the following table.

Rule	Description
Script - AD Op Master Response	The sole purpose of this rule is to run the script every 5 minutes.
Failed to ping or bind to the Domain Naming Master FSMO role holder	This event generates a Warning alert when event 20003 with the severity level Warning from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Contacting the Domain Naming FSMO Role Holder has completed successfully	This event generates a Success alert when event 20003 with the severity level None (this corresponds to a success event level) from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Failed to ping or bind to the Infrastructure Master FSMO role holder	This event generates a Warning alert when event 20007 with the severity level Warning from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Contacting the Infrastructure FSMO Role Holder has completed successfully	This event generates a Success alert when event 20007 with the severity level None (this corresponds to a success event level) from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Failed to ping or bind to the PDC FSMO role holder	This event generates a Warning alert when event 20011 with the severity level Warning from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Contacting the PDC FSMO Role Holder has completed successfully	This event generates a Success alert when event 20011 with the severity level None (this corresponds to a Success event level) from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Failed to ping or bind to the RID Master FSMO role holder	This event generates a Warning alert when event 20015 with the severity level Warning from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Contacting the RID Master FSMO Role Holder has completed successfully	This event generates a Success alert when event 20015 with the severity level None (this corresponds to a Success event level) from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Failed to ping or bind to the Schema Master FSMO role holder	This event generates a Warning alert when event 20019 with the severity level Warning from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Contacting the Schema Master FSMO Role Holder has completed successfully	This event generates a Success alert when event 20019 with the severity level None (this corresponds to a Success event level) from the AD Op Master Response script occurs. The alerts are suppressed on the following fields: Alert Description, Severity, Source Name, Event Number, Computer, and Logging Domain.
Op Master Domain Naming Last Bind - Threshold Exceeded	This rule generates a critical Error alert when the average of the ActiveDirectoryMP/Op Master Domain Naming Last Bind counter over the last five samples exceeds 30. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average of the ActiveDirectoryMP/Op Master Domain Naming Last Bindcounter over the last five samples exceeds 15. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates a Warning alert when the average of the ActiveDirectoryMP/Op Master Domain Naming Last Bindcounter over the last five samples exceeds 5. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
Op Master Infrastructure Last Bind - Threshold Exceeded	This rule generates a Critical Error alert when the average of the ActiveDirectoryMP/Op Master Infrastructure Last Bind counter over the last five samples exceeds 30. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average of the ActiveDirectoryMP/Op Master Infrastructure Last Bind counter over the last five samples exceeds 15. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates a Warning alert when the average of the ActiveDirectoryMP/Op Master Infrastructure Last Bind counter over the last five samples exceeds 5. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
Op Master PDC Last Bind - Threshold Exceeded	This rule generates a Critical Error alert when the average of the ActiveDirectoryMP/Op Master PDC Last Bind counter over the last five samples exceeds 30. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average of the ActiveDirectoryMP/Op Master PDC Last Bindcounter over the last five samples exceeds 15. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. - Or - This rule generates a Warning alert when the average of the ActiveDirectoryMP/Op Master PDC Last Bind counter over the last five samples exceeds 5. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
Op Master RID Last Bind - Threshold Exceeded	This rule generates a Critical Error alert when the average of the ActiveDirectoryMP/Op Master RID Last Bind counter over the last five samples exceeds 30. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average of the ActiveDirectoryMP/Op Master RID Last Bindcounter over the last five samples exceeds 15. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates a Warning alert when the average of the ActiveDirectoryMP/Op Master RID Last Bind counter over the last five samples exceeds 5. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
Op Master Schema Last Bind - Threshold Exceeded	This rule generates a Critical Error alert when the average of the ActiveDirectoryMP/Op Master Schema Last Bind counter over the last five samples exceeds 30. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. – Or – This rule generates an Error alert when the average of the ActiveDirectoryMP/Op Master Schema Last Bind counter over the last five samples exceeds 15. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain. - Or – This rule generates a Warning alert when the average of the ActiveDirectoryMP/Op Master Schema Last Bindcounter over the last five samples exceeds 5. The alerts are suppressed on the following fields: Alert Source, Computer, and Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Topology Discovery

The AD Topology Discovery script collects information about the site link replication topology. The information that is collected by this script is displayed in the Site Links replication topology diagram.

Parameters

There are no parameters for the AD Topology Discovery script.

Permissions

For the AD Topology Discovery script to run successfully, the Management Server Action Account must be a member of the Administrators group. The Management Server Action Account is the security context (provided by MOM) that ADMP scripts are run in on remote computers.

How the Script Works

The AD Topology Discovery script performs site link discovery by first creating collections for the following types of objects:

• Domain Controllers

• Sites

• Global Catalogs

• AD Site Link relationships

• Group-Computer relationships

The script uses ADSI to search for all sites under the CN=Sites,configuration naming context object in Active Directory with the filter (objectCategory=Site).

Detecting servers in each site

This script creates an object instance in the Sites collection for each site that it finds, and it creates a Site-DC, a Site-Bridgehead, and a Site-Computer collection for the site. Under each site object, the script searches for all the objects matching objectCategory=server.

The script then creates an object instance in the Domain Controllers collection, the Site-DC collection, the Site-Bridgehead collection (if the domain controller is a preferred bridgehead server for the site), and the Site-Computer collection for each domain controller that is returned. It also creates a relationship instance for the Group-Computer relationship, has its source set as Windows Domain Controllers with the target being the server name, and adds it to the appropriate collection.

If the domain controller is a global catalog, the script also creates a global catalog instance and adds it to the global catalog collection.

Detecting site subnets

After this script discovers all the domain controllers in the site, it searches for the subnet of the site by querying under CN=Sites,configuration naming context using the filter (&(objectCategory=subnet)(siteObject=distinguishedNameOfCurrentSite)). The first five subnets that are returned (or fewer, if fewer subnets are returned) are concatenated to look like the following:

172.31.3.0/24

172.31.48.0/24

172.99.48.0/22

If more than five subnets are returned, "..." is appended to the subnet list. After the script constructs the subnet string, the string is set as the Subnets attribute on the current site instance.

Site ISTG configuration

This script discovers the Inter-site Topology Generator (ISTG) for the current site by querying below the site object with the filter (intersiteTopologyGenerator=*). If the options attribute of the returned object AND 1 is equal to 1, the ISTG Enabled attribute of the current site instance is set to No and the ISTG Role Holder attribute is set to None. If the options attribute of the returned object AND 1 is not equal to 1, the ISTG Enabled attribute is set to Yes and the ISTG Role Holder attribute is set to the CN of the parent of the object that is returned in the search. After the script performs site ISTG configuration for each site, it discovers the site links.

Site link discovery

This script searches for site links under the CN=Inter-site Transports,CN=Sites,configuration naming context object using the filter (objectCategory=siteLink). For each site link that is detected, the script checks the isDeleted attribute. If the isDeleted attribute is set to False (or if the attribute does not exist), the script obtains the parent object of the site link and stores the CN as the transport type.

The script creates an array by parsing the schedule and loading the siteList attribute into an array. For each pair of items in the array, a SiteLink instance is created for the AD Site Link Relationships collection.

For example, if there are three values in the siteList attribute (Site1, Site2, and Site3), the following SiteLink instances are created:

• Site1-Site2

• Site1-Site3

• Site2-Site3

  Note

  Site links are not directional; therefore, the script will not create site links instances in the other direction (Site2-Site1, Site 3-Site2, and so on).

The script sets the replInterval attribute on each instance, constructs a schedule, sets the Transport, and sets the site name before adding each instance to the collection.

The script then creates a Naming Context collection and enumerates all the naming contexts in the Configuration container, using the filter ‘(&(objectCategory=crossRef)(!(|(cn=Enterprise Schema)(cn=Enterprise Configuration))))’. For each object that is returned, a Naming Context instance is created and the following properties are set on it:

• NCName

• DNSRoot (This might have multiple values.)

The operations master role holders for each naming context are then discovered. For each naming context/operations master role pair (only the RID master, PDC emulator, and infrastructure master are considered), a relationship collection is created. (Application directory partitions do not have either a PDC emulator or a RID master; therefore, these roles are skipped.) An instance is added to each collection, with the source being the computer that holds the operations master role and the target being the naming context.

Relationship collections are then created for the domain naming master and the schema master. (These operations master roles are forest-wide, not domain-wide.) An instance is created in each collection that identifies the operations master role holder.

Finally, the script submits the data to MOM.

Events

The AD Topology Discovery script generates the events in the following table.

Event Number	Purpose
24000	This event is logged to indicate that there might be a problem with the Site Link replication topology diagram because the script was unable to fully discover site link topology.
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed running successfully. It is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule. The script will not execute.
20098	This event is logged to indicate that ADMP does not run in agentless mode.

Rules

The AD Topology Discovery script generates alerts through the threshold rules in the following table.

Rule	Description
Topology discovery did not fully discover topology - the Site Link diagram may be incomplete	This rule generates an Information alert from event 24000. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
The Active Directory Management Pack does not support the agentless management mode	This rule generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Remote Topology Discovery

The AD Remote Topology Discovery script collects information about connection object health and replication topology for each domain controller. The information that is collected by this script is displayed in the Connection Objects and Broken Connection Objects replication topology diagrams.

Parameters

There are no parameters for the AD Remote Topology Discovery script.

Permissions

For the AD Remote Topology Discovery script to run successfully, the Agent Action Account must have Read access to the Configuration container.

How the Script Works

The AD Remote Topology Discovery script discovers the connection objects between domain controllers by first creating a dictionary that it will use to store the connection objects after they are discovered and by obtaining the name of the local domain controller.

This script uses ADSI to perform a search of the Configuration container on the local domain controller using the filter (&(objectCategory=Server)(CN=LocalComputerName)), where LocalComputerName is the name of the local domain controller. The script then constructs a second query using the ADsPath of the server that is returned in the previous query as the root for the search with a filter of (objectCategory=ntdsConnection), which returns all of the incoming connection objects for the local domain controller.

For each connection object that is returned, the object that is identified by the fromServer attribute is bound to, and its parent object is obtained. The parent object is the domain controller that the connection object is coming from. If the domain controller does not exist in the local domain controller's dictionary of connection objects, a structure is created and added to the dictionary using the domain controller's name as the key. If the domain controller does exist, the structure is received from the dictionary. The following information is recorded for each connection object:

• The CN (canonical name) of the parent of the object that is identified by the fromServer attribute

• The options attribute

• The mS-DS-ReplicatesNCReason attribute

• The transport type. (If the TransportType attribute starts with CN=SMTP, the SMTP is stored; otherwise, IP is stored.)

After the script enumerates all connection objects, it uses the ReplProv WMI provider to enumerate all of the MSAD_ReplNeighbor classes on the local domain controller. If the ReplProv WMI provider is not installed, the script generates an error. The script continues to run, but data that is provided by the ReplProv WMI provider will not be available in the Connection Objects replication topology diagram.

The script then uses the SourceDsaCN property of the MSAD_ReplNeighbor class to retrieve the connection object structure from the dictionary for each replication neighbor that is returned by the ReplProv WMI provider. If the connection object structure does not exist, it is added. The script then sets the following properties on the structure:

• The name of the domain controller that is identified in the fromServer attribute (This is the SourceDsaCN.)

• The Connection State (If the ModifiedNumConsecutiveSyncFailures property of the MSAD_ReplNeighbor class instance is greater than 2, the domain controller state is changed to Error. If the value is 1 or 2, the domain controller state is changed to Warning.)

• The Consecutive Failures (set to the value of the ModifiedNumConsecutiveSyncFailures property of the MSAD ReplNeighbor class instance)

• The last successful replication time (the TimeOfLastSyncSuccess property — or Never, if the property happens to be 1/1/1601.)

After the script enumerates the MSAD_ReplNeighbors class instance, it creates two variables: one for Connection Objects and one for Broken Connection Objects. Then, it enumerates each structure in the dictionary and creates an instance in one of the variables. If the structure is in an error state, the script creates a Broken Connection Objects instance; otherwise, it creates a Connection Objects instance.

The script then sets the following properties on the instance:

• The name of the domain controller that is identified in the fromServer attribute

• The Connection State

• The State color (Error = Red, Warning = Yellow; otherwise, the color is Green)

• Connection Style (Solid lines equal an intersite connection object; dashed lines equal an intrasite connection object.)

• The number of consecutive failures

• The last successful synchronization time

• The partitions that are held

• The transport type

• The manner in which the connection object was created; either manually or automatically by the KCC

After these properties are added to the instance, the script adds the instance to the appropriate collection.

Finally, the script creates a collection for the domain controller and an instance that is added to the collection to hold the properties so that the domain controller can be identified, making sure that the domain controller object exists in the MOM database. After this is complete, the script submits the information to MOM.

Events

The AD Remote Topology Discovery script generates the events in the following table.

Event Number	Purpose
21000	An error was encountered during execution of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and other errors. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20099	This event is logged to indicate that the script completed running successfully. It is logged only when the value of the LogSuccessEvent parameter is True.
20002	This event is logged to indicate that the script was not run by an event processing rule and that the script will not execute.
20098	This event is logged to indicate that ADMP does not run in agentless mode.

Rules

The AD Remote Topology Discovery script generates alerts through the threshold rules in the following table.

Rule	Description
The Active Directory Management Pack does not support the agentless management mode	This rule generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Replication Monitoring

The AD Replication Monitoring script monitors replication. Because replication can be difficult to monitor, the scripts, rules, and reports that ADMP provides are particularly important.

ADMP accomplishes the two most important goals for monitoring replication:

• Detecting replication problems

• Monitoring replication latency

The AD Replication Monitoring script performs the following tasks:

• Updates MOMLatencyMonitors objects

• Determines whether replication is occurring

• Calculates performance data for specified computers

• Records replication performance data

• Queries the ReplProv WMI provider to determine the state of each incoming connection object

This script runs periodically, based on a scheduled rule in the Active Directory Availability rule group. By default, this script runs once per hour. Each task in the script runs once per n runs of the script, where n represents a configurable parameter.

You must manually add the domain controllers for which you want the AD Replication Monitoring script to collect replication latency data to the Active Directory Replication Latency Data Collection - Sources and the Active Directory Replication Latency Data Collection - Targets computer groups.

Parameters

The AD Replication Monitoring script accepts the parameters in the following table.

Parameter Name	Description	Default Value
ObjectUpdateThreshold	The threshold beyond which the script assumes that either replication is not occurring or the script is not running on the other source domain controller.	24 (hours)
InterSiteMaxExpectedLatency	The expected maximum convergence time for replication to occur between any two domain controllers in the forest.	15 (minutes)
IntraSiteMaxExpectedLatency	The expected maximum time taken to replicate between any two computers within a site.	5 (minutes)
ChangeInjectionFrequency	Specifies how often a change is injected into the system. The change is injected into the system every nth time the script runs, where n is the value of the ChangeInjectionFrequency parameter. Note that the ChangeInjectionFrequency parameter is affected by how often the script is run. By default, the script runs once per hour so that the default settings cause an injection to occur once every six hours.	6
MonitorDomainNC	If the value of this parameter is True, the domain directory partition is monitored.	True
MonitorConfigNC	If the value of this parameter is True, the configuration directory partition is monitored.	False
MonitorApplicationPartitions	If the value of this parameter is True, allapplication partitions are monitored.	False
FirstReplicationPeriod	If the initial replication after a server becomes a domain controller does not occur within the specified number of hours, an alert is generated.	24 (hours)
LogSuccessEvent	If the value of this parameter is True, an event is generated every time that the script runs successfully.	False

Permissions

For the AD Replication Monitoring script to run successfully, at a minimum the Agent Action Account must be able to:

• Create container objects as children of CN=MOMLatencyMonitors.

• Read the attributes of all the objects that are created under CN=MOMLatencyMonitors.

• Write to the adminDescription attribute on the objects that are created under CN=MOMLatencyMonitors.

Create the MOMLatency container as a child container of the root of each domain and application directory partition that you are going to monitor. If an application directory partition crosses domain boundaries, provide the appropriate access to the Agent Action Account in each domain. If you are going to monitor the Configuration partition, create the MOMLatencyMonitors container as a child object of the Configuration partition as well.

Note

If you do not want to create the CN=MOMLatencyMonitors containers under the root of each partition manually, you must provide the Agent Access Account with the appropriate credentials to create the containers automatically.

How the Script Works

To determine the health of Active Directory replication, the AD Replication Monitoring script performs both of the following tasks:

• Creates or modifies its own directory objects, and follows the replication of the changes it makes to determine replication latency

• Queries the replication subsystem, through the WMI Replication Provider, to determine whether replication is occurring

Creating or updating a directory object

The AD Replication Monitoring script creates or updates its own directory objects in each directory partition that is monitored. Within each directory partition being monitored, the script periodically updates specific objects that uniquely identify each domain controller that holds a replica of the directory partition.

For each directory partition being monitored, a container called MOMLatencyMonitors (of the container object class) is created at the root of the partition. Each domain controller then writes its own object, which is named with the common name of the domain controller, into that container, and the domain controller is responsible for updating the adminDescription attribute of that object.

For example, for the configuration and domain directory partitions of the cohovineyard.com domain, these objects appear as follows:

DC=cohovineyard,DC=com 
CN=MOMLatencyMonitors 
CN=COHOVINEYARD-DC-01 
CN=COHOVINEYARD-DC-02 
CN=COHOVINEYARD-DC-03 
CN=configuration, DC=cohovineyard,DC=com 
CN=MOMLatencyMonitors 
CN=COHOVINEYARD-DC-01 
CN=COHOVINEYARD-DC-02 
CN=COHOVINEYARD-DC-03

Every monitored directory partition must support objects with an objectClass of container.

When this script runs, it finds its object in each of the directory partitions, and it updates the adminDescription attribute with the current date and time.

Note

The time stamp in the adminDescription attribute is stored in a UTC locale–independent format.

The frequency of this update is determined by the ChangeInjectionFrequency parameter. By default, this update occurs every sixth time the script runs, to limit the amount of replication traffic that the monitoring system creates. After the script updates its object, replication occurs, and the change is replicated to other domain controllers.

If the script cannot update its object, the script generates an event identifying the reason for the failure. Possible problems include insufficient permissions or simply an unexpected run-time error.

Determining whether replication is occurring

To determine whether replication is occurring, the AD Replication Monitoring script finds all the of the domain controllers in each MOMLatencyMonitors container in each of the monitored directory partitions, and it checks the values of their adminDescription attribute. When a change is made on a domain controller, the domain controller writes to the adminDescription attribute and includes a time stamp. The domain controller then replicates the change.

The value of adminDescription is checked in a number of different ways by the domain controller that receives the replicated changes. If the value of the time stamp in the adminDescription attribute is greater than the current time on the local domain controller, an event is generated that identifies a time skew problem. (If the clocks between two domain controllers are not synchronized, replication problems may occur that may invalidate the method of calculating replication latency.) If the value of adminDescription is older than the user-specified testing period that is provided in the script parameter ObjectUpdateThreshold, an event is generated to identify that the object has not been updated in this period of time.

If the domain controller being checked is in the same site as the local domain controller, and if the difference between the adminDescription attribute and the whenChanged attribute is greater than three times the user-defined intrasite threshold (which is supplied to the script through the IntraSiteMaxExpectedLatency parameter), an error is indicated, and an event detailing this error is generated. This process is similar for domain controllers in different sites, using the InterSiteMaxExpectedLatency script parameter. For details about how the difference between the values of the adminDescription and whenChanged attributes is used for performance data, see “Calculating performance data” later in this document.

If the difference between the values of the adminDescription and whenChanged attributes is within the applicable threshold, no events are generated. However, performance data can still be recorded.

Using data from the WMI Replication Provider, the script also checks whether the connection objects for the local domain controller are replicating correctly. A value for the attribute NumberOfConsecutiveFailures greater than or equal to 2 indicates an error condition. (Alerts are not generated when the value equals 1, to prevent the generation of alerts based on transient or one-time-only failures.) The value of this attribute and the value of the TimeOfLastSyncSuccess attribute are reported in an event as error parameters.

Illustrating replication monitoring

This section includes a series of three figures to illustrate how the AD Replication Monitoring script works. In the example, three domain controllers (DC-01, DC-02, and DC-03) are being monitored. The example assumes that the script runs at :00 minutes each hour. For simplicity, the figures show only the time values for the adminDescription and whenChanged attributes, even though these attributes actually contain both the date and time.

In the first figure, the three domain controllers are shown at 12:00 UTC, immediately after the script has made its first run. As shown in the following figure, the script has created one replication monitoring object on each domain controller. In the adminDescription attribute on each object, the script writes the time that the object was created. The whenChanged attribute reflects the time that the object was last updated. Because these objects are new, the two values are equal.

At 12:00 UTC, the script injects replication monitoring objects.

During the next hour (between 12:00 UTC and 13:00 UTC, replication between the three domain controllers occurs, as illustrated in the following figure.

Replication occurs.

The script makes its next hourly run at 13:00UTC. At this time, the script checks its monitoring objects, and it calculates replication latency for each monitoring object on each domain controller. The script calculates replication latency by calculating the difference between the values for whenChanged and adminDesc on each object, as shown in the following figure.

Replication latency is calculated.

In addition, the script checks that replication is occurring on all domain controllers by checking the age of the adminDescription value on each monitoring object. The script updates adminDescription on each monitoring object every sixth time the script runs. Therefore, an out-of-date value for adminDescription is a good indication that the source domain controller for that monitoring object is not replicating properly.

This script generates an alert if any of the following are true:

• The value of the adminDesc attribute on a monitoring object is older than the value for the ObjectUpdateThreshold parameter, which is one day by default.

• Intrasite replication latency for a monitoring object is greater than three times the threshold value of the IntraSiteMaxExpectedLatency parameter.

• Intersite replication latency for a monitoring object is greater than three times the threshold value of the InterSiteMaxExpectedLatency parameter.

Checking initial replication

The AD Replication Monitoring script also performs a check specifically to determine whether initial replication has completed in a timely manner. The script binds to each directory partition, and it reads the whenCreated and replUpToDateVector attributes on the directory partition object. If the replUpToDateVector attribute exists, the initial replication has succeeded, and no further action is taken. If the replUpToDateVector attribute does not exist and if the whenCreated attribute indicates that the directory partition is older (in hours) than the value that is represented by the FirstReplicationPeriod parameter, an alert is generated indicating that initial replication has not succeeded.

If a domain controller does not complete its initial replication, the domain controller will not advertise itself as a domain controller on the network. Monitoring initial replication helps ensure that domain controllers that are being created for shipment and installation in remote sites have been fully replicated — before shipment — and will therefore advertise themselves properly after being installed in the remote sites.

Collecting performance data

Because collecting replication latency performance data can generate a large amount of information, the AD Replication Monitoring script does not collect performance data by default. You can enable and disable performance data collection for each domain controller separately.

Enabling performance data collection

To enable performance data collection for a given domain controller, add that domain controller to either the Active Directory Replication Latency Data Collection - Sources computer group or the Active Directory Replication Latency Data Collection - Targets computer group.

Replication latency performance data is collected on all domain controllers in the Active Directory Replication Latency Data Collection - Targets computer group. Replication latency data is only generated (and collected) for replication from the computers in the Active Directory Replication Latency Data Collection - Sources computer group to the Active Directory Replication Latency Data Collection - Targets computer group. For example, if you want to collect replication latency data for replication from DC-01 to DC-02, add DC-01 to the Sources computer group and add DC-02 to the Targets computer group. If you want to collect replication latency data for replication from DC-02 to DC-01, add DC-02 to the Sources computer group and DC-01 to the Targets computer group.

The Update Replication Latency Perf Data Collection Flag (Sources) rule and the Update Replication Latency Perf Data Collection Flag (Targets) rule apply to these two computer groups by default. Each rule runs once per hour and sets the state variable ReplicationLatencyPerfDataFlag (for the Sources computer group) and the state variable ReplicationCollectionPerfDataFlag (for the Targets computer group) to the current date and time. These state variables are used solely by the AD Replication Monitoring script to determine whether to include a domain controller in the set of computers for which performance data is being collected.

Calculating performance data

When it runs, the AD Replication Monitoring script modifies the adminDescription attribute of the MOMLatencyMonitors object of each domain controller. The adminDescription attribute stores the current date and time. If the ReplicationLatencyPerfDataFlag state variable has a date and time that is no older than two hours, as the script updates the adminDescription attribute an extra flag is added indicating that the domain controller is included in the set of source domain controllers for which performance data is collected.

Note

The time stamp in the adminDescription attribute is stored in a UTC locale–independent format.

In calculating the difference between the adminDescription and whenChanged attributes, if the source domain controller is included in the set of source domain controllers for which performance data is collected, and the ReplicationCollectionPerfDataFlag state variable has a date and time that is no older than two hours, the replication latency performance data is collected by MOM.

When it is stored, the data is generated for the counter ReplicationLatency: NamingContext where NamingContext is replaced by the name of the directory partition being modified. The instance of the object is the name of the domain controller with which the replication latency is being calculated.

If performance data is being collected for three domain controllers, (DC-01, DC-02, and DC-03), and if DC-01 and DC-02 are in the Active Directory Replication Latency Data Collection - Sources computer group and DC-02 and DC-03 are in the Active Directory Replication Latency Data Collection - Targets computer group, and if both the configuration directory partition and the domain directory partition are being monitored, the performance information that is collected each day is similar to the information in the following table.

Domain Controller Name	Performance Instance
DC-01	Configuration:DC-02
DC-01	Configuration:DC-03
DC-02	Configuration:DC-03
DC-01	Domain:COHOVINEYARD:DC-02
DC-01	Domain:COHOVINEYARD:DC-02
DC-02	Domain:COHOVINEYARD:DC-03

Validating script parameters

The AD Replication Monitoring script validates script parameters to ensure that the value of the ObjectUpdateThreshold parameter is more than three times the value of the InterSiteMaxExpectedLatency parameter. In addition, the script checks that the value of the InterSiteMaxExpectedLatency parameter is greater than or equal to the value of the IntraSiteMaxExpectedLatency parameter. If any of these checks fail, an event is generated identifying the problem, and no further script processing occurs until the error is corrected.

Events

When the AD Replication Monitoring script detects a failure, either by querying the WMI Replication Provider or by detecting that an expected change has not replicated through the system, the script generates an event that provides details of the failure. If multiple problems are detected, the script generates events for each type of problem.

For example, if the WMI Replication Provider identifies that replication is not occurring through a connection object, this information is added to an event. If the script detects that the value of the adminDescription attribute has not been updated within a reasonable amount of time or that the value of the adminDescription attribute represents some time in the future, a different event is generated.

This script generates the events in the following table.

Event Number	Purpose
20001	This event does not trigger an alert, and it is generated when an attempt is made to configure a rule, other than an event processing rule, to run a monitoring script.
20061	This event is logged to indicate that the MOMLatencyMonitors object has not been updated in the last x hours. It is triggered when the difference between the value of a domain controller’s adminDescription attribute in a particular directory partition and the current time is more than the value in hours of the ObjectUpdateThreshold attribute. For any given execution of the script, each of the domain controllers in each directory partition being monitored is added to a single event.
20062	This event is logged to indicate that replication occurred but that it exceeded the specified thresholds — either intrasite or intersite, as applicable.
20063	This event is logged to indicate that a time skew has been detected. The value of the adminDescription attribute of one or more domain controllers is set to a time in the future, according to the local domain controller.
20066	This event is logged to indicate that the sanity check failed. One or more of the script parameters are configured in a way that the script does not support.
20067	This event is logged to indicate that an access error to the monitoring objects in one of the directory partitions has occurred.
20068	This event is logged to indicate that the WMI ReplProv component is not installed. This prevents the AD Replication Monitoring script from monitoring replication fully.
20069	This event is logged to indicate that the initial replication following the domain controller promotion is not complete.
20083	This event does not trigger an alert. It is generated when the script detects that a domain controller has not updated its MomLatencyMonitors object within the specified period. If this condition is detected, the script searches the directory to determine if the domain controller is still valid. If the domain controller is no longer valid, the MomLatencyMonitors object is deleted and the event is generated.
20099	This event is logged to indicate that the script completed running successfully. This event is logged only when the value of the LogSuccessEvent parameter is True.
21000	This event is logged to indicate that an unexpected run-time failure has occurred in the script.
20064, 20065	These events are logged to indicate that the WMI Replication Provider has detected that some or all of the replication partners for the local domain controller failed to replicate the last time that replication was attempted.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The rules that monitor the events generated by the AD Replication Monitoring script are explained in the following table.

Rule	Description
Script Based Test Failed To Complete	Generates a Warning alert from any event that is created by a script with the name AD* and event 21000. The alerts are suppressed on the following fields: Event Number, Computer, and Logging Domain.
One or more domain controllers may not be replicating	Generates a Warning alert when event 20061 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Domain, Source Name, and Event Number.
AD Replication is occurring slowly1	Generates a Warning alert when event 20062 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
AD Replication Monitoring - Time skew detected	Generates an Error alert when event 20063 of the severity level Error is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
Replication is not occurring - All replication partners have failed to synchronize	Generates an Error alert when event 20064 of the severity level Error is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
Some replication partners have failed to synchronize	Generates a Warning alert when event 20065 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, Event Number and Alert Description.
Invalid script parameter configuration	Generates a Warning alert when event 20066 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
AD Replication Monitoring - Access Denied	Generates a Warning alert when event 20067 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
WMI Replication Provider is not installed - Replication cannot be monitored fully.	Generates a Warning alert when event 20068 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
Initial replication after domain controller promotion has not completed	Generates an Error alert when event 20069 of the severity level Error is created by this script. The alerts are suppressed on the following fields: Computer, Domain, Source Name, and Event Number.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

1. If this alert generates an excessive amount of alert traffic in your environment, you can reduce the traffic it by clearing  the check box next to Computer on the Alert Suppression tab of the rule properties. For more information about configuring alert suppression see the Active Directory Management Pack Guide (https://go.microsoft.com/fwlink/?LinkId=38341).

AD Replication Partner Count

The AD Replication Partner Count script counts the number of replication partners for each domain controller. This script generates alerts if too many (or too few) replication partners exist for a domain controller, based on the replication topology.

Note

All searches that are described in the following sections are subtree searches, unless otherwise specified.

Parameters

The AD Replication Partner Count script is configured using the script parameters in MOM 2005 that are described in the following table.

Parameter Name	Default Value	Valid Range	What It Does
ConnectionsThresholdWarning	40	1 through 100	Indicates the number of replication partners (per domain controller) that are allowed before a Warning alert is generated.
ConnectionsThresholdError	50	* through 100	Indicates the number of replication partners (per domain controller) that are allowed before an Error alert is generated. If the value of the ConnectionsThresholdError parameter is not greater than or equal to the value of the ConnectionsThresholdWarning parameter, the value of the ConnectionsThresholdError parameter is set to the value of the ConnectionsThresholdWarning parameter.
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script completed successfully, which can be useful for debugging purposes.

Permissions

For the AD Replication Partner Count script to run successfully, the Agent Action Account must have Read access to the Configuration container.

How the Script Works

The AD Replication Partner Count initializes a global instance of an ADODB.Connection object (which is used to search the directory), binds to the rootDSE of the local computer; and stores the ConfigurationNamingContext and ServerName attributes. The script then binds to the local computer object using the ServerName attribute. The local computer object is used later in the script.

Then, this script determines the number of inbound connections to the local domain controller by binding to the CN=NTDSSettings,ServerName object, where ServerName represents the value that is read from the ServerName attribute. Because each child object within this object represents a connection object, the script counts the child objects. The number of child objects represents the number of inbound connections to this domain controller.

If no inbound connections exist, the script completes a search to determine whether multiple domain controllers exist. If multiple domain controllers exist, the script sets a flag indicating that this server has no inbound replication connections.

If multiple domain controllers exist, the script also counts the number of outbound connections for the local domain controller by counting the number of objects that are returned during a search of the CN=Sites container in the configuration directory partition, with a search filter of (&(objectCategory=nTDSConnection)(from Server=CN=NTDSSettings,ServerName)), where ServerName represents the value that is read from the ServerName attribute.

Note

The script counts the outbound connections for a domain controller by counting the number of inbound connections on other domain controllers that reference the domain controller currently being monitored.

If multiple sites exist, the script also checks that the current site has an inbound connection from at least one other site. To determine whether multiple sites exist, the script performs a search on the CN=Sites container in the configuration directory partition, with a search filter of (objectCategory=siteObject). The search has a scope of onelevel. The number of objects that are returned by the search represents the number of sites that exist.

When multiple sites do exist, the script constructs a search filter that includes (objectCategory=connectionObject). For each server in the local computers site, a clause is added: (fromServer*<>ServerDistinguishedName*), where ServerDistinguishedName represents the distinguished name of each of the domain controllers in the local computers site, including the local domain controller. This search filter is used to perform a subtree search on the CN=Sites container in the configuration directory partition. If the search returns one or more objects, at least one inbound connection to the site of the local domain controller exists.

After all these tests have been performed, the script generates the appropriate events. If multiple servers exist and either no inbound connections exist, no outbound connections exist, or there are no inbound connections to the local computers site, a replication island event is created indicating what the problem is. If there are more inbound or outbound connections than the specified threshold indicates are allowable, a Warning or Error alert (depending on which threshold is exceeded) is created.

Events

The AD Replication Partner Count script generates the events in the following table.

Event Number	Purpose
21000	The script encountered an error that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20080	This event is logged to indicate that a replication topology problem exists. The event description identifies what sort of problem exists: for example, a domain controller with no connection objects or a site that is not connected to any other site.
20081	This event is logged to indicate that the allowable number of replication connections has been exceeded. The event description indicates whether the number of allowed inbound or outbound connections has been exceeded.
20082	Indicates that the number of connections has grown too rapidly. The event description indicates how many new connections have been created since the script last ran.
20066	An invalid parameter was detected. The event description identifies the invalid parameters and how to correct the problem.
20002	The script was not started by an event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The events that are generated by the AD Replication Partner Count script are monitored by the rules in the following table.

Rule	Description
Script Based Test Failed To Complete	Generates a Warning alert from any event that is created by a script with the name AD* and event ID 21000. The alerts are suppressed on the following fields: , Event Number, Computer, and Logging Domain.
A domain controller has an extremely high number of replication partners	Generates an Error alert when event 20081 of the severity level Error is created by this script. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
A domain controller has an unusually high number of replication partners	Generates a Warning alert when event 20081 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
A domain controller has received a significant number of new replication partners	Generates a Warning alert when event 20082 of the severity level Warning is created by this script. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Replication Partner Op Master Consistency

The AD Replication Partner Op Master Consistency script determines whether domain controllers agree with one another on the identity of the domain controllers holding the operations masters roles.

Parameters

The AD Replication Partner Op Master Consistency script can be configured using the script parameter in following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished successfully, which can be useful for debugging purposes.

Permissions

For the AD Replication Partner Op Master Consistency script to run successfully, the Agent Action Account must have Read access to the Configuration container.

How the Script Works

The AD Replication Partner Op Master Consistency script creates an instance of the OOMADs COM object and calls OOMADs.GetDomainForDC, passing in the local computer name and receiving the domain name for the domain controller. The script then uses the COM object to retrieve all replication partners for the domain controller, and it determines the domain of each domain controller. If the domain of the replication partner and the domain of the local domain controller are not the same, only the identities of the schema operations masters and domain naming operations masters (as identified by the two replication partners) are compared. Otherwise, the identities of all operations masters (as identified by the two replication partners) are compared. If the replication partners identify different operations master role holders for one or more of the operations masters, the script generates an event indicating the conflicting operations master role (domain naming operations master, RID operations master, schema operations master, infrastructure operations master, and PDC emulator operations master) and the conflicting identities that are provided by the two replication partners. The OOMADs COM object is then used to determine which computer holds each operations master role.

Events

The AD Replication Partner Op Master Consistency script generates the events in the following table.

Event Number	Purpose
21000	An error was encountered during the running of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
20046	This event is logged to indicate that the script could not bind to the ADsPath that was returned by the COM object. ADsPath is used to identify one of the replication partners of the local domain controller.
20045	The COM object returned an empty string when it was queried for one of the operations master role holders.
20041	An inconsistency exists between the domain controller that the local domain controller identifies as holding a given operations master role and the domain controller that the replication partner identifies as holding that same operations master role.
20040	This event is generated only when the value of the parameter LogSuccessEvent is True. This event is generated only when the local domain controller and the replication partner agree on the identity of an operations master role holder.
20034	This event is logged to indicate that the OOMADs COM object returned an error while enumerating the replication partners for the local domain controller.
20002	This event is logged to indicate that the script was not run by an event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The events that are generated by the AD Replication Partner Op Master Consistency script are monitored by the following rules.

Rule	Description
Script Based Test Failed to Complete	Generates a Warning alert from any event 21000 that is created by a script with the name AD*. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
Two replication partners have an inconsistent view of the FSMO role holders	Generates an Error alert from event 20041 that is created by a script with the name AD Replication Partner Op Master Consistency. The alerts are suppressed on the following fields: Computer, Domain, and Event Number.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.

AD Server Moved Site

The AD Server Moved Site script determines whether the local domain controller has changed sites since the previous running of the script. This script generates an Information alert if the domain controller has changed sites.

Parameters

The AD Server Moved Site script can be configured with the parameter in the following table.

Parameter Name	Default Value	Valid Range	What It Does
LogSuccessEvent	False	True/False	Determines whether to log an event indicating that the script finished successfully, which can be useful for debugging purposes.

Permissions

For the AD Server Moved Site script to run successfully, the Agent Action Account must have Read access to the Configuration container.

How the Script Works

The script retrieves the site globally unique identifier (GUID) that was stored during the previous script run and stores it in the SiteGUID variable. The SiteGUID variable identifies the Site object in the directory in which the domain controller resided. The script binds to the rootDSE of the local domain controller and retrieves the ConfigurationNamingContext attribute. This attribute is then used to perform a search in the CN=Sites container in the configuration directory partition, with a search filter of (cn=LocalComputerName), which returns the ADsPath of the local computer object. If this search succeeds, the script binds to the ADsPath that is returned, which returns the local computer object in the directory. From this object, the Parent property is used to get the ADsPath of the parent object, which is the object that represents the site in which the local domain controller resides. The script also binds to the ADsPath of the parent object to read the GUID property. This GUID is compared with the SiteGUID that was retrieved earlier. If these GUIDs are different, the script attempts to find the original site by performing a search for all the sites in the configuration directory partition, binding to each site that is returned and comparing the site’s GUID with the SiteGUID that was retrieved earlier. After the site has been found (that is, when the GUIDs match), the name of the site is stored. If none of the GUIDs match, the original site is assumed to have been deleted. An event is then created indicating that the server has moved sites. The event description identifies the current site and the previous site of the local domain controller or indicates whether the previous site has been deleted.

If the original bind to the rootDSE fails, and if the Net Logon service is running, an event is created indicating that the bind failed and describing the reason for the failure. If the Net Logon service is not running, an event is created indicating that the bind failed because domain controller Locator is not running. The event also describes the error that was returned by the bind.

If the value of the LogSuccessEvent parameter is True, when the script completes it generates an event indicating the length of time the script took to complete.

Events

The AD Server Moved Site script generates the events in the following table.

Event	Purpose
21000	An error was encountered during the running of the script that the script does not specifically handle. This includes errors that are returned by the WMI provider, errors in binding to the rootDSE, and so on. The error message describes the operation that caused the error. It also provides the error number and, if possible, a description of the error.
22001	This event is logged to indicate that the computer object could not be found in Active Directory. This event can occur if the local domain controller is now just a member server (that is, Active Directory is not installed on it) but it is still running ADMP.
20036	This event is logged to indicate that the domain controller has changed sites. The event description indicates the original site and the current site for the domain controller.
20099	This event is logged to indicate that the script completed successfully, and it lists the length of time that the script took to run.
20002	This event is logged to indicate that the script was not run by an event processing rule and therefore it will not run.
20098	This event is logged to indicate that ADMP does not run in agent-less mode.

Rules

The events that are generated by the AD Server Moved Site script are monitored by the rules in the following table.

Rule	Description
Script - AD Server Moved Site	Causes the script to run (once per day, by default).
Script Based Test Failed to Complete	Generates a Warning alert from any event 21000 that is created by a script with the name AD*. The alerts are suppressed on the following fields: Source Name, Event Number, Computer, and Logging Domain.
The server has moved between sites	Generates an informational alert when the event 20036 is created by the AD Server Moved Site script. The alerts are suppressed on the following fields: Source Name, Event Number, Event Description, Computer, and Logging Domain.
The Active Directory Management Pack does not support the agentless management mode	Generates an Error alert from any event 20098. The alerts are suppressed on the following fields: Computer and Domain.