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:
You can set the override to only discover agent based DC’s here:
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:
To troubleshoot this – you might enable verbose logging:
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!!!
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:
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. 
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.
Thx Kevin for the write up. Is it possible to include DMZ domains in this topology layout ?
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.
Thx Gordon
Pingback:Catch up on the latest Azure Monitor, SCOM and SquaredUp news | SquaredUp
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?
Yes. We were supposed to update the MP with updated naming and displaystrings but it hasnt happened yet. 🙁
Does this MP covers AD 2019 as well? its not mentioned anywhere in the doc/wiki
Yes
I’m assuming they’ll rename the class for 2016 as well, to 2016+?
I expected they would, it was supposed to happen, but I don’t know if/when.
Hi Kevin,
Regarding this, or other MPs (like ADCS). If it relies on the RMS to discover, does it mean that any ADDS and ADCS (and possible other services) are not able to be discovered via a gateway?
It simply means that the discovery runs on a specific management server. It simply dictates the run location of the discovery. What the discovery “does” after that is completely dependent on the discovery logic itself. Typically a gateway is not really a target for any discovery.
Hi Kevin,
Can we target the discovery to Gateway domain server?
HI Kevin,
Any distributed application (DA) or Distributed application Designer (DAD) you shared in your blog. could you please share. Thank you.