A WordPress.com site dedicated to System Center and Cloud Management

Archive for the ‘Active Directory’ Category

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 Files\Microsoft Monitoring Agent\Agent\Health 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 Files\Microsoft Monitoring Agent\Agent’ 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

Advertisements

Active Directory Certificate Services – Configuration


On the Credentials page, supply appropriate credentials and then click Next.

AD CS Configuration 01

On the Role Services page, select Certification Authority and then click Next.

AD CS Configuration 02

On the Setup Type page, select Enterprise CA and then click Next.

AD CS Configuration 03

On the Specify CA Type page, select Root CA and then click Next.

AD CS Configuration 04

On the Set Up Private Key page select Create a new private key and then click Next.

AD CS Configuration 05

Leave the defaults on the Configure Cryptography for CA page, and then click Next.

  • Important: CSP, Hash Algorithm and Key length must be selected to meet application compatibility requirements.

AD CS Configuration 06

On Configure CA Name page, enter Domain Root CA (ex. SC LAB Root CA) in the Common name for this CA field, and then click Next.

AD CS Configuration 07

On Set Validity Period page enter 10 Years, then select Next.

AD CS Configuration 08

Keep the default on the Configure Certificate Database page, and then click Next.

AD CS Configuration 09

On the Confirmation page, click Configure.

AD CS Configuration 10

Review the information on the Results page to verify that the installation is successful and then click Close.

AD CS Configuration 11

You now have Active Directory Certificate Services installed.

Here is a video walk through:

)

Active Directory Certificate Services – Installation


Install Enterprise Root CA using Server Manager

Ensure that you are logged on to your server as an Administrator.

Open Server Manager.

Click on Manage and then select Add Roles and Features.

Server Manager - Add Role

On the Before You Begin page select Next.

Add Roles and Features Wizard 01

On the Installation Type page select Role-based or feature-based installation.

Add Roles and Features Wizard 02

On the Server Selection page ensure that the correct server is selected.

Add Roles and Features Wizard 03

On the Select Server Roles page select Active Directory Certificate Services and then click Next.

Add Roles and Features Wizard 06

On the Select Features page, click Next.

Add Roles and Features Wizard 07

On the Introduction to Active Directory Certificate Services page, click Next.

Add Roles and Features Wizard 08

On the Select Role Services page, ensure that Certificate Authority is selected, and then click Next.

Add Roles and Features Wizard 09

On the Confirmation page, click Install.

Add Roles and Features Wizard 10

On the Results page, click Close.

Add Roles and Features Wizard 11

Once the installation is complete, we need to do some post-deployment configuration.

Here is a video walk through;

Tag Cloud

%d bloggers like this: