Something that a fellow PFE (Brian Barrington) called to my attention, with SCOM 2016 agents, when installed on a Domain Controller: the agent just sits there and does not communicate.
The reason? Local System is denied by HSLOCKDOWN.
HSLockdown is a tool that grants or denies a particular RunAs account access to the SCOM agent Healthservice. It is documented here.
When we deploy a SCOM 2016 agent to a domain controller – you might see it goes into a heartbeat failed state immediately, and on the agent – you might see the following events in the OperationsManager log:
Log Name: Operations Manager
Source: HealthService
Event ID: 7017
Task Category: Health Service
Level: Error
Computer: DC1.opsmgr.net
Description:
The health service blocked access to the windows credential NT AUTHORITY\SYSTEM because it is not authorized on management group SCOM. You can run the HSLockdown tool to change which credentials are authorized.
Followed eventually by a BUNCH of this:
Log Name: Operations Manager
Source: HealthService
Event ID: 1102
Task Category: Health Service
Level: Error
Computer: DC1.opsmgr.net
Description:
Rule/Monitor “Microsoft.SystemCenter.WMIService.ServiceMonitor” running for instance “DC1.opsmgr.net” with id:”{00A920EF-0147-3FCC-A5DC-CEC1CA93AFED}” cannot be initialized and will not be loaded. Management group “SCOM”
If you open an Elevated command prompt, and browse to the SCOM agent folder – you can run HSLOCKDOWN /L to list the configuration:
There it is. NT Authority\SYSTEM is denied.
I’ll be researching why this change was made – this did not happen by default in SCOM 2012R2.
In the meantime – the resolution is simple.
On domain controllers – simply run the following command in the agent path where HSLOCKDOWN.EXE exists:
HSLockdown.exe <YouManagementGroupName> /R “NT AUTHORITY\SYSTEM”
This will remove the explicit deny for Local System. Restart the SCOM Microsoft Monitoring Agent Service (Healthservice)
.
Here is an example (my management group name is “SCOM”)
