Microsoft Active Directory Management Pack Guide

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Active Directory Management Pack for Microsoft Operations Manager 1.0 SP1

Version 1.0

Developed by Windows Server Content Group

Click here to download a copy of this guide.

Acknowledgements

Program Manager: Paul Reiner

Writer: Andrea Weiss

Editors: Bonnie Birger, Jim Becker

Copy Editor: Jim Becker

Lab Staff: Robert Thingwold and David Meyer

Lab Partners: Hewlett-Packard and Cisco Systems

We thank the following people for reviewing the guide and providing valuable feedback:

Brenda Carter, Bulent Ozkir, Andrew Strachan

Overview of Active Directory Management Pack

Microsoft® Operations Manager (MOM) 2000 Active Directory Management Pack (ADMP) Service Pack 1 (SP1) provides a monitoring and management system for the Active Directory® directory service that is integrated with MOM. ADMP can help you to improve the availability, performance, and security of Active Directory implementation. With ADMP, MOM provides central monitoring and automatic problem resolution for large networks, continuously monitoring Active Directory components. By using ADMP, you can achieve the following benefits for your organization:

Improved reliability of your Active Directory implementation and the applications that rely on it.
Higher customer satisfaction and decreased help desk calls because problems are detected and solved before they affect users.
Increased service levels, due to improved reliability.

Microsoft provides many predefined, out-of-the-box solutions called Management Pack modules. Management Pack modules are ready-to-use components for monitoring and managing specific applications and environments, such as Microsoft® Exchange 2000 Server or Microsoft® SQL Server™ 2000. Management Pack modules provide predefined computer groups and processing rules, such as filters, alerts, and performance sampling and threshold rules. Management Pack modules also provide predefined computer attributes, providers, scripts, links to the Microsoft Knowledge Base, public views, and default notification groups. These elements integrate specialized research and expertise into your enterprise network.

ADMP monitors Active Directory and the services that it relies on to help maintain consistent directory data and the needed level of service throughout the forest. You can monitor important indicators to discover and resolve minor problems before they develop into potentially lengthy service outages. Using ADMP assures administrators that:

All necessary services that support Active Directory are running on each domain controller.
Data is consistent across all domain controllers, and end-to-end replication completes in accordance with your service level agreements (SLAs).
Lightweight Directory Access Protocol (LDAP) queries respond quickly.
Domain controllers do not experience high central processing unit (CPU) usage.
The central monitoring console collects all events that can adversely affect Active Directory.

ADMP monitors many significant Active Directory performance counters. Using performance thresholds and related alert definitions to highlight performance conditions that might indicate service problems or possible denial-of-service attacks, ADMP helps you to identify issues before they become critical. By increasing the security, availability, and performance of your Active Directory installation, ADMP helps reduce your cost of ownership by providing proactive Active Directory management.

For more information about MOM and other Management Packs, including installation and configuration, see www.microsoft.com/mom.

ADMP Features

ADMP SP1 monitors the performance, availability, and security of Active Directory. It provides a complete Active Directory monitoring solution by:

Monitoring all aspects of Active Directory health.
Monitoring the health of vital processes that Active Directory depends on, including NetLogon, File Replication service (FRS), Intersite Messaging service (ISM), Windows Time service, and Key Distribution Center (KDC).
Monitoring replication health.
Collecting key performance data.
Reporting on service availability and replication health.

By detecting, alerting on, and automatically responding to critical events, ADMP helps to indicate, correct, and prevent possible Active Directory service outages.

ADMP monitors events placed in the Application, System, and Directory Service event logs by different Active Directory components and subsystems. It includes key performance metrics to monitor the overall performance of Active Directory and to alert you to critical performance issues. Using MOM Reporting, you can analyze and graph this performance data to understand usage trends and to manage system capacity.

ADMP includes Active Directory–specific views that provide a quick snapshot of the health of your Active Directory implementation. ADMP contains 42 reports in the following key areas:

Active Directory discovery
Health monitoring and operational recovery
Replication monitoring
Operations

What´s New in ADMP SP1

ADMP SP1 provides significant improvements and additions to the original ADMP, including:

Dramatically improved health definitions
Support for all new Windows Server 2003 Active Directory features
Full context-sensitive Help for every alert, including most common causes of and suggested corrective actions for each alert
Simplified deployment for large enterprises, requiring only minimal configuration
Improved alert classifications, so that alerts can be paged to IT support personnel
Improved scripts that are more flexible and robust
A new Client Pack that provides scripts that simulate user activity for domain controllers to ensure availability from key locations in your environment
New Exchange 2000 Server awareness that ensures the availability of Active Directory for Exchange 2000 Server.

In addition, ADMP SP1 provides the following improvements in wide area network (WAN) and CPU usage:

New event consolidation logic reduces CPU usage of MOM Database Access Server/Consolidator/Agent Managers (DCAMs), load on the SQL database, and WAN utilization ten-fold.
New alert consolidation logic reduces alert volumes 100-fold.

Terms and Definitions

It is useful to know the following terms and definitions when deploying ADMP SP1:

ADMP A set of predefined rules that govern the monitoring of Active Directory.

