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

Posts tagged ‘Active Directory’

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

SCOM 2012 SP1 in a LAB – Configuration Guide (Configure Computers and Devices to Manage)


Hello everyone, if you have been following along with my guides, you should now have SCOM installed.

But SCOM wont do you any good if it doesn’t have any computers or devices to manage, so that’s where we will start as part of these Configuration guides.

First, start by launching the SCOM console.

SCOM Install 18

Now, navigate to the Administration pane. From there, under Device Management find ‘Agent Managed’. Right-click on the Agent Managed item, and choose Discovery Wizard.

SCOM Agent Install 01

The Computer and Device Management Wizard will start. You must first choose why type of device you want to discover and manager. You have 3 choices, Windows Computers, UNIX/Linux Computers, or Network Devices. For our example we will choose Windows Computer, and then click Next.

SCOM Agent Install 02

On the Auto or Advanced screen, you can choose to let SCOM scan the domain to find the computers, or if you want more control over which systems are monitored, you can choose the Advanced Discovery.  If you choose the Advanced option, you can also choose if you want to discover only servers, clients, or both. Additionally, you can choose which Management Server you want the discovered systems to be managed by.

Since we only have one Management Server in our lab, we only have one option, but in a Production environment you can use this to balance the load between multiple Management Servers.

Make your appropriate selections, and click Next.

SCOM Agent Install 03

Next you need to specify the Discovery Method that will be used. Again, you can allow SCOM to scan Active Directory, or you can manually type the computer names for it to check against.

From my own personal experience, it is usually best to manually type the names of the computers, as this gives you more control over what systems are added to SCOM, and how many at a time.

Choose your appropriate options, and click Next.

SCOM Agent Install 04

You can now specify the Administrator Account to use. We will accept the default selection to use the Management Server Action Account, and then click Discover to initiate the process.

SCOM Agent Install 05

SCOM will then go off and attempt to communicate with the specified systems.

Here is a diagram that shows how computer discovery works in SCOM.

Discovery

The systems that SCOM is able to communicate with will appear in the Discovery Results. From there, select the device(s) that you want to install the SCOM agent on.

In our example we will install the SCOM agent on all systems in our lab environment.

Make your selection(s) and click Next.

SCOM Agent Install 06

On the Summary screen, you can control where the SCOM Agent will be installed. In my personal experience, the default location is sufficient. You can also provide an Agent Action Account. In a lab environment, we can use the Local System, however, in a Production environment I have personally seen a designated Agent Action Account (usually a Service Account) be used in this context.

Make the appropriate selection/input, and click Finish.

SCOM Agent Install 07

SCOM will then start the Agent installation task. Depending on your network, the number of devices, etc. it may take a while to complete.

SCOM Agent Install 08

When the discovery and agent installation completes, it should look like this. You can click Close on the status window.

SCOM Agent Install 09

Returning back to the SCOM console, you will now see the system(s) that you discovered and installed the Agent on.

SCOM Agent Install 10

Congratulations, not only do you have a working SCOM environment, but you also have SCOM actively monitoring!

Here is a video walk through of these steps:

SCOM 2012 SP1 in a LAB – Installation Guide (Install ACS)


Install Audit Collection Services

Since Audit Collection Services (ACS) is not a part of the main SCOM installation, we have to install it separately.

NOTE: In a Production environment, ACS is normally implemented in a segregated space. The reason for this is because ACS is used to audit security and logons. Since the Administrator of SCOM will more than likely be a part of an Operations team, and have access to various Production/Non-Production servers, for security reasons, the ACS installation would be on a server that the Operations team would not have access to (since they would be among the logons being monitored/audited).

To start the installation, mount the SCOM ISO and run the setup.exe. From the splash screen, click the ‘Audit Collection Services’ link.

ACS Install 01

On the Welcome screen click Next.

ACS Install 02

Read the License Agreement, accept the agreement, and click Next.

ACS Install 03

