In most environments with Windows infrastructure, more than likely Active Directory has been implemented to handle the directory services. Considering the complexity of Active Directory with all of its moving parts (replication, logon services, time services, and Kerberos to name a few), it's fortunate that a domain controller can be instrumented to deliver the necessary information to monitor. The ADMP takes advantage of that to provide a robust monitoring environment for Active Directory.
The Active Directory management pack utilizes event logs, performance counters, and scripts to gather key points of data to understand the health of an Active Directory implementation. Early detection can help you find potential areas that need to be addressed before problems arise.
The Active Directory management pack consists of the following files:
MicrosoftWindowsActiveDirectory.akm
MicrosoftWindowsActiveDirectoryReports.xml
MicrosoftWindowsActiveDirectoryMPGuide.doc
MicrosoftWindowsActiveDirectoryMPTechRef.doc
As of this writing, the latest version number is 05.0.2642.0063. After downloading the management pack, extract the contents to a common location and follow the steps in Chapter 8 to import the management pack. After importing the management pack, check the version number against the version number stated in the Management Pack and Product Connector Catalog.
You can find additional detail on general configuration and an overview in MicrosoftWindowsActive DirectoryMPGuide.doc, while MicrosoftWindowsActiveDirectoryMPTechRef.doc contains detailed information on various rules, scripts, and tasks that come with the management pack. These documents can also be found online at http://www.microsoft.com/mom/techinfo/productdoc/default.mspx.
After importing ADMP, a few configuration parameters should be done to complete the setup of monitoring. The Active Directory management pack has rules that perform client-side activity to ensure that services are available from a client perspective. It also includes provisions for implementations across slow WAN links to reduce the amount of data gathered. You can also specify critical domain controllers to pull additional data from to assist in understanding latency.
As with the DNS MP, the ADMP requires an additional WMI provider called ReplProv. Windows Server 2003 comes with this provider by default. For Windows 2000 Server, ReplProv will have to be loaded. The file, ReplProv.msi, is in the MOM installation files under the Support Tools directory.
The Active Directory management pack doesn't use the regular attributes and formula evaluations such as the Base OS or DNS MP. It uses Discovered Groups instead. For that reason, the MP doesn't require any attributes. Only the Active Directory Trust Monitoring Group uses formula evaluation. Using the Search for Computers tab to pick up Domain Controllers and the Formula tab to pick up Windows 2003 Server, it populates its membership with Windows 2003 Servers that are Domain Controllers.
The Computer Groups listed (except for Active Directory Trust Monitoring) are empty and designed to be populated by the administrator. Any computers that are added to the Active Directory Client Side Monitoring will instruct the agent to run the AD Client Side Monitoring Pack (a subset of rules of the ADMP). Adding in computers to this group, which are either the Exchange servers themselves, or a computer near the Exchange server, gives the best simulation of how Domain Controllers may be responding to Exchange requests.
Latency Data Collection groups provide additional data collection for richer, detailed reporting and graphing. Both sources and targets need to be specified for this to work. Be careful how many DCs you add to these groups. This can generate a lot of data. The rough calculation is source DCs multiplied by target DCs. If there are 5 sources and 5 targets, you would have 25 data collections per interval. Because the intervals are per hour, that's 600 data collections a day.
To use this management pack in situations where DCs are connected via low bandwidth, the Reporting Rules can be disabled. In order to do this, disable the child Rule Groups in the following sections:
Active Directory Windows 2000/Reporting Rules for Active Directory
Active Directory Windows 2000 and Windows Server 2003/Reporting Rules for Active Directory
Active Directory Server 2003/Reporting Rules for Active Directory
The ADMP uses the Network Administrators group as its default Notification Group.
Computer Groups | Active Directory Client Side Monitoring |
Active Directory Trust Monitoring | |
Active Directory Replication Latency Data Collection: | |
Sources | |
Active Directory Replication Latency Data Collection: | |
Targets | |
Notification Groups | Network Administrators |
In this section, we cover a sundry of scripts that contain parameters from the ADMP. Details on a few of the other scripts (mainly related to discovery) are in the Tech Reference mentioned earlier in the "Installation" section. The format of the following sections will include a brief description of the script, followed by a table that includes the names, descriptions, and default values associated with the script. The goal of this section is to provide some detail on what these scripts do and to help you understand how they support the management of your AD infrastructure.
The first portion of this section covers the Active Directory Client Side Monitoring scripts. There are five scripts that have various settings that can be adjusted to meet the requirements of your organization.
AD Client Connectivity instructs the agent to contact each domain controller (specified by AD Client Update DCs) and performs the following tests: ICMP Ping, connect to SYSVOL, LDAP Ping, and ADSI bind followed by a search.
Name | Description | Value |
---|---|---|
BindThreshold | Specifies the threshold of the length of time a bind should take | 500 |
FailureThreshold | Indicates how many times the Bind Threshold can be breached before triggering an event | 3 |
LogSuccessEvent | Logs event for successful script execution | False |
SearchThreshold | Specifies the threshold of the length of time a search should take | 500 |
This script connects to an available GC and performs a bind followed by a search. It does this for all GCs it has been instructed to contact. Assuming it cannot contact at least 1 GC (as defined by default), it will generate an event.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
MinimumAvailableGCs | Indicates how many GCs must be reachable, at a minimum | 1 |
PDC Response script checks the PDC Emulator Master to make sure the DC is available. If it fails more than the FailureThreshold, an event is generated. If a check comes back successfully, on the next execution, the script checks the SuccessCount interval and determines from it how many tests to skip.
Name | Description | Value |
---|---|---|
FailureThreshold | Indicates the number of consecutive failures before triggering an event | 3 |
LogSuccessEvent | Logs event for successful script execution | False |
SuccessCount | Indicates how many times to skip the next test run on successful completion of a test | 1 |
This performs a serverless bind to RootDSE. It retrieves the name of the DC and determines if the DC is in the management site of the agent.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
The first parameter to modify in this script is SiteDiscoveryMode, which indicates the other parameters that must be filled out. SiteDiscoveryMode uses the following values:
1: Monitor all of the DCs in the domain that the agent exists. Define the Domains parameter.
2: Monitor all of the DCs in a particular site. Define the Sites parameter.
3: Monitor all of the DCs in the site that the agent exists. No values need to be defined as the script will discover the DCs that reside in the same site as the agent.
4: Monitor only specific DCs. Define the DomainControllers parameter.
Name | Description | Value |
---|---|---|
DomainControllers | List of Domain Controllers to monitor (comma delimited) | |
Domains | List of domains to monitor (comma delimited) | |
LogSuccessEvent | Logs event for successful script execution | False |
SiteDiscoveryMode | Specifies discovery mode for Domain Controllers | 3 |
Sites | List of sites to monitor (comma delimited) |
This next portion covers the other scripts in the ADMP. The scripts listed here control the various Domain Controller health checks.
This script monitors a Domain Controller's use of CPU by focusing on the LSASS process. The three parameters, LSASSThreshold, NumSamples, and MaxFrequency, help to suppress unnecessary alerts. The NumSamples value tells MOM how many values to use to create the average usage that LSASSThreshold looks at. The MaxFrequency value will cause the script to exit out if an alert has already been generated in the timeframe of this value. In other words, if MaxFrequency is 15 minutes, then an alert will generate once every 15 minutes, no matter how often the same condition may be detected during that 15-minute timeframe.
Name | Description | Value |
---|---|---|
LSASSThreshold | Average CPU usage for LSASS must remain above this value to indicate a problem. | 80 |
NumSamples | Number of samples to use for average value. | 10 |
MaxFrequency | Specifies the frequency (in minutes) to generate alerts. | 15 |
LogSuccessEvent | Logs event for successful script execution. | False |
As this script sounds, it checks for adequate drive space (at least 20 percent of the database size or 500MB—whichever is greater). It also checks for the last sampled value and the current sampled value to see if excessive growth has occurred. Excessive growth is considered a value of 20 percent or more. This is the default value, which consequently is static and cannot be changed without altering the script itself directly.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
The only "verification" this script provides is to determine whether or not the domain is a single-label name. If it is, it performs an additional check to make sure that registration to a single-label domain is enabled.
Note | Single-label domains are not recommended for use in an Active Directory environment. |
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
This script checks to make sure the following services are running: Net Logon, File Replication Service, Intersite Messaging, Kerberos Key Distribution Center, and Windows Time. Additionally, it also checks to ensure that SYSVOL is accessible by accessing //127.0.0.1/SYSVOL, and that the DC Locator Service is running by querying for a DC. If the query returns a name other than itself, it generates an alert. There are no parameters to adjust in this script.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
This script performs two examinations. First, it attempts a serverless bind to RootDSE. If the bind fails enough times to breach the FailureThreshold, an event is created. If the bind succeeds, the script measures the bind time.
Name | Description | Value |
---|---|---|
FailureThreshold | Number of failures (consecutive) before alert is created | 4 |
LogSuccessEvent | Logs event for successful script execution | False |
This script performs an actual query to the Global Catalog and measures the response time. It's not recommended that the Query parameter be changed because of the requirements for information that the query has to return. It must return at least one object so that the query issued is valid. Furthermore, it shouldn't return very many objects so that the query response is quick.
Name | Description | Value |
---|---|---|
FailureThreshold | Number of failures (consecutive) before alert is created | 4 |
Query | LDAP filter to use to query GC | (objectCategory = DMD) |
LogSuccessEvent | Logs event for successful script execution | False |
This simply counts the number of objects in the Lost and Found container. There are no parameters that can be changed in this script.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
Through the TrustMon provider, this script checks the available trusts to make sure they're healthy. This provider is not available for Windows 2000 Domain Controllers, and thus this script does not run on Windows 2000 DCs. Sounds like another reason to upgrade.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
This script is run as a response when events are found relating to No GC Logon functionality (Windows 2003 only). It picks up general information that may be useful to assist Domain Admins in troubleshooting.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
This checks the availability of the five FSMO roles (Schema Master, Domain Naming Master, Infrastructure Master, RID Master, and PDC Emulator) by performing a bind to each one. If the bind is successful, it measures the response time. The parameter SuccessCount suppresses additional testing following a successful test.
Note | Because of the importance of the PDC Emulator, this script checks the response of this FSMO role every time the script runs, regardless of the SuccessCount value. |
Name | Description | Value |
---|---|---|
FailureThreshold | Number of failures (consecutive) before alert is created | 4 |
SuccessCount | Number of times to skip the test if a successful execution has occurred | 3 |
LogSuccessEvent | Logs event for successful script execution | False |
The purpose of this script is to watch replication latency through synthetic transactions. This script creates a container at the root of every monitored partition called MOMLatencyMonitors. Each DC will create its own object in this container. The adminDescription attribute is updated (and examined) by this script.
The IntraSiteMaxExpectedLatency should closely resemble your environment. Alerts for slow replication aren't generated unless the replication latency is three times the value of this parameter for intrasite replication. InterSiteMaxExpectedLatency works in the same way.
The ChangeInjectionFrequency tells the script to update the value of the adminDescription attribute every sixth time the script runs.
Name | Description | Value |
---|---|---|
ObjectUpdateThreshold | Indicates how many hours to wait before generating an event indicating that a domain controller hasn't updated its respective object | 24 |
InterSiteMaxExpectedLatency | Expected replication convergence time (in minutes) between any two DCs in the same domain | 15 |
IntraSiteMaxExpectedLatency | Expected replication convergence time (in minutes) between any two DCs in the same site | 5 |
ChangeInjectionFrequency | Specifies how often a change is made to the adminDescription value | 6 |
MonitorDomainNC | Specifies whether to monitor the Domain partition | True |
MonitorConfigNC | Specifies whether to monitor the Config partition | False |
MonitorApplicationPartitions | Specifies whether to monitor the Application partition | False |
FirstReplicationPeriod | Specifies the length of time (in hours) that the first replication should complete after a DCPromo operation has been run | 24 |
LogSuccessEvent | Logs event for successful script execution | False |
Aside from generating an alert when potentially too many replication partners exist, this script also generates an alert when a replication island condition is detected.
Name | Description | Value |
---|---|---|
ConnectionsThresholdWarning | Breach of this threshold generates a Warning alert to indicate that there are a high number of replication partners | 40 |
Name | Description | Value |
---|---|---|
ConnectionsThresholdError | Breach of this threshold generates an Error alert indicating that there are a high number of replication partners | 50 |
LogSuccessEvent | Logs event for successful script execution | False |
Op Master Consistency checks a domain controller and its replication partners to determine if all of them return the same FSMO roles. If what the domain controllers understand to be the FSMO role holders are inconsistent, an event is generated.
Note | If the domain controllers are not in the same domain, then only the Schema Master and the Domain Naming Master roles are examined. |
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
If a domain controller changes sites, an Informational event is generated indicating that this has happened.
Name | Description | Value |
---|---|---|
LogSuccessEvent | Logs event for successful script execution | False |
The following table lists the available tasks in this management pack. It also states the context that the task runs in.
Task | Context |
---|---|
Replication Summary Snapshot | Agent |
Service Principal Name Health | Agent |
Enumerate Trusts | Agent |
Active Directory Users and Computers Snap-in | Console |
ADSI Edit | Console |
DCDiag | Agent |
LDP | Console |
Task | Context |
---|---|
NETDIAG | Agent |
NETDOM | Agent |
NLTEST | Agent |
REPADMIN | Agent |
SETSPN | Agent |
Note | If the tasks execute in the context of the agent, LocalSystem provides all necessary permissions. However, if the agent runs in least privilege configurations, it may require additional permissions to execute some of the tasks. All console tasks are executed under the permission of the user using the Operator Console. If the user doesn't ordinarily have the rights to execute the task, using the task may not work as expected. Many of the agent-executed tasks listed require the support tools to be installed on the agents. |