ADMP Client Pack A set of predefined rules and scripts within ADMP that monitor Active Directory health from an external client computer. These rules run on the client computer, not on domain controllers.

ADMP error alert A message generated by ADMP that indicates that a problem requires attention. All alerts with a severity of Error or higher should be paged to IT support personnel and responded to immediately. All ADMP error alerts indicate that a failure has occurred.

ADMP event A low-level item of interest that ADMP collects from event logs or scripts. You can correlate ADMP events with ADMP alerts when you need to see more detailed information about an alert. ADMP reports also use ADMP event information. You can view ADMP events by using Event View in MOM.

ADMP informational alerts Messages generated by ADMP that indicate the success of a process or configuration action, such as "Promotion has succeeded." Informational alerts can be enabled by an operator when additional information is required for debugging scripts or tracking an operation.

ADMP warning alert A message generated by ADMP that indicates that a failure is pending but has not yet occurred. The message should be attended to within a reasonable amount of time, but it does not require immediate attention. However, ignoring warnings long enough will lead to errors that do require immediate attention. By default, warnings are not paged to IT support personnel.

MOM Design Architectures and ADMP

MOM is usually deployed in one of three different architectures, depending on your organization:

Single configuration group
Multiple configuration groups with multihomed agents
Multitiered configuration groups with alert forwarding

Each configuration has different consequences for the information that is available through ADMP. The following sections explain these configurations and consequences.

Single Configuration Group

This architecture represents the basic design for a MOM implementation. The single configuration group architecture is designed to optimize performance, balance the workload, and build in redundancy. A single configuration group can scale to monitor up to 2000 servers.

The typical topology for the single configuration group includes the following elements:

MOM database on a server running SQL Server 2000
One or more DCAMs (Multiple DCAMs provide load balancing, redundancy, and scalability.)
Up to 2000 agents
Optional reporting installation on a separate server
Optional Web server installation to provide Web console access

Figure 1 illustrates the topology of the single configuration group.

Figure 1: Topology of a Single Configuration Group

Figure 1: Topology of a Single Configuration Group

The elements of this design include a dedicated OnePoint database (SQL01), two DCAMs (DCAM01 and DCAM02), and agents (S01 through S04). The agents report to a primary DCAM, represented in Figure 1 by a solid line. These agents are also configured to report to a secondary, redundant DCAM, represented in Figure 1 by a dotted line.

During installation, ADMP writes rules into the OnePoint database. The DCAMs and agents receive the new rules at the next heartbeat interval.

This is the simplest configuration to deploy and support, and it is also the recommended configuration. In this configuration, all ADMP features are available.

Multiple Configuration Groups with Multihomed Agents

This architecture implements multiple configuration groups based on the single configuration group design. However, this design incorporates multihomed agents, allowing agents to report to up to four configuration groups. Use this architecture to distribute monitoring requirements across specialized groups, such as security, Active Directory, or Exchange 2000 Server. This allows separate IT groups to monitor different aspects of the same server.

The topology of the multiple configuration groups with multihomed agents includes the following elements:

Up to four configuration groups
Configuration groups based on the single configuration group architecture for optimal performance, load balancing, and redundancy
Single or multihomed agents

Figure 2 illustrates the topology of multiple configuration groups with multihomed agents.

Figure 2: Topology of Multiple Configuration Groups with Multihomed Agents

Figure 2: Topology of Multiple Configuration Groups with Multihomed Agents

This design includes multihomed agents (S01 through S04) that report to more than one configuration group. However, not all agents are required to be multihomed. For simplicity, Figure 2 shows only one DCAM per configuration group. However, all configuration groups should include at least two DCAMs for redundancy and load balancing.

Organizations might choose to deploy multiple configuration groups for the following reasons:

The IT groups that manage Exchange 2000 Server and Active Directory cannot agree on certain deployment or support issues, such as the size of the database, the length of time to retain historical data, or how to administer the systems. Having several configuration groups allows each IT group complete autonomy.
This configuration is used to test new rules on the same shared domain controller. It is commonly used when an IT group needs a larger OnePoint database and is willing to fund it.

ADMP fully supports this configuration with the following restrictions:

If ADMP is installed into multiple configuration groups, each installation of ADMP must be the same version.
Because ADMP reports are based on data from the OnePoint database, some reports generated in this configuration do not span configuration groups. The discovery reports are generated from the directory, not from the OnePoint database.

Multitiered Configuration Groups with Alert Forwarding

This architecture maintains centralized monitoring while scaling a MOM implementation to up to ten configuration groups. Multiple zone configuration groups, each based on the single configuration group architecture, forward alerts to a single master configuration group for centralized management. Use this architecture to scale beyond the limitations of a single configuration group. This architecture can also be used to scale across geographical regions or across security boundaries.

The topology of the multitiered configuration group with alert forwarding architecture includes the following elements:

Configuration groups based on the single configuration group architecture for optimal performance, load balancing, and redundancy
A centralized master configuration group
Up to 10 zone configuration groups with alert forwarding to the master configuration group

Figure 3 illustrates the topology for multitiered configuration groups with alert forwarding.

Figure 3: Topology of Multitiered Configuration Groups with Alert Forwarding

This design includes two zone configuration groups forwarding alerts to a central master configuration group. The master configuration group does not monitor agents directly.

ADMP fully supports this configuration with the following restrictions:

If ADMP is installed into multiple configuration groups, each installation of ADMP must be the same version.
You can run reports on the OnePoint database in the Master configuration group, but this database contains only the data that is forwarded by the zone configuration groups. These reports reflect the composite data from all zone configuration groups.
The Active Directory replication latency script must have identical parameters on all configuration groups.

Note: In multitiered configuration groups, all rules should be identical in all configuration groups to prevent confusion by operators.

ADMP Deployment and Operations

The process for deploying ADMP SP1 involves the following steps:

Test ADMP in a lab environment.
Pilot ADMP.
Deploy ADMP.

After your deployment is complete, there are tasks that you perform on a regular basis using ADMP. These tasks fall into the following categories:

The tasks you perform on a regular basis with ADMP to monitor Active Directory
The tasks you perform on an as-needed basis with ADMP during routine maintenance

Testing ADMP

It is important to test your ADMP deployment. Depending on the needs of your organization, you configure varying levels of monitoring, some of which can cause excessive network traffic or CPU usage. You can change thresholds and configure settings in a test environment without causing disruption to users.

There are two approaches that you can use to test a management pack:

Build a test lab that is a reduced scale of your production environment, and ensure that this test lab is isolated from your production environment. This approach allows you to test the management pack without impacting your production environment. However, this approach requires a significant investment in hardware to replicate the agent scenarios.
Build a test configuration group that is separate from any other MOM configuration groups, and then multihome agents that are in your production environment. This provides the advantages of testing the management pack with agents in a production environment, without impacting other MOM configuration groups that are used for production. However, this approach requires that you coordinate agents that are multihomed. While this approach provides a more accurate view of the data that is collected on agents, it increases the amount of data that is sent through your production network.

If you are already using ADMP in your production environment and you are upgrading to ADMP SP1, decide if you want to retain custom content that you have entered into the knowledge base (KB). If so, export a copy of ADMP from your production environment, and then import it into your test configuration group. After importing the customized management pack, upgrade the management pack using the MOM SP1 CD. Be sure to select the option to retain your custom, company-entered KB.

In the test environment, perform the following tasks:

Test the sizing of the DCAM and SQL server. Simulate the production load as much as possible in your test environment.
Become familiar with the day-to-day procedures that are required for operations with ADMP SP1 in your environment. During this effort, determine the personnel requirements for operations tasks such as viewing alerts, updating status, and closing alerts. Develop processes for handling alerts.
Develop a regular reporting cycle with the reports that are most useful to your organization. See Appendix A for a complete list of reports.
Develop and test your deployment or upgrade process for ADMP SP1. Determine the process for how you will deploy the agent and management pack to all servers in your environment.
Develop and test any custom thresholds for your environment. You can test ADMP SP1 rules by using the Logevent.exe event logging tool to simulate events from the event logs. At a command prompt, type the following command, and then press ENTER:

logevent.exe -m \<computer name> -s <severity> -r “<source>” -e <event ID> “<event text>”

Test paging and e-mail notification.
Test the minimum credentials that are required by MOM to run properly.
Assess any impact that ADMP SP1 might have on WAN usage and CPU load on domain controllers.
When deploying ADMP SP1 in your test environment, copy all custom rules from your previous installation to another folder under the Processing Rule Groups folder, such as My Custom Rules. In the MOM console, right-click the old folder, click Properties, clear the Enabled check box, and then click OK.

Important: Never move rules to another folder. Instead, always copy rules from one folder to another. This gives the rules a new globally unique identifier (GUID), whereas moving the rules retains the old GUID, which can result in unexpected behavior.

Most likely, the added functionality in ADMP SP1 will make your old custom rules obsolete so that you will not need to reenable them. If, however, your testing reveals that your custom rules are still necessary, you can reenable the Custom Rules folder. In the MOM console, right-click the Custom Rules folder, click Properties, select the Enabled check box, and then click OK.

After testing ADMP, export a copy of the management pack to preserve the modifications you made as a result of the testing process.

Piloting ADMP

You can use an ADMP SP1 pilot program to validate your configuration choices against live data in your pilot environment. Based on the results of your pilot program, you can make any necessary adjustments to your configuration before deploying ADMP SP1 throughout the rest of your production network. In this selected area of your production environment, verify that everything that you test in the lab is working properly. Be sure to import the version of the ADMP that you exported at the completion of the formal test process. Perform the following steps:

Verify that the sizing of the DCAM and SQL server are sufficient for your production load.
Verify operations processes and personnel requirements.
Verify the reports that are required.
Verify the deployment or upgrade process for ADMP SP1.
Verify custom thresholds for your environment.
Verify that paging and e-mail notification is working properly.
Verify that the credentials that MOM is using are sufficiently privileged to run properly, without being over-privileged.
Verify WAN usage and CPU load on domain controllers by ADMP SP1.

After you complete your pilot testing, export the ADMP to back up the changes that are made to the management pack.

Deploying ADMP

Deploying ADMP SP1 involves the following steps:

Deploy MOM.
Install ADMP.
Configure ADMP.
Perform initial triage.

Deploying MOM