On the Database Installation Options screen, choose whether you will create a new database or use an existing one. In our example, we will choose the ‘Create a new database’ option, and click Next.

ACS Install 04

 On the Data Source screen, enter a new for the data source or accept the default, and then click Next.

ACS Install 05

On the Database screen, enter the database server name and instance name, and change the database name if you do not want to use the default. Since this is a lab environment, we will choose the ‘Database server running locally’ because we have SQL Server installed on the same server as SCOM. Make the appropriate choices, and then click Next.

ACS Install 06

For Database Authentication, we are going to choose the ‘Windows authentication’ option for our lab since it’s in its own domain. Read the information for each option, and make the applicable choice, and then click Next.

ACS Install 07

For the Database Creation Options, in a Production environment you would specify different disks for the database and log files, but since we are in a lab, we will chose the ‘Use SQL Server’s default data and log file directories’ and click Next.

NOTE: I believe, though am not 100% sure, that if when you first setup/install SQL Server and specify different disks for the database(s) and log(s), then choose the ‘use SQL default’ would be appropriate since the defaults would already be offloaded to appropriate separate disks.

ACS Install 08

On the Event Retention Schedule screen, you can specify the time for the database maintenance to occur, as well as the number of days to retain. This last option is very important, as in Production your organization may have some legal/security obligations to meet. However, just remember that the longer the retention, the more space the database will need. Usually, when planning ACS in a Production environment, most use the SCOM Sizing Helper Tool to know how large the database will be, and how much to plan for growth.

For our lab environment, we will accept the defaults and click Next.

 ACS Install 09

Make the appropriate selection for the Timestamp Format, and click Next. In our lab example, we will use ‘Local’.

ACS Install 10

On the Summary screen, review the selections and input, and click Next.

ACS Install 11

Immediately after you click Next from the Summary screen, you will be prompted for the SQL Server Login. By default it will assume the login for the account that is currently logged in. If this is accurate, just click OK.

ACS Install 12

Wait for the Installation Wizard to complete, which didn’t take too long in our small scaled-down environment.

ACS Install 13

Finally, the installation will complete. Click Finish.

ACS Install 14

Congratulations, you have now installed ACS! But there is still more to do. We need to setup reporting, and the event forwarder.

Here is a video walk through of these steps:

ACS Reporting

For ACS Reporting, you first need an instance of SQL Server Reporting Services (SSRS). If you have been following these guided series, we will be using the same SSRS instance that we originally setup/configured for SCOM Reporting, since we are in a lab environment.

For our process, we are going to be following the steps outlined in this TechNet article: http://technet.microsoft.com/en-us/library/hh299397.aspx.

First, we need to log onto the server that we will use for hosting the ACS reports. In our example, this is the same server that we installed SCOM on. From within that server, we need to create a temporary folder. We’ll create one on the root of C:\ and call it ACS (i.e. C:\ACS).

ACS Reporting 01

Mount the SCOM ISO, and navigate to \ReportModels\ACS (in my example it is D:\ReportModels\ACS\) and copy everything from this location into the temporary folder that we created.

ACS Reporting 02

Next, still within the mounted ISO, navigate to \SupportTools\ (in my example it is D:\SupportTools\AMD64\ReportingConfig.exe) and copy the ReportingConfig.exe file into the temporary folder that we created.

 ACS Reporting 03

Now we need to run a command through an elevated command prompt. In Windows Server 2012 to do this, mouse over to the bottom left corner, which will cause the Start ‘square’ (not sure what the official name is) to appear. Right-click on the Start square, and click on ‘Command Prompt (Admin)’ to launch an Administrative Command Prompt.

ACS Reporting 04

ACS Reporting 05

Next, you will need to change the directory to the temporary folder that we created. You will then have to run the following command: UploadAuditReports “<auditdbserver\instance>” “” “”. In our lab example the command line would be: UploadAuditReports “SCOM\SCOMSQL” “http://SCOM/Reports_SCOMSQL&#8221; “C:\ACS”

