Monitoring Windows services in SCOM is a vital part of any SCOM deployment. In this post I will show you how you can automate the creation of SCOM windows service monitors. The first thing you’ll need is Tao Yang’s OpsMgr SDK which I initially spoke about here.
The next thing you’ll need is, is the list of services that you want to monitor. The CSV should contain the service name, the service display name and the server name. Create a CSV file that looks like this:
Where Name is your FQDN of your server. Service Name is the service name of the service. Service Display Name is the service display name.
Note, the way I have written this particular script, it assumes that you want to monitor a service on a specific server. In the rare instance you want to monitor a service that is installed on every server, simply change -disabled to $false and remove the override. Typically by default you should create service monitors as disabled as to not try and have SCOM monitor that service on every server in your environment.
First things first, we need to do some house keeping to get setup.
$path = "c:\temp\services.csv" $services = import-csv $path $domain = "sandlot.dom" $scom = "om01.sandlot.dom" $mp = "custom.service.monitors"
Path make it whatever you want, just put your CSV file in there, change your domain name and SCOM Management server name, and give the $MP variable a valid management pack to add to.
If your MP doesn’t exist, you can always create it from Powershell with the cmdlet New-OMManagementPack from Tao Yang’s module.
New-OMManagementPack -sdk $scom -Name 'custom.service.monitors' -DisplayName 'Custom Service Monitors'
Next we will sort through the services in the CSV and assign variables
foreach($service in $services){ $computer = $service.name $servicename = $service.servicename $servicedisplay = $service.servicedisplayname $computerID = Get-SCOMAgent -DNSHostName $computer | select id, displayname $ID = $computerID.id
In particular we’re getting the SCOM Agent for the computer using -DNSHostName. We need this to get its ID in SCOM because the override we’re going to create needs it.
The full script:
$path = "c:\temp\services.csv" #import csv file $services = import-csv $path #set your domain $domain = "sandlot.dom" #set your SCOM management server $scom = "om01.sandlot.dom" #set your SCOM management Pack $mp = "custom.service.monitors" #import OpsMgr SDK import-opsmgrsdk #loop through Services CSV and create monitors and overrides foreach($service in $services){ $computer = $service.name #for computer to monitor that service on $servicename = $service.servicename #service name to monitor $servicedisplay = $service.servicedisplayname #service display name to monitor $computerID = Get-SCOMClassInstance -name $computer | select id, displayname $ID = $computerID.id #get computer ID in SCOM for New-OMOverride -contextinstance #create new Service Monitor, disabled new-omserviceMonitor -sdk $scom -mpname $mp -monitorname $servicename -monitordisplayname "$servicedisplay Windows Service" -servicename $servicename -parentmonitor "Availability" -ClassName "Microsoft.Windows.Server.OperatingSystem" -unhealthystate "error" -unhealthywhenrunning $false -ignorestartuptype $false -disabled $true #create override to enable the previously created service Monitor for the specific computers New-OMOverride -sdk $scom -MPName "custom.service.monitors" -workflowtype "Monitor" -target "microsoft.windows.computer" -contextinstance $id -overridename $servicename -overridedisplayname "$servicedisplay windows service" -overrideworkflow $servicename -overrideparameter Enabled -overridevalue $true }
If we go into SCOM we can see the monitor has been created, and it is also set to generate alerts for this monitor, which is really what we want.
The monitor is created as not enabled, which is what the second command for the override does.
If we check the override settings, we can see it overrides the monitor settings to true for the specific server we set.
One thing to note. You need to run this on a SCOM management server, unless you add some remote commands. Once again shout out to Tao Yang for creating the module, you can find his blog here.