Deploy MOM using the best practices and guidelines provided in the MOM Deployment Guide on www.microsoft.com/mom.

Installing ADMP

When you install ADMP into your production environment, verify that you are installing the version of the management pack resulting from your pilot testing. Do not install ADMP directly from the MOM CD into your production environment. If you are upgrading to ADMP SP1, choose the option to replace the existing ADMP entirely. This ensures that the version of ADMP that you are running in production is the same version that you verified through your testing and piloting phases.

Note: Always back up ADMP before upgrading. The MOM installation wizard will prompt you to do this.

Merging management packs is no longer supported by MOM, because this can lead to inconsistent results. If you have made significant modifications to your management pack that you want to retain, copy those modifications to a custom folder entirely outside the ADMP before installing it.

Important: You must copy and not move the custom rules to another location, so that the custom rules have a different GUID.

Configuring ADMP

The initial configuration of ADMP includes the following tasks:

Set the replication latency intersite threshold.
Specify domain controllers for data collection. (Optional)
Configure settings for slow WAN links or large branch office configurations. (Optional) For more information about configuring these settings, see Appendix B: Configuring Settings for Slow WAN Links or Large Branch Office Deployments.

Setting the Replication Latency Intersite Threshold

The maximum intersite replication latency is the maximum amount of time a change takes to replicate across the entire forest. Meet with your system architect to review what the expected maximum value is. Usually, this value is closely monitored to ensure that any applicable SLAs for your organization are being met. The most common scenario for this is to ensure that common help desk procedures, such as resetting passwords, replicate from the corporate headquarters to the branch office within a reasonable amount of time, as determined by the SLA.

Monitoring the maximum latency for the forest also ensures that all domain controllers are receiving updates. Failure for even one domain controller to receive updates in a timely manner can have significant negative results. If you receive frequent errors in ADMP after correctly setting this threshold, you are probably not meeting your SLA requirements. The most common reason for this is incorrectly set site schedules.

Set the intersite maximum latency value to the SLA value, in minutes. If you have an SLA, you should set the intersite maximum to one-third of the SLA or your maximum expected replication time across your forest, whichever is smaller.

To set the intersite replication latency value

In the MOM Administration Console, expand Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows 2000 (enabled), Active Directory Availability (enabled), Active Directory Availability (shared) (enabled).
Click Event Processing Rules.
In the right pane, double-click Script - AD Replication Monitoring.
On the Responses tab, select the script named AD Replication Monitoring, and then click Edit.
In the list of event parameters, double-click Intersite Expected Maximum Latency .
Enter the value (in minutes) for the maximum expected replication latency between domain controllers.
Click OK. Click OK again in the Launch a Script dialog box.
Click OK to exit the property page.
Expand Rules, Processing Rule Groups.
Right-click Rules, and then click Commit. This process takes about 10 minutes.

Specifying Domain Controllers for Data Collection

In this step, you add to ADMP the names of the domain controllers for which you want to collect data for detailed trending analysis. This is very useful for graphing replication performance between critical domain controllers, and it is required for the AD Replication Latency report.

Note: The data collected for detailed trending analysis can be large. The amount of data collections is roughly equal to the square of the number of domain controllers that you specify. For example, if you specify 10 domain controllers, you will receive approximately 100 data collections per interval.

To specify domain controllers for data collection

In the MOM Administration Console, expand Rules, Computer Groups.
Double-click Active Directory Replication Data Collection.
On the Included Computers tab, select the computers that you want to include in detailed performance trending.
Expand Rules, Processing Rule Groups.
Right-click Rules, and then click Commit.

Note: It can take up to 24 hours for data to start collecting.

Performing Initial Triage

After the initial deployment, allow 24 hours for the ADMP scripts to run (some of the scripts run in real time, and others run at scheduled intervals of up to 24 hours). At this point, ADMP starts displaying alerts in the All Open Alerts view. The number and severity of alerts depends on the thresholds that you set earlier, as well as the number of domain controllers and existing problems in your Active Directory implementation.

To perform initial triage after deploying ADMP

View alerts. Perform the following steps to list all alerts in the forest on one screen:
1. Right-click the Monitor icon.
2. Select Find Alerts.
3. Click Alerts that are not resolved.
4. Click Next until there is a screen with a Finish button, and then click Finish.
Resolve alerts:
1. To sort by severity, click the Severity column.
2. Address the problems that are indicated in order of severity (Critical Errors, Errors, Warning, Information). Each alert has KB information that gives you more information on how to proceed with the alert.
Important: If you find errors from the AD Essential Services script, address these errors first. These errors indicate that one or more domain controllers are nonfunctional.
Look for noisiest generators:
1. Click Action, click View Reports, and then click LOCAL REPORTS.
2. Expand Microsoft Operations Manager.
3. Select Most Common Alerts, select all dates, and then click View.
4. Examine the report, and address all events that show more than 5% in the Activity column.
5. Repeat these steps for the Most Common Events report.

Note: If you address the issues found in this procedure quickly, you decrease the amount of noise on your domain controllers, WAN, and MOM system. The general health of your Active Directory environment will improve.

Using ADMP to Manage Active Directory

You must triage all alerts on a daily basis. In addition, you must perform other tasks on a regular basis, depending on your environment. Many important problems do not cause alerts, but they still require periodic attention. ADMP generates reports that display data over time and present patterns that indicate problems. Review the reports to resolve issues before they generate alerts.

You can perform the daily, weekly, and monthly tasks as specified in the tables in this section, but you must adjust the frequency of these tasks to meet the needs of your particular environment.

Daily Tasks

On a daily basis, perform the following tasks:

Review all open alerts.
Verify that all domain controllers are communicating with the MOM console.
Review warnings. (Optional)

Reviewing All Open Alerts

Triage all new alerts in the following order of priority:

Critical errors
Active Directory Essential Services alerts
Active Directory Scripts, such as the operations master (also known as flexible single master operations (FSMO)) ping and replication latency
Warnings (optional)
Informationals (optional)

It is expected that not all problems can be repaired in one day or less. Commonly, parts must be ordered, or computers must be scheduled for reboot, and so forth. It is important that you follow up on these open alerts to make sure that they are addressed in a timely manner.

To review open alerts

In the MOM console, click Monitor, All Open Alerts.
Review all alerts that are older than 24 hours to make sure they are addressed in a timely manner.

Verifying That All Domain Controllers Are Communicating with the MOM Console

Communication failure between the domain controller and the monitoring infrastructure prevents you from receiving alerts so that you can examine and resolve them.

To verify that domain controllers are communicating with the MOM console

In the MOM console, click Monitor, All Agents.
In the right pane, click the Last Contact column header. This sorts all computers based on last contact time. If the last contact time is greater than five minutes, troubleshoot why the computer is not communicating with MOM.

Reviewing Warnings

It is desirable but not mandatory that you review Warnings, because they indicate pending failures. Warnings are not displayed by default.

To enable the display of Warnings

In the MOM console, expand Monitor, Public Views, Active Directory, Health Monitoring.
Right-click Active Directory Domain Controller Alerts, and then click Properties.
In View Description, click Service Unavailable, Security Breach, Critical Error, Error.
In the Alert Severity dialog box, select the Warnings check box, and then click OK twice.

To review warnings

In the MOM console, click Open Active Directory Domain Controller Alerts.
To sort by severity, click the Severity column.
Review all Warnings.

Weekly Tasks

In addition to the tasks that you perform daily, review the following reports weekly:

AD Duplicate Accounts
AD Time Service
AD Client Side Response Time (if running Client Pack)
AD Domain Changes
AD Database and Log

For a description of the reports, see Appendix A.

Monthly Tasks

In addition to the tasks you perform daily, and the reports you review weekly, review reports in the following categories on a monthly basis:

Capacity Planning and Trending
- AD Domain Controller Memory Capacity Planning by Day
- AD Domain Controller Processor Capacity Planning by Day
- AD Domain Controller Disk Space
- AD LDAP Performance
- AD Inbound Replication Bandwidth Usage
Configuration Management
- AD Trust Web (review all trust relationships in network to make sure no unexpected trusts are there)
- AD Machine Account Authentication Failures (ordered by count)
- AD Domain Controllers by Site
- AD Operations Master Best Practices
Availability
- AD Domain Controller Availability
- DNS Service Availability
- DNS Server Availability
Most Common Alerts
- Microsoft Operations Manager Report: Most Common Alerts by Processing Rule Group
- Microsoft Operations Manager Report: Most Common Events

Review other reports as appropriate for your installation.

Common Management Tasks for ADMP

You might need to perform some tasks to manage ADMP on an as-needed basis. These tasks include the following:

Add a domain controller to ADMP.
Remove a domain controller from ADMP.
Modify rules.
Enable the ADMP Client Pack.

Adding a Domain Controller to ADMP

Add the domain controller as appropriate according to the MOM user´s guide. Determine whether you want to collect replication latency trending data. If you do, use the following procedure.

To collect replication latency trending data

In the MOM console, navigate to Rules, Computer Groups.
Double-click Active Directory Replication Latency Data Collection.
Click the Included Computers tab.
Click Add.
Type the domain and name of the new domain controller, and then click OK.

Removing a Domain Controller from ADMP

You can remove a domain controller using same procedure that you use to remove any managed node from MOM. Use the following procedure if you need to remove a domain controller from ADMP.

To remove a domain controller from ADMP

Open ADSIedit, open the domain object, locate the MOMLatencyMonitors organizational unit (OU), locate the domain controller object that you are removing, and then delete it. If the MOMLatencyMonitors OU does not exist, go to step 3.
Navigate to the configuration container, open the MOM Latency Monitors OU, and then delete the object.
If the domain controller is also a DNS server, repeat steps 1 and 2 to delete the object in the DNS application directory partition (for Windows Server 2003 only). Repeat steps 1 and 2 for all application directory partitions.

Modifying Rules

It is strongly recommended that you not edit the built-in rules, but rather, copy them, disable the original, and then modify the copy. This prevents updates from Microsoft interfering with your custom rules.

To modify rules in ADMP

Right-click the rule that you want to modify, and then click Copy.
Navigate to the Custom AD Rules folder, and then select Event Processing Rules.
Right-click Event Processing Rules, and then click Paste.
Modify the rule as necessary, and then click OK.
Open the original rule that you copied, disable it by clearing the Enabled check box, and then click OK.
Right-click Rules, and then click Commit.