NOTE: The reporting server URL needs the reporting server virtual directory (ReportingServer_<InstanceName>) instead of the reporting manager directory (Reports_<InstanceName>).

IMPORTANT: If you encounter the following error: “CreateSRSDataSource: Exception Invalid URI: The URI scheme is not valid“, the solution is simple (although it took some searching to find). Thanks goes to ThoughtsOnOpsMgr‘s blog for detailing the simple solution.

SOLUTION: Remove the quotes (” “) unless the path/file name has a space in it. So, my lab example would literally be: UploadAuditReports SCOM\SCOMSQL http://SCOM/Reports_SCOMSQL C:\ACS.

This creates a new data source called Db Audit, uploads the reporting models Audit.smdl and Audit5.smdl, and uploads all reports in the acs\reports directory.

IMPORTANT: In order for the import to function properly make sure you have the .NET Framework 3.5 installed. If you have been following these guides, this will already be installed from when we installed SQL Server 2012. ACS Reporting 06

Next, open Internet Explorer and navigate to the following URL: http:///Reports_, in our example it will be http://SCOM/Reports_ SCOMSQL.

ACS Reporting 07

Now click on the ‘Audit Reports’ directory folder, and then click the ‘Details View’ button in the top right corner.

ACS Reporting 08

Now click the DB Audit data source to open it.

ACS Reporting 09

Finally, under the ‘Connect Using’ selections, ensure that ‘Windows Integrated Security’ is selected, and click Apply.

 ACS Reporting 10

You can now go into the SCOM console, under Reporting, and view the Audit Reports.

REMINDER: It is acceptable to have the Audit Reports accessible via the SCOM console in a lab environment. But in a Production environment your organization may have strict security policies that you are required to follow, which would include auditing of IT to be handled by some security department.

ACS Reporting 11

Congratulations, you have finished configuring/deploying ACS Reporting. But, there is still one last step we need to complete, the Event Forwarder.

Here is a video walk through:

ACS Event Forwarder

Now that we have ACS installed, and the Reporting configured, we can now turn on the Event Forwarder to start collecting security events.

We are going to follow the TechNet article here: http://technet.microsoft.com/library/hh272397.aspx. As stated by this article: “By default, the service needed for an agent to be an Audit Collection Services (ACS) forwarder is installed but not enabled when the Operations Manager agent is installed.” Therefore, in order to audit security events, you need to have the SCOM Agent installed on the system(s) first.

Log onto the SCOM server and open the SCOM console and click on the Monitoring pane. From there, navigate to Operations Manager > Agent Details > Agent Health State.

ACS Event Forwarder 01

In the details pane (the middle pane), in the Agent State area, select the system(s) that you want to enable Audit Collection on. When you select a system, in the right-hand Actions pane, under the Health Services Tasks, click the ‘Enable Audit Collection’ link.

 ACS Event Forwarder 02

This will launch the Enable Audit Collection task. From this window, you will need to enter the Collector Server for the Forwarder to report to. To do this, click the Override button.

 ACS Event Forwarder 03

On the Override dialog, enter the FQDN of the Collector Server. In our lab example, we will enter the only Management Server in our environment (i.e. SCOM.SC.LAB). Enter the appropriate information and then click the Override button.

 ACS Event Forwarder 04

The Enable Audit Collection dialog will now show the Collector Server that you just entered. At this point, you can also add a specific account to use within the Task Credentials section, or accept the defaults. Once you are ready to enable ACS, click the Run button.

ACS Event Forwarder 05

Once the task runs and completes successfully, the dialog will appear similar to the following. You can click Close.

ACS Event Forwarder 06

Congratulations, not only do you now have SCOM installed, along with Reporting; you additionally have setup ACS and enabled security auditing in your environment.

Here is a video walk through:

Tag Cloud

%d bloggers like this: