SCOM Service Accounts

A System Center Operations Manager 2007 installation will result in lots of service accounts for running various management packs and performing various tasks. However a base install will require you to create 5 main accounts. These accounts will be explained below:

Action
The action account is used by the management servers working with the clients. It gathers information and performs various tasks on agents.

Runas
Runas accounts are used to allow you to perform actions on clients from the management server with elevated privilages. Used for when your action account doesn't have privilages to perfrom a task so it uses the runas account to do this instead.

SDK and Config
Runs the SDK and Configuration SCOM services.

Data Warehouse Write
Used from a reporting server to write to the data warehouse SQL server.

Data Reader
For reading information from SQL.

Ways to Deploy Agents in SCOM

In System Center Operations Manager 2007 there are many different ways to install agents to client machines. These methods include:

• Discovery Wizard
• Manual Agent Installation of the SCOM CD
• msiexec.exe
• Group Policy
• Operations Manager Command Shell
• Scheduled Discoveries
• AD Integration Auto Assignment
• SCCM Deployment

Below we will be going through and looking at each method along with its pro's and con's.

Discovery Wizard

The discovery wizard is one of the most popular ways for Administrators to deploy agents to new managed assets in a SCOM 2007 infrastructure. The discovery wizard broadcasts subnets to find out which devices require agents installed, and gives you the option which devices you want to push the SCOM agent out to over RPC.

To kick this discovery wizard off you simply click administration, right click device management and click discovery wizard. There are two types of discoveries:

• Automatic Computer Discovery
• Advanced Discovery

Automatic computer discovery does every PC in the domain. Advanced discovery lets you select things like just servers. I always recommend advanced discovery.

For subnets that do not have their own management server, you can setup SCOM agents as proxies to do the broadcast for you. Basically you just select one PC that will always be powered on and mark it as a proxy inside operation manager console - very simple. Here is a little diagram I made to show you how this works.

When you use the discovery wizard agents are automatically approved, and do not enter pending management.

Manual Agent Installation of the SCOM CD

You can insert the SCOM installation disk into a windows client and install the Agent simply using the disk. If you do this, the agent will appear under Pending Management. You will then need to approve it in the operations manager console as a managed client.

msiexec.exe

You can use the msiexec.exe tool to install SCOM agents on workstations. Here is an example on how you would do this:

msiexec.exe /i \\path\Directory\MOMAgent.msi /qn /l*v \logs\MOMAgent_install.log USE_SETTINGS_FROM_AD=0 MANAGEMENT_GROUP=(Management Group) MANAGEMENT_SERVER_DNS=(Management Server FQDN) ACTIONS_USE_COMPUTER_ACCOUNT=0 ACTIONSUSER=(Username) ACTIONSDOMAIN=(Domain) ACTIONSPASSWORD=(Account password)

You can take this futher using admin tools such as psexec to run this command on multiple computers at a given time for mass deployments.

By default all these computers will appear under pending management. If you want them to automatically be approved there is an option under Operations Manager in global settings.

Group Policy

You can push the agent out to PC's using standard software deployment through group policy. When using group policy machines will not automatically be approved and you will have to add them manually unless you Auto-approve new manually installed agents.

Operations Manager Command Shell

You can install the SCOM agent on a single workstation using the Ops Mgr Shell by using a command similar to:

install-agent -ManagementServer servername -AgentManagedComputer agentcomputername

Or you could make a very simple powershell (.ps1) script.

$creds = Get-Credential
#Create an array $Servers for a list of servers
$servers = get-content c:\ServerList.txt
$DiscoCnfg = New-WindowsDiscoveryConfiguration -computername:$servers -performverification: $true -actionaccount:$creds -computertype: "server"
$ms = Get-rootManagementServer
#You have to Discover the computer first
$DiscoResults = Start-Discovery -managementserver $ms -windowsdiscoveryconfiguration:$DiscoCnfg
install-agent -ManagementServer $ms -AgentManagedComputer: $DiscoResults.custommonitoringobjects

This will mass deploy agents out to multiple machines.

Scheduled Discoveries

Scheduled discoveries was the prefered way of deploying agents in MOM 2005. However this feature was lost moving to SCOM 2007. In reality, it was more or less replaced by AD Integration. However an engineer created a powershell script that you can schedule to bring this feature back if you wish to do your deployments this way. Fore more information visit the following site:

http://www.systemcenterforum.org/news/scheduled-discovery-and-agent-deployment-in-large-and-complex-environments/

AD Integration Auto Assignment

This is the most automated way to do the installation of agents on your network. If you wish to use AD Integration you need to prepare your domain using MOMADAdmin.exe which can be found on the SCOM CD in the support folder. This commandline tool creates a OperationsManager container on your domain partition.

Auto Assignment is done using LDAP queries. You can simply use something like AD Users and Computers which has a nice interface to create LDAP queries for you. I recommend creating a query that targets just operating systems with the word "server" in it - as I do not recommend monitoring clients as your monitoring servers will be flooded with logs.

I found this really good article that walks you through a step by step process in setting up Auto Assignment and SCOM AD Integration:

http://www.infrontconsulting.com/AD_OpsMgr2007.pdf

SCCM Deployment

You can also deploy scom agents using SOE management software such as Microsoft System Center Configuration Manager server.

RMS and the SDK, Config and Health Service

In this post I'm going to run through the Microsoft System Center Operations Manager 2007 RMS (Root Management Server) and three critical services:

• SDK Service
• Configuration Service
• Health Service

All these services can be viewed in the services.msc console on a RMS server in a SCOM environment. It is Microsoft best practice that you do not run the SDK and Config services using the standard SYSTEM account and that you create a new account in AD Users and Computers to run both of these accounts as a service account. This account must be local admin on the RMS server.

SDK Service

Every SCOM management group contains one RMS. The SDK Service is one service account that can only be found on all Management Servers, however it is only enabled on the RMS. SDK stands for Software Development Kit. The SDK Service has a number of responsibilities, one of the main ones being an interface into the Operations Manager environment. All applications created to talk to Operations Manager must talk through the SDK Service.

Although all interface communication must come through the SDK Service, there is two connectors that applications must talk to first before being passed through the SDK Service. These connectors are known as the Operations Manager Class Libaries and the Operations Manager Connector Framework.

The Operations Manager Class Libaries is what all Microsoft interface tools use such as operations manager console, operations manager command shell and the operations manager web console.

The Operations Manager Connector Framework is for non-microsoft operations manager products. It allows developers to create custom applications for monitoring their SCOM environments using the extensive knowledge database Microsoft has made freely available on their MSDN website.

Here is a diagram I made that shows how this fits together nicely:

The SDK Service is also responsible for viewing the current state of a monitored object, importing management packs to the database, storing management packs in the database, and storing managed group configuration in the database.

Configuration Service

The configuration service is used to synchronise configuration from the root management server to all other management servers. It also lets all management servers know who the root management server is.

Health Service

The health service monitors the health of all the hosts on the network. This is done using management packs and other tools which SCOM provides. If the health service is stopped, performance logging and detection of failures will not occur.