Enabling the ADMP Client Pack

The ADMP Client Pack is a set of rules in the Processing Rules Group that allow client-side monitoring for Active Directory. You can use the rules contained in the ADMP Client Pack to test the availability of Active Directory from a client perspective. Manually deploy this rule group in your environment if it is necessary or desirable to actively monitor the availability of domain controllers and Active Directory.

Note: Always enable this rule group on or near servers running Exchange 2000 Server to ensure that global catalog servers and domain controllers are always available to Exchange 2000 Server.

A client computer in this context is a computer that is not a domain controller but that is running the MOM agent and the ADMP Client Pack. You can configure the ADMP Client Pack to monitor a specific set of domain controllers, such as:

Domain controllers within the client´s local site
Domain controllers within a list of specified sites
All domain controllers in the client´s domain

The client computer actively determines whether domain controllers are available by:

Pinging the domain controllers with both Internet Control Message Protocol (ICMP) and LDAP packets.
Performing net use connections to the SYSVOL share.
Performing LDAP binds.
Performing LDAP searches.

You can specify the thresholds used for the LDAP bind and search. If multiple consecutive failures (or binds or searches that exceed the specified thresholds) occur, the ADMP Client Pack generates an alert.

For more information on configuring the ADMP Client Pack, navigate to Processing Rules Groups in the MOM console, and select Active Directory Client Side Monitoring. Scroll down the right pane to the Configuration section.

To enable the ADMP Client Pack

In the MOM ADMP console, select the AD Client Side Monitoring computer group.
Manually add each client computer to the AD Client Side Monitoring computer group.

Appendix A: ADMP Reports

ADMP reports augment ADMP by providing important information over longer periods of time. ADMP reports provide important information in the areas of trending and capacity planning, user account problems, change configuration management, and service level availability.

Data collection for several reports is disabled by default. The MOM administrator must enable data collection for these reports to run properly. These reports include:

AD Replication Monitoring*
AD Services Availability**
DNS Service Availability**
DNS Server Availability**
AD Domain Controller Memory Capacity Planning by Day***
AD Domain Controller Memory Capacity Planning by Peak Hours***
DNS Server Memory Capacity Planning by Day***
DNS Server Memory Capacity Planning by Peak Hours***

* Enable this report by opening the MOM console, and then clicking Rules, Computer Groups. Then double-click Active Directory Replication Latency Data Collection, Include Computers, and manually add each server that you want to collect data for.

** Enable this report by opening the MOM console, clicking Configuration, Global Settings, Agents, Service Availability, and then selecting the Enable service availability checking and reporting check box.

*** These reports require the operating system management pack to be loaded.

Active Directory Discovery

These reports display the current configuration:

AD Domain Controllers by Domain
- This report lists all domain controllers in the selected domain, along with their IP address and site, sorted by domain.
AD Domain Controllers by Site
- This report lists all domain controllers by site regardless of domain, sorted by site. This view is more convenient than AD Domain Controllers by Domain for listing and verifying that the required domains are present at a particular site.
AD Operations Master Best Practices
- This report describes each of the best practices for the operation masters, and it verifies that they are being followed.
AD Operations Masters by Computer
- This report lists which computers are holding one or more operations masters or global catalogs, sorted by computer.
AD Operations Masters by Role
- This report lists which computers are holding one or more operations masters or global catalogs, sorted by role.
AD Replication Topology by Domain Controller
- This report summarizes the Active Directory replication topology, sorted by domain controller. The report provides a list of connection objects for each domain controller; indicates whether the connected domain controller is a bridgehead server; and, if so, whether the connection is IP or Simple Mail Transfer Protocol (SMTP).
AD Replication Topology by Site
- This report summarizes the Active Directory replication topology, sorted by site. It includes site link name, link type, link cost, replication interval, and local or remote bridgehead.
AD Trust Web
- This report summarizes all of the trust relationships for selected domains. It includes the trusted domain, the direction of the trust, and its transitivity.

Active Directory Health Monitoring and Operational Recovery

AD Authentication Performance
- This report summarizes four key authentication-related counters over the defined time interval. This can be a useful trending report showing the rising authentication times as the number of users increases during your deployment. It can also be used to track changing loads over time.
AD Client Side Response Time
- This report summarize the bind and ping times for the Client Pack scripts. This is very useful in determining and documenting the actual reponse times of domain controllers at key sites within the enterprise. For more information, see "Enabling the ADMP Client Pack" earlier in this white paper.
AD Domain Controller Disk Space
- This report summarizes Active Directory disk consumption and free space for the database and log volumes. It is critical that adequate free space be available for Active Directory. Use this report to trend and predict the size of volumes that you will need, given your current growth rate.
AD Domain Controller Memory Capacity Planning by Day
- This report summarizes the cache miss rate on the domain controller. Active Directory performance is directly related to the ability to cache the entire database in RAM.
AD Domain Controller Memory Capacity Planning by Peak Hours
- This report summarizes the cache miss rate on the domain controller for the 7 A.M. to 7 P.M. time frames. Active Directory performance is directly related to the ability to cache the entire database in RAM.
AD Domain Controller Processor Capacity Planning by Day
- This report summarizes the minimum, average, and maximum processor utilization per day for the selected domain controllers.
AD Domain Controller Processor Capacity Planning by Peak Hours
- This report summarizes the minimum, average, and maximum processor utilization per day for the selected domain controllers between 7 A.M. and 7 P.M.
AD General Health
- This report summarizes the number of TCP connections, the percentage of processor time, the number of server sessions, and related uptime. This information can help you track uptime and trend the number of clients served in that period.
AD Global Catalog Search Time
- This report summarizes global catalog responsiveness. Use this report to trend and debug slow Exchange 2000 Server address book and logon time problems. Any value over half a second is problematic for servers running Exchange 2000 Server.
AD LDAP Performance
- This report summarizes various LDAP-related performance counters. This report is useful for trending and capacity planning issues related to directory-enabled applications such as Exchange 2000 Server.
AD LSASS Performance
- This report summarizes key counters within the LSASS process. LSASS is the process name for Active Directory. Use this report for trending and capacity planning purposes. One key example is that the total private bytes consumed must not exceed 2 gigabytes (GB) (2.5 GB for Windows Server 2003, Enterprise Edition).
AD Operations Masters Connection Time
- This report summarizes ping and bind times to the operations masters for the selected domain controllers. Climbing response times are indicative of an overloaded operations master, most notably the primary domain controller (PDC) emulator. Use this report to trend and plan the sizing needs of your operations masters.
AD Response Time
- This report summarizes the bind times for the selected domain controllers. This report is unique because it reports on the responsiveness of the domain, not of a particular domain controller. Interpret this report as the ability to locate and respond to local clients.
AD Response Time by Peak Hours
- This report summarizes the bind times for the selected domain controllers between 7 A.M. and 7 P.M. This report is unique because it reports on the responsiveness of the domain, not of a particular domain controller. Interpret this report as the ability to locate and respond to local clients.
DNS Server Memory Capacity Planning by Day
- This report summarizes the cache miss rate on the DNS server.
DNS Server Memory Capacity Planning by Peak Hours
- This report summarizes the cache miss rate on the DNS server for the 7 A.M. to 7 P.M. time frames.
DNS Server Processor Capacity Planning by Day
- This report summarizes the minimum, average, and maximum processor utilization per day for the selected DNS servers.
DNS Server Processor Capacity Planning by Peak Hours
- This report summarizes the minimum, average, and maximum processor utilization per day for the selected DNS servers between 7 A.M. and 7 P.M.

Active Directory Operations

AD Client Side Events
- This report provides the raw details supporting the client pack alerts that show up in MOM. Use this report to do a more detailed analysis of the reported problem.
AD Domain Changes
- This report summarize significant changes to the domain, such as movement of the PDC emulator.
AD Domain Controller Availability
- This is the uptime report for the selected domain controller.
AD Duplicate Accounts
- This report details which user accounts have duplicate (conflicted) security principal names (SPNs) and user principal names (UPNs). When two or more objects have identical principal names, Kerberos is unable to issue tickets to access for those accounts. It is very desirable to repair this immediately. This usually occurs when scripts are used to create accounts and the input is not checked for principal name uniqueness beforehand. The easiest way to correct this is to use ADSIEDIT to reestablish uniqueness.
AD Machine Account Authentication Failures
- This report summarize which workstations (that are joined to the domain) are unable to authenticate. This failure prevents Group Policy updates and software distribution to the computer. The most likely causes are a mismatched password or a deleted machine account object. If the machine account is present, the problem occurs because the user has joined two or more computers to the domain with the same NETBIOS name. This causes one of the computers to be unable to authenticate. The correct solution is to rename the failing computer and rejoin it to the domain. Correcting this problem also lessens the load on the domain controller.
AD Machine Account Authentication Failures (ordered by count)
- This report summarize which workstations (that are joined to the domain) are unable to authenticate. This failure prevents Group Policy updates and software distribution to the computer. The most likely causes are a mismatched password or a deleted machine account object. If the machine account is present, the problem occurs because the user has joined two or more computers to the domain with the same NETBIOS name. This causes one of the machines to be unable to authenticate. The correct solution is to rename the failing computer and rejoin it to the domain. Correcting this problem also lessens the load on the domain controller. This report is sorted by count so that you can correct the worst problems first. Please note that a low failure count that is several days old may indicate a problem that has since been corrected or a workstation or laptop that is currently off.
AD SAM Account Changes
- This report summarizes which users have conflicted Security Accounts Manager (SAM) account names. Active Directory does not support overloaded SAM account names. Active Directory automatically renames one of them. Use this report to identify the source of the problem and correct it. This problem is usually caused by creating the same object twice on two different domain controllers within one replication interval. Waiting a sufficient time for replication to complete causes an error message to be sent, indicating that the second account creation is conflicting in the user interface.
AD Services Availability
- This report is the key uptime report that reports on all of the essential components of the domain controller.
AD Time Service
- This report details the raw events collected from the time service provider. Use this report to examine time service problems and to identify intermittent issues. Time service stability is critical to Active Directory.
DNS Server Availability
- This is the uptime report for the server running the DNS service.
DNS Service Availability
- This is the uptime report for the DNS service on the selected domain controller.

