Do you have some domain controllers that are appearing in a “not monitored” state?

There are several reasons why an object would have a “not monitored” state.  There are two very common reasons why a domain controller appears in this state if you are running the AD MP.

There is an option to remove these domain controllers that appear in a “not monitored” state.  You can refer to the Active Directory Management Pack Guide for details on this, but there are a couple points I will note here that will help answer some lingering questions.

This is not intended to explain when or why you should remove this discovered inventory, rather some observations and notes I ran across while performing these steps in my lab.  Refer to official documentation to help determine if you really want to remove these not monitored domain controllers.

As of the date of this post, the current version of the AD MP is 6.0.6452.0.  The AD MP may change in subsequent versions.

How these object get discovered

Forests, Domains, sites, site links, subnets, and domain controllers are all seeded in the AD Topology Discovery, which resides in Microsoft.Windows.Server.AD.Library.  This workflow runs on the Root Management Server.

At a very high level, in this discovery, a connection is made to Active Directory and returns all domain controllers in the domain.  Each domain controller returned from Active Directory will be submitted as discovered inventory and all the corresponding relationships (e.g., connection points) will be created.  This is an all-inclusive discovery pass; no domain controller left behind.

Whether or not the domain controller has an agent installed, the objects and relationships will be discovered and created in Operations Manager.  This is why we may see several, and in some cases hundreds of domain controllers that are in a “not monitored” state.  Because the state of a Windows Computer object cannot possibly be evaluated without first having an agent installed on that computer; with the exception of agentless monitoring, of course, but that’s a separate discussion.

This explains case 1; the domain controller does not have an agent installed.  What about case 2; the domain controller has an agent installed, but it doesn’t report to this Management Group?  Read on.

DiscoveryAgentOnly override

If you decide that you don’t like having all these domain controllers in a “not monitored” state, you can use this override option to remove this inventory and the associated relationships.  Be aware that the Active Directory Topology will no longer be completely accurate, and some monitoring workflows may not work as expected.

I will not discuss the effects of removing this inventory, only steps to remove and observations while removing.

See “Gotcha!” and “Workaround” sections below before enabling this override.

How domain controllers are discovered if DiscoverAgentOnly override is enabled

Here’s a high-level overview of discovery process in the AD Topology Discovery if this override is enabled.

I enabled DiscoverAgentOnly, but this inventory didn’t go go away!

First, let’s double check the work.  Is this what you did?

Override the AD Topology Discovery for all objects of class: Root Management Server

Wait… This discovery runs every 24 hours, by default.  You’ll need to wait for the next interval to see results.

A couple things to verify

You want to see results now?

If you want immediate results, also check the IntervalSeconds parameter and change this value to a smaller number (e.g., 300 = 5 minutes).  Wait for that duration and inventory should reflect desired results.

Remember to change this IntervalSeconds parameter back! Default = 86400 (24hours)

Gotcha!

There is a little detail I haven’t mentioned yet.

The Management Server Action Account requires Operations Manager Administrator User Role to run Get-Agent in Command Shell.

The Default Action Account, which is usually a special Management Server Action Account which all Management Servers use by default for all workflows, may not have require privileges to run the Get-Agent cmdlet in Command Shell.

The MSAA does not need to be an Operations Manager Administrator for normal operations, but it does need Operations Manager Administrator privileges to run the AD Topology Discovery successfully if the DiscoveryAgentOnly override is set to TRUE.

Workaround

Be sure the Management Server Action Account domain account is a member of the Operations Manager Administrator domain security group.

This is necessary for the MSAA account to inherit privileges to perform the Get-Agent command in the discovery workflow.

If the MSAA account is not added to Operations Manager Administrators prior to setting the DiscoverAgentOnly override to TRUE, you’ll notice that CMD.exe and Powershell.exe processes on the RMS will never return.  These will hang indefinitely and the discovery will not spawn any new thread until these are killed or the RMS Health Service is restarted.

If the MSAA account is added to Operations Manager Administrator after setting the DiscoverAgentOnly override to TRUE, and at least one interval has passed, you need to kill those processes running under the MSAA or restart the Health Service on the RMS.

UPDATE: 11/05/2009

The latest release of the AD MP guide (6.0.7065.0) has been revised, and now states that the Management Server Action Account must be a member of the Operations Manager Administrators group in low-privilege environments (page 27).  This means that the MSAA domain user account needs to be added to the Operations Manager administrator domain group, which will receive the Operations Manager Administrators User Role.

Keep in mind that this is ONLY required if you plan on using the Discover Agent Only option for the AD Topology discovery.  Otherwise, the MSAA does not require Operations Manager Administrators User Role.