Get more out of Active Directory forest and domain discovery

Update (Dec. 8, 2008)

After finding the time to investigate the new Microsoft managemement pack (6.0.6452.0) it was not too difficult to find a way to re-enable untrusted domain discovery. More information here:
How to make Active Directory MP discover untrusted domains

Update (Nov. 10, 2008)

Microsoft has just released Version 6.0.6452.0 of the AD management packs: See catalog. The discovery process has changed significantly so the workaround below does not work any longer.

The good news are that MS does now support discovery of TRUSTED domains and domain controllers in OUs. For UNTRUSTED domains, integrated using security gateways I will post an update soon.

As for now I am pulling the worrkaround below.

Background information

Using the currently available AD management packs it is only possible to discover AD forests, the root management server (RMS) has access to. When implementing gateway servers to extend OpsMgr’s management group to other forests (domains), only the remote domain controllers (DCs) but not their domains and forests are added to the repository.

Furthermore the discovery explicitly expects finding all DCs in the AD OU ‘Domain Controllers‘. If DCs’ computer objects are organized into sub OUs (in our installation this was required to make applying different IPSec policies possible), the AD topology discovery won’t be able to find them.

DCs in sub OUs

The actual monitoring will be active since most monitors and rules are targeted at DCs und underlying objects but the diagram views will only show the RMS’ forest. When DCs are placed in sub OUs the domain objects will be empty as well. As a side effect you’ll see event IDs 3333 (source DataAccessLayer) and 10801 (source Health Service Modules) logged to the Operations Manager event log. The DC discovery script attempts to add relationship instances to objects that do not exist in the database.

When taking a look at the MP Active Directory Server Common Library, one can see that the discovery rule AD Topology Discovery is targeted at the RMS only. The rule’s knowledge article states: “The version AD MP does not support multiple AD Forest topology discovery. This feature will be implemented in a future version of the AD MP.” All the forest and domain discovery is done by the script ADTopologyDiscovery.vbs. It looks for DCs with this LDAP query:

strQuery = “<LDAP://” & sPDC & “/OU=Domain Controllers,” & sDNC & “>;(objectCategory=computer);cn,distinguishedName,dNSHostName,serverReferenceBL;onelevel

The ‘onelevel’ switch makes it fail to enumerate DCs in sub OUs

Enabling full topology discovery

To enable discovery of AD forests joined in using gateways, I took the existing discovery rule and added it to a custom management pack, targeting it at OpsMgr security gateway servers located in domains as well as to the RMS. I also altered the above LDAP query to allow the script finding DCs in sub OUs. It is even possible to use an override should the DCs’ computer objects not be in an OU called ‘Domain Controllers‘.

The management pack consists of :

  • AD Discovery Management Server Computer Group: RMS and gateways installed in domains
  • Discovery of the AD Discovery Management Server Computer Group
  • AD Topology Discovery (Custom script): targeted at all management servers – disabled by default
  • Override to enable the discovery on members of above group
  • Override to disable the original discovery

The additional computer group was required to make sure that the discovery is only active for gateways that are actually inside a domain in addition to the RMS. Note that the only changes to the discovery script required were adding references to Microsoft’s management pack, changing the LDAP query’s option switch and adding command line parameters to make overriding of the DC’s OU name possible. Other than that the script is the same as found in Active Directory Server Common Library, 6.0.5000.0

Download the management pack: (not compatible with Microsoft’s MP

Download Custom AD Topology Discovery MP (rename after downloading – it is a zip archive)

Note that this MP is thought to work with Operations Manager 2007 – RTM (AD Management Packs 6.0.5000.0). I have tested it with the RC of SP1 as well but if a newer AD management pack is delivered the above solution will likely have to be altered.

Update(March 11th, 2008): SP1 includes AD Management Packs version 6.0.6278.0. There are no changes to the discovery process. Hence the above solution works for SP1 installation as well.

Update(March 26th, 2008): Version 6.0.6278.10 works as well with this workaround.


The following screen-shot shows an AD topology with two forests. Both have only one domain. The left consists of two sites and a total of four DCs. The forest on the right only has one site and two DCs.

AD Topology showing two forests

Keep track of MOM Datawarehouse DTS jobs duration

We’re still running a large MOM 2005 environment and sometimes we did run into situations where the DTS jobs took too long to complete. This led to various problems including data not being ready for scheduled reports, collision with database maintenance jobs or failure of subsequent DTS jobs (yes – we do have SCRM 2006 installed).

MOM does alert if these jobs fail but there’s no convenient way of telling how long they took.

So I put together a little management pack consisting of:

  • A timed event rule that writes a performance counters based on DTS job duration
  • The same rule optionally writes alerts if the job took too long
  • A report about the DTS job duration

Download MOM Datawarehouse MP (change the extension after downloading)

The management pack works well with our SCRM 2006 installation where we have a total of three DTS jobs running every night. Here’s an example of how the MOM GUI and reports look like:

MOM Operator View  MOM Report

Automatically remove RMS Health Service from Maintenance Mode


It has been mentioned by various people that one should not put OpsMgr’s management servers’ health service objects into maintenance mode: Manageability Team Blog Entry

Now this is difficult to explain to people using the OpsMgr console and I’ve infrequently found my RMS’ health services showing the wrench icon. In order to avoid this situation from stopping OpsMgr for too long, I put together a tiny SQL query. It ends maintenance mode if found active on an RMS’ health service and then attempts to restart the config service on the RMS.

End RMS Maintenance Mode SQL Query 

This will reinitialize the RMS and it will begin updating other maintenance windows as required.


I configured an SQL agent job using the above query. It is scheduled to run every 15 minutes and does the job nicely. The SQL statements below do create the SQL Server agent job ‘End RM Maintenance Mode’ for you. Simply paste the text into a new query window:

SQL Server Agent Job Configuration

Note that you’ll need to allow the xp_commandshell function on your SQL server. This can be activated using  the SQL Server Surface Area Configuration tool. Furthermore the user you’re running the SQL server agent under must have administrative access to the RMS server. You’ll need to pay attention to this especially if your RMS and SQL servers are on dedicated machines.


Open OpsMgr’s Operations Console. Change to the Monitoring pane and choose ‘Discovered Inventory’. From the action pane use ‘Change Target Type’ and select ‘HealthService’.

You should now see a list of all health services your RMS manages.

Set some non-RMS health services into maintenance mode and wait until their state changes to ‘Not monitored’. Now do the same with the health service entity of your RMS.

After the SQL server agent job has been run the RMS’ health service’s maintenance mode should have ended and by checking the system log on your RMS you should see that OpsMgr’s Config Service has been restarted.


In case your the RMS’ Health Service’s Maintenance Mode is not ended properly (the wrench icon disappears but the health service remains in ‘Not Monitored state), check your SQL server agent’s log. Most likely you’ll see that the job didn’t have the permission to restart the Config Service or xp_commandshell was not enabled.