Active Directory Replication

AD Inbound Replication Bandwidth Usage
- This report summarizes the inbound replication data bandwidth over the selected period (compressed and uncompressed). This report is useful for trending and capacity planning to track and predict the average compression achieved and the necessary local area network (LAN) bandwidth required.
AD Outbound Replication Bandwidth Usage
- This report summarizes the outbound replication data bandwidth over the selected period (compressed and uncompressed). This report is useful for trending and capacity planning to track and predict the average compression achieved and the necessary LAN bandwidth required. Outbound is particularly useful in tracking potential bridgehead overloading.
AD Replication Collisions
- This report details all of the objects that are renamed during replication as a result of collisions. Collisions only occur if the same object is created on two or more domain controllers within the same replication interval. If the object truly is a duplicate, you may delete the appropriate one. If the object represents two different entities, rename the appropriate one.
AD Replication Failures
- This historical report summarizes all replication-related failures by domain controller. Use this report to correlate problems (such as failure resetting passwords) with replication failures.
AD Replication Monitoring
- This report summarizes the minimum, average, and maximum replication latency per context per domain controller. This report is extremely useful in verifying any SLA that you have for changes to replicate within the domain or forest. It can also be used to verify that site links and schedules are set up correctly.

Appendix B: Configuring Settings for Slow WAN Links or Large Branch

Office Deployments

There are several cases in which you might decide not to collect warnings, performance data, and miscellaneous noncritical events. These include:

Deployments across satellite links
Large branch office deployments
Deployments with very slow WAN links
Deployments where alerts are forwarded to a global network operations center
Warnings and informational messages are not needed

You can filter events that you do not want to be notified about. First, you must create a folder to hold the new filter rules, and then you must add the filter rules.

In addition, you might decide to disable certain performance data to decrease traffic. After making changes, you need to commit changes to the system.

Note: Several ADMP reports will not operate if performance data gathering is disabled.

If you have not already created a folder to hold new rules, perform the following procedure.

To configure filters

In the MOM Administrative Console, navigate to Rules, Processing Rule Groups.
Right-click Microsoft Windows Active Directory (enabled), click New, and then click New Processing Rule Group.
In the Processing Rule Group Properties - General dialog box, in the Name box type a name for the new folder (for example, Custom AD Rules).
In the Processing Rule Group Properties - General dialog box, in the Description box type a description for the new folder (for example, Use this folder to hold custom AD rules).
In the Processing Rule Group Properties - General dialog box, make sure that the Enabled check box is selected.
Click Next, and then click Finish.
When a dialog box appears with the message "Would you like to deploy the processing rules in this newly created processing rule group to a group of computers?" click Yes.
Click Add.
Select Windows 2000 Domain Controllers and Windows Server 2003 domain controllers, and then click OK.
Expand the Microsoft Windows Active Directory rule group, and then expand Custom AD Rules.
Right click Event Processing Rules, and then click Event Filter.
Verify that the provider name is Application, and then click Next.
Click Advanced.
In the Advanced Criteria dialog box, set the following parameters:
1. In the Field box, select Event Type.
2. In the Condition box, select is less than.
3. In the Value box, select Error.
Click Add to list.
Click Close, and then click Next
In the Filter Processing Rule Properties - Schedule dialog box, in the drop-down box click Always process data, and then click Next.
In the Filter Processing Rule Properties - Filter dialog box, select Do not evaluate further processing rules, nor insert matching events into the database (Pre-Filter), and then click Next.
In the Company Knowledge Base dialog box, click Next.
In the Filter Processing Rule Properties - General dialog box, in the Name box type a name for the filter (for example, Filter non-error Application events).
Repeat steps 11-20 to filter events for each of these event logs: Directory Service, System, and Script Generated Data. In each step, replace Application with the name of the event log for which you are setting filters.
In the MOM Administration Console, right-click Rules, and then click Commit. These changes take approximately 10 minutes to take effect.

To disable performance data

In the MOM Administration Console, navigate to Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows 2000 (enabled), Active Directory - General (enabled), Active Directory General (shared) (enabled).
Click Performance Processing Rules.
For each rule of type Measuring in the right pane, perform the following steps to disable the rule:
Double-click the rule.
Make sure the Enabled check box is cleared, and then click OK.
Repeat steps 2 and 3 for Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows 2000 (enabled), Reporting Rules for Active Directory(enabled), Reporting Rules for Active Directory(shared)(enabled).
Perform step 3 for TCP Connections in Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows 2000 (enabled), Reporting Rules for Active Directory (enabled), Performance Processing Rules.
Perform step 3 for TCPv4 Connections in Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows .NET (enabled), Reporting Rules for Active Directory (enabled), Performance Processing Rules.
Perform step 3 for TCPv6 Connections in Rules, Processing Rule Groups, Microsoft Windows Active Directory (enabled), Active Directory Windows .NET (enabled), Reporting Rules for Active Directory (enabled), Performance Processing Rules.
In the MOM Administration Console, navigate to Rules, Processing Rule Groups.
Right-click Rules, and then click Commit. This process takes about 10 minutes.