SCOM Agent Grayed Out When Trying To Monitor Domain Controller(s)

Hello Everyone,

Sorry that I haven’t been able to post anything for a little while. Here’s something I wanted to quickly share in relation to System Center Operations Manager (SCOM) and monitoring Active Directory Domain Controllers.

So, let’s say you have SCOM installed, and you want to monitor your Active Directory. So you go through the process of installing an Agent on a Domain Controller. The installation completes successfully, but in the SCOM console, the Agent shows as grayed out.

AD Agent Grayed Out

That doesn’t seem to make any sense. Even if you log into the Domain Controller, you can see the Microsoft Monitoring Agent service running.

NOTE: In System Center Operations Manager 2012 R2, the “Microsoft Monitoring Agent” is new in R2, and replaces the “Operations Manager Agent” in previous versions. See the following TechNet article on What’s New In System Center 2012 R2 Operations Manager.

Domain Controller Task Manager

Additionally, if you check the Health Service State directory (located in C:Program FilesMicrosoft Monitoring AgentAgentHealth Service State), it appears to have everything that a “normal” monitored system does. But in fact it does not!

Domain Controller Health Service State Folder

Domain Controller Health Service State Folder Properties

Here is a screenshot of a system that has an active Agent. Notice that there are and 28 files and 17 folders different.

Active Agent - Health Service State Folder

Active Agent - Health Service State Folder Properties

In my lab example, I am using a Management Server Action Account that follows the least-privilege method. Why is this? Why would I use least-privileges, when I could just use a Domain Admin account to make things simplier. Although that would be a lot easier, currently at my employer we are implementing SCOM 2012 R2, and our security requirements, well, require least-privileges. Therefore, I figure I should try to work with that method in my lab. 

Now let’s focus on the issue at hand. Here is a great article that provides background information on the issue, and also the solution to correct it (which we are going to follow here): http://thoughtsonopsmgr.blogspot.ca/2009/09/hslockdown-explained.html.

So, since we have an Agent installed on a Domain Controller, but it’s not actually being monitored, we need to use the HSLockDown tool to correct the issue.

Start by opening a Command Prompt with Administrator privileges.

NOTE: In Windows Server 2012 R2, right-click on the Windows icon and choose “Command Prompt (Admin)”

Admin Command Prompt

In the Administrator Command Prompt, change the working directory to the Agent folder by typing ‘cd C:Program FilesMicrosoft Monitoring AgentAgent’ and press Enter.

Command Prompt - Change DIR SCOM Agent

Next, type ‘HSLockdown.exe /L’ which will list all of the accounts. You will notice that there is 1 Denied account. However, this is for the Local System account.

Command Prompt - List Accounts

To grant access to a specific account, type the following: HSLockdown.exe /A “<Account>”; where <Account>” is your Management Server Action Account, then press Enter.

Command Prompt - Allow Account

You will notice the message presented, which states: “Please restart the Health Service to apply changes”. Now, if you are running System Center 2012 R2 Operations Manager, this will be the “Microsoft Monitoring Agent” service.

Restart Health Service

Given enough time, the SCOM console will show the Agent on the Domain Controller as green, and thus working correctly.

NOTE: In my lab, this didn’t work exactly as detailed. The Agent state didn’t change, and there were Alerts generated about the Health Service failing to load rules. As an attempt to resolve the issue, I stopped the Microsoft Monitoring Agent service, and re-named the Health Service State folder. Then start the service again. This will cause the Health Service State folder (and its contents) to be re-generated.

However, this still has not corrected the issue for me. I am unsure if this is due to using a least-privilege account for the Management Server Action Account. I will need to look into this further, and will provide the results of my findings.

SOLUTION:

So, I have discovered the solution to this issue.

First, I downloaded the SCOM Active Directory Management Pack documentation, in hopes that there might be some information about what is required to monitor a domain controller. The documentation states the following:

For each of the client-side monitoring scripts to run successfully, the Action Account must be a member of the Administrators group on both the computer on which the client management pack is running and the domain controller that is being monitored. The Action Account must also be a member of the Operations Manager Administrators group, which is configured through the Operations console in so that all the scripts that are configured on the Root Management Server can run properly.

Here is a TechNet thread that discuss this issue: http://social.technet.microsoft.com/Forums/systemcenter/en-US/4a80861c-1c66-4393-bb37-fb70153730fd/health-service-unloaded-system-rules-only-on-domain-controllers?forum=operationsmanagergeneral.

So, I tried creating a specific RunAs account and Profile for domain controllers. Note however, that this account still requires Local Administrator access on the domain controller(s). If you are in an environment like mine, where Security will not provide passwords to Production Service Accounts, then you can have them enter the password for the RunAs account. But, this will only affect the scripts, etc. in relation to the Active Directory Management Pack. I currently don’t have any Management Packs installed; all I’m trying to do is get the Agent to report back as healthy.

Basically, even if you are working in a least/low-privilege environment with the Management Server Action Action, the account that the Agent is running under on the domain controller(s) needs to also have Local Admin rights. So, a solution would be to either have your Security department grant the Management Server Action Account the required Local Admin rights on the domain controller(s) you want to monitor, OR, you can manually change the Action Account that the Agent on the domain controllers run under

To do this in Windows Server 2012 (or R2), right-click on the Windows logo, and choose Control Panel.

Control Panel

Navigate to System and Security and click on the Microsoft Monitoring Agent link.

Control Panel - Microsoft Monitoring Agent

In the Microsoft Monitoring Agent Properties dialog, select the Management Groups entry shown, and then click Edit.

Control Panel - Microsoft Monitoring Agent Properties

On the Edit Management Group dialog, you can now change the Agent Action Account. It is here where you should enter the account that has Local Admin on the domain controller(s). Either this will remain as the normal Management Server Action Account (if you Security department grants it the appropriate access), or you can enter the same account that will be used as the RunAs account for the Active Directory Management Pack.

NOTE: You will need to make the potential modification on each/every domain controller that you want to monitor.

Edit Management Group

After providing an account that has Local Admin on the domain controller(s) for the Agent Action Account, you will need to restart the Microsoft Monitoring Agent service.

Restart Health Service

As soon as I did that, the Agent almost immediately reported back in the SCOM console as healthy.

Domain Controller - Healthy Agent

%d bloggers like this: