We have two Windows Server 2016 servers that are not discovered as a Windows Server class instance on our SCOM 1801 environment. They are only discovered as “System Center Managed Computer (Server OS)”.
There are no errors in their operations manager event log and we never had this issue before with other Windows Server 2016 servers.
One thing to note is that both of the servers are Domain Controllers.
We have tried to use the SCOM 2016 agent and tried to use HSLockdown.exe /A “NT AUTHORITY\SYSTEM” but this doesn’t help to solve the issue.
The Windows Server discovery is not coming through.
I believe you need to install the agent as domain admin, and then run it as Local System with the HSLockdown that you mention above (I’ve not actually got round to doing it yet due to reluctance from our AD Team!). I’ve got the same version management packs as Ruben above and normal 2016 servers are discovered fine, so this must be because they’re domain controllers.
Sorry that doesn’t help much, but if you fix it please update what the solution was
We have installed the latest version (10.0.21.0) of the Windows Server 2016 and 1709+ management pack.
And we still have these two Windows Server 2016 Domain Controllers that won’t get discovered as a Windows Server only as “System Center Managed Computer (Server OS)”.
Yesterday we added two other Windows Server 2016 Domain Controllers and they have been discovered succesfully as a Windows Server 2016 Operating System and Server object.
The WMI query to discover “Windows Server” instances is: SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole >1 and DomainRole <4
We currently have around 5 Windows Server 2016 servers that are not discovered as Windows Server in SCOM.
All 5 of them doesn’t return a value when executing this query manually.
Could this be a bug in the Windows Server Operating Management Pack?
To me it sounds more like an issue with WMI on those particular servers so i’d probably start by digging into that some more.
I’ve just verified and we’re running the same version of MP as you and have deployed 15 or more DC’s in the last week or two and we haven’t seen a similar problem.
Out of interest what happens if you RDP to one of the affected Servers and run the following PowerShell command. Do you get anything back at all:
Get-WMIObject -Query ‘SELECT * FROM Win32_ComputerSystem’
Also, perhaps try running through this article to diagnose if you have any issues with WMI or not:
The WMI query you suggested to try, returns a correct value on the servers.
I don\'t believe there is anything wrong with WMI on these servers.
The Discovery rule for the Windows Server class contains the WMI query:
SELECT NumberOfProcessors FROM Win32_ComputerSystem WHERE DomainRole >1 and DomainRole <4
Because the DomainRole is higher than 4 this query will never returns a value on domain controllers.
– Standalone Workstation (0)
– Member Workstation (1)
– Standalone Server (2)
– Member Server (3)
– Backup Domain Controller (4)
– Primary Domain Controller (5)
Therefore I would guess that there is another Windows Server discovery rule specifically for domain controllers ?
We have found the cause of the issue.
We had an override for the Windows Computer class on the discovery rule: Discover Windows Domain Controllers.
We have a specific group on which this discovery is enabled. So Domain Controller monitoring is only activated for this group. After adding the computer objects in this group --> Windows Server discovery started.
Just for the sake of completeness I had a bit of a dig in the MP and noted that the Windows Domain Controller class is based upon the Windows Server class.
This would mean that although the WMI query you mentioned wouldn’t return a value you would still get an instance of the WIndows Server class because in normal operation the discovery for the Domain Controller (which uses a different query) would create both the Domain Controller class instance and the Windows Server class instance.
In your case this wasn’t happening because of the override which prevented both class instances from being created.
