SCOM 2007 R2

Monitoring Multiple Active Directory Forests Without A Trust

Posted by rob1974 on January 26, 2010

SCOM can monitor other forests without have a trust to that forest. This can be achieved by using certificates. My colleague already made a post on how these certificates need to be set up. Even though  SCOM management servers and its agents have communication individual management packs might have the requirement of having a trust in place.

As we all read the management pack guides before we import a new management pack, you immediately see on page 9 multiple forest topology discovery and views: “to discover other forest, a trust relationship is required between the forest hosting the Operations Manager Manager Root Management Server and other forests”.

We don’t have a trust nor do we want one, but most of our monitored servers are in other forests and there are quite a lot of domain controllers amongst those servers. Does this line mean we don’t have to bother with importing the AD mp? Fortunately, this is only about topology and their corresponding views of forests and domains. All domain controllers are discovered and monitored by this MP, even when they are in different forests than the SCOM servers.

We’ve disabled the topology discoveries as we just have a single forest, single domain topology for SCOM and the people in charge of the domain controllers are scoped to those servers on the computer object, so they won’t see the topology anyway. However, I wouldn’t recommend disabling the discoveries when the main forest you are monitoring is the same as the SCOM forest or has a trust with that forest. By disabling these discoveries you basically lose your health model for AD and are left with just the health of domain controllers.

If you do want to disable the topology discovery, just disable the discoveries below:


As you can see i filtered on “root management server” and this is the reason why you need to have the trust. These discoveries all run on the RMS.

So, now we have monitoring of domain controllers without having knowledge about the domain/forest topology. Well not quite, we’re not there yet. We do have monitoring of domain controllers, but we also have lots of errors about several scripts not being able to run with an error description “failed to create the object ‘McActiveDir.ActiveDirectory’”.

The management pack guide states that the Active Directory Helper object will be installed when you install the agent. However, this is only true when you push the agent (well i think, i haven’t really tested it). For manual installed agents, none of the helper objects will be installed and you need to install this helper object (OOMADS.msi found on the SCOM CD) on all domain controllers manually.

The installation is so easy, i won’t even make a screenshot of it, no selections at all, just next, finish and done. But as soon as the installation has finished the “failed to create object McActiveDir.ActiveDirectory” errors have disappeared. And pretty soon after the health explorer for a domain controller looks like this instead of some warnings we had before:


So now all we have to do is install the OOMADS.msi on all domain controllers. However, we don’t like manual installs and want to script the helper object installation in our scripted agent install.

We can find some some setting to determine whether a server is a domain controller or not, but we’d prefer the same setting as SCOM would use to determine whether a server is a domain controller. So we started looking in the mp’s and AD discoveries for such a setting. Soon we found a script called ADLocalDiscoveryDC.vbs which has the following description (including the typo’s :)):

‘ Script Name – AD Local Discovery DC

‘ Purpose     – Discovers weather a local server is DC or not
‘ Parameters  – Targer fqdn, netbiosname

‘ (c) Copyright 2003, Microsoft Corporation, All Rights Reserved
‘ Proprietary and confidential to Microsoft Corporation             

So this must be how a DC is discovered, but it isn’t. If you look more closer, it’s actually targeted at domain controllers. This discovers a lot of roles of a DC, but it does not discover if a computer is a domain controller.

However, this script is still useful. Because it does install the helper object on a domain controller provided OOMADS.msi is located in scomagentinstallpath\HelperObjects (there are some more checks before OOMADS.msi will be installed, if you are interested just find the function InstallOOMADs() and figure out what it does; this function might be different for each os version). This means we just have to place the correct helper object (x86, amd64, ia64) in this directory and the next time this discovery script runs OOMADS will be installed automatically. As this discovery only runs on domain controllers, you can copy OOMADS.msi to all agent-managed servers, which also prevents manual action whenever a server will be promoted to DC after agent installation.

A bit off topic but we still wondered how SCOM determined whether a server is a DC or not. This discovery takes place in Microsoft.SystemCenter.Internal by a wmi query “SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole > 3”. If this returns something the computer will be marked as a domain controller. Most likely NumberOfProcessors is used as each computer has at least 1, so it will always return something. Similar queries for client (domainrole =< 1) and server (domainrole >1 and < 4) computers are used and also discovered in the internal mp.

To sum things up:

– The AD mp discovers and monitors all domain controllers regardless of having a trust.

– Forest/domain topology is only discovered when there’s a trust between the SCOM forest and other forests. This only affects the health model of AD, not the health of an individual domain controller. In other words, domains/forests without a trust are not monitored, but all domain controllers are.

– To have all tests functional OOMADS.msi must be installed on all domain controllers. By placing the correct version of OOMADS.msi in “scomagentinstallpath\HelperObjects” it will be installed on each domain controller automatically.


3 Responses to “Monitoring Multiple Active Directory Forests Without A Trust”

  1. Philippe Augras said

    Hi Rob,

    Thanks for this very interesting article. It actually matches a problem I’m currently trying to find a solution for. I’d need some enlightment concerning “In other words, domains/forests without a trust are not monitored”. It’s not very clear to me so could you tell me the kind of alerts I will or will not get in such a situation ? It’s kind of unsual to me to think that “DC will be monitored” but “domains/forests won’t be”.
    Thanks in advance for your reply 🙂


    • rob1974 said

      You’ll see all alerts that you would get if you had a trust. However it will not build a health model or your domains/sites and forests because it can’t run the discovery that is responsible for it (you dont get a graphic display of the health of your entire forest). imho that’s not a big loss, mostly the health model means 60% of the underlaying objects are unhealthy then the top is unhealthy too. e.g. a domain is “healthy” when 1 of the 2 dc’s is unhealthy??? you’d really want to have a look at the alerts anyway and don’t trust that health model 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: