Menu Close

Configuring the Active Directory Management pack AD Topology Discovery overrides

We released an updated Active Directory Management Pack back in 2016, and have made updates along the way.  The current release supports Domain Controllers running Windows 2012, 2012R2, 2016, and later.

One of the items that many people configure, is to only discover Domain Controllers that have an AGENT on them.  Many times there are a huge number of DC’s in an environment, but not all are agent managed, and you do not wish to discover all of these in SCOM without an agent.

The AD Topology Discovery runs against your Root Management Server Emulator:

image

 

You can set the override to only discover agent based DC’s here:

image

 

HOWEVER – you might find when this is set, that you stop discovering topology at all, such as your AD Sites show up “Not Monitored” and your AD Topology diagram views do not roll up any state:

image

 

image

 

 

To troubleshoot this – you might enable verbose logging:

image

 

This will log events to show what’s happening.  Unfortunately, these verbose event logs do not actually log the error.  But they do give us a clue:

 

Log Name:      Operations Manager
Source:        Health Service Script
Event ID:      500
Level:         Information
Description:  ADTopologyDiscovery : Executing Agent discovery command:
cmd.exe /C cd “C:\Program Files\System Center Operations Manager 2007” & “C:\Windows\system32\windowspowershell\v1.0\powershell.exe” -PSConsoleFile Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Console.psc1 -command “.\Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Functions.ps1; Start-OperationsManagerClientShell -ManagementServerName: \”\” -PersistConnection: $false -Interactive: $false; Get-Agent | where {$_.ManagementGroup -like \”OM\”} | Format-List Name” > “C:\Windows\Temp\ADTopologyDiscovery-Data-{91A293C8-1114-4F74-8CDA-024ED18ACD0F}.txt” 2> “C:\Windows\Temp\ADTopologyDiscovery-Error-{91A293C8-1114-4F74-8CDA-024ED18ACD0F}.txt” “

The parts highlighted above are the issue.  This actually runs a PowerShell.exe command to connect to the SDK to pull back all the agents.  The challenge here is, that we must provide the path to the console file:  Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Console.psc1

This means that you MUST have the SCOM console installed on your RMSe, AND you must provide this path to the file in an override (if you wish to use Agent-only in your discovery).  This was a poor design really, because there is no need for this to connect to the SCOM SDK via PowerShell.  This is a really, really old method of interacting with the SDK, probably a carryover from the old ADMP.  But the simplest solution is to just provide the correct path to where YOU installed the SCOM console:

In SCOM 2019, my path is:  “C:\Program Files\Microsoft System Center\Operations Manager\Console”

In SCOM 2016, my path is: “C:\Program Files\Microsoft System Center 2016\Operations Manager\Console”

Your location may differ.  You just need to find the location of the Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Console.psc1 file, which is installed when you install the console.

The path MUST BE IN DOUBLEQUOTES!!!

image

 

This will query the SDK, and bring back ALL the agents, to verify each DC from Topology discovery is agent managed.  Note – this can take a LONG time in some environments, as it is essentially performing a “Get-SCOMAgent” command, and looping through each one.

Now my topology is showing correctly:

 

image

 

NOTE:  You will want to disable the “Verbose logging” override – as this will now log an event for EACH agent in the management group.  If you have 1000 agents, that’s a burst of 1000 events.  Not a good idea.  Smile

 

Known issues:

1.  You might see errors when AD Topology script runs:

Event ID: 1000   Source: Health Service Script

ADTopologyDiscovery : Cannot create System.Collection.Stack

This is because the script is using functions provided by .NET 3.5.  Please install .NET 3.5 on your management servers, or at least the management server that holds the Root Management Server Emulator role.

10 Comments

    • Gordon

      Unfortunately, the MP was designed in such a way as to discover only the AD topology of the domain that you have SCOM MSs as members of (and the trusted domains that are a part of the forest). So any untrusted domains will only have DCs discovered but not the topology so it won’t monitor the AD health of those other domains.

      As stated above, “The AD Topology Discovery runs against your Root Management Server Emulator”. This is one of the MSs running in your original domain. Other domains are monitored either with the use of certificates (very manual way) or setting up a GW server for SCOM. But then again, the topology discovery does not run on the GW so the domain that the GW is a member of will not be discovered.

      That is my understanding of it.

  1. Pingback:Catch up on the latest Azure Monitor, SCOM and SquaredUp news | SquaredUp

  2. Andrew T

    The updated MP guide for 10.0.2.2 makes no mention of AD 2019. Is the new MP version-agnostic like the SQL MP?

Leave a Reply

Your email address will not be published.