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

Archive for February, 2014

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.


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

Working With The Microsoft Deployment Toolkit (MDT) 2013 – Part 7: Build And Capture A Reference System

In our last post we finished creating the Boot Media to use when building and capturing a Windows image.

Now we are going to create use the Boot Media and (finally) build and capture a Windows image.

Build And Capture A Reference System

Take the Boot Image that we created (found in \Boot). We are going to use the “LiteTouchPE_x86.iso” because the x86 media is more widely compatible (not everything is compatible with x64).

We are going to use a Virtual Machine (VM) for the reference system.

Start by mounting the ISO to a blank Virtual Machine, then start the Virtual Machine. You will be presented with the following prompt. Press any key so the Virtual Machine (VM) will boot from the Boot Media.

Build And Capture 01

Eventually, though it may take a while depending on your network, the Microsoft Deployment Toolkit wizard will appear. When it does, click on the “Run the Deployment Wizard to install a new Operating System” option.

Build And Capture 02

You will be presented with a dialog for User Credentials. These credentials must be able to access the MDT server, as this is where the image file will be captured to. Supply the credentials and then click OK.

NOTE: If you MDT Server is in a domain, you can use domain credentials, but what if it isn’t? What if your MDT server is in a Workgroup (like mine is)? In that case, in the “Domain” field, you would just use the server’s name.

Build And Capture 03

On the Task Sequence screen, choose the appropriate task sequence to run, then click Next. In our case, this is the Task Sequence we created (see Working With The Microsoft Deployment Toolkit (MDT) 2013 – Part 5: Create A Task Sequence).

Build And Capture 04

On the Computer Details screen, you can provide a Computer Name (though it is not required) but do NOT choose “Join a domain”; just accept the default of “Join a workgroup“, and then click Next.

Build And Capture 05

On the Move Data and Settings screen, since we are not migrating any user’s data, choose the “Do no move user data and settings” option, and then click Next.

Build And Capture 06

On the User Data (Restore) screen, again since we are not migrating users, choose the “Do not restore user data and settings“, and then click Next.

Build And Capture 07

On the Product Key screen, you can supply a key if required, then press Next. This depends on your environment/organization, and if you have a Multiple Activation Key (MAK), or if your organization uses a Key Management System (KMS). For this lab example, we are going to choose “No product key is required.”

Build And Capture 08

On the Locale and Time screen, make the appropriate adjustments required, and then click Next.

Build And Capture 09

On the Administrator Password screen, provide a password for the LOCAL Administrator account, then click Next.

IMPORTANT: I need to emphasize that this is for the LOCAL Administrator account. This is the local non-domain account. This means that if you are using this image in a domain environment, and the system looses its trust with the domain, your IT department can use this local account to log into the system and re-join/re-add it to the domain.

Build And Capture 10

On the Capture Image screen, choose the “Capture and image of this reference computer“, give the file a unique name, and then click Next.

Build And Capture 11

On the Ready screen, review the information displayed, and then click Begin.

Build And Capture 12

The process will begin by installing the Operating System we specified in our Task Sequence. Time to sit back and watch.

Build And Capture 13

Eventually the Operating System will be installed. However, it may look like nothing else is happening (at least in reference to capturing Windows 8). Navigate to the Desktop.

Build And Capture 14

On the Desktop you will see that the Task Sequence is continuing, and installing the Application (in this example Microsoft Office) we specified.

Build And Capture 15

Once all the steps in the Task Sequence have completed, the final capturing piece will initiate. This starts with SysPrep being executed on the reference system.

Build And Capture 16

Eventually the process will get to the point where it shows “Create WIM”. This may take a while depending on your hardware/network, but will eventually result in the captured image.

Build And Capture 17

Once the capture has completed, click Finish.

NOTE: The Virtual Machine (VM) will automatically restart. We are done our work with it, so you can shut it off.

Build And Capture 18

Back on the MDT Server, navigate to \Captures. In that directory you will now see your captured .WIM file with the name we supplied in the wizard.

Build And Capture 19

Now that we have captured image in a .WIM file, you can use it with your Operating System Deployment tool(s)/process.

Here is a video walk through:

Working With The Microsoft Deployment Toolkit (MDT) 2013 – Part 6: Boot Media

In our last post we created a Task Sequence to build and capture a Windows image.

Now we are going to create the Boot Media that will be used to build and capture a Windows image.

Start by launching the Deployment Workbench.

MDT Install 07

Create Boot Media

We are going to create Boot Media to demonstrate using the Microsoft Deployment Toolkit (MDT) to build and capture a reference system. An alternative to using the boot media is to use Preboot Execution Environment (PXE) booting, but that requires having a Windows Deployment Services (WDS) server setup and configured, along with a Dynamic Host Configuration Protocol (DHCP) server. I may document how to do this later, but for now, we’re going to use Boot Media.

Expand the Deployment Share that was created, and right-click on the Deployment Share folder and choose Update Deployment Share. This will initiate the Update Deployment Share Wizard.

MDT Generate Boot Media 01

On the Options screen, choose “Optimize the boot image updating process” option, and then click Next.

Update Deployment Share Wizard 01

On the Summary screen, click Next.

Update Deployment Share Wizard 02

The Progress screen will display information on each step it is performing. Please note that this may take some time to complete, so be patient.

Update Deployment Share Wizard 03

On the Confirmation screen, click Finish.

Update Deployment Share Wizard 04

Now if you navigate to your Deployment Share directory, you will see a directory labelled Boot. Within there you will see the Boot Images created, labelled “LiteTouchPE_x86.iso” and “LiteTouchPE_x64.iso”.

MDT Generate Boot Media 02

You now have the Boot Images created, and we can use them to build and capture a reference system.

Here is a video walk through:

Tag Cloud

%d bloggers like this: