Monitoring All Auto-Start Services In A Single SolarWinds Orion SAM Script

Today, we’re going to look at how we can monitor services configured for automatic startup in bulk, using a single component monitor with a PowerShell script in SolarWinds® Server and Application Monitor (SAM). We will also look at the differences between this and traditional single service monitoring using the service monitor component.

Firstly, let’s look at the standard service monitor component:

Here, we have configured our service monitor to look at the WMI service and alert us if it is down.

Very easy to create and monitor, just how it should be and is in SolarWinds world.

Of course, any service you wish to monitor is likely to be configured to auto-start. Now, what if we want to monitor another auto-start service? Well, we will have to add another service monitor component and configure it according to the next service we define.

This is all good and well, however, assuming that the template you are creating will be assigned to multiple servers and each server is most likely configured slightly differently depending on the roles it is performing, there will likely be a few problems we will encounter when assigning the template. Let’s look at this in point form:

• The application monitor you’ve created has only the services you’ve statically defined in the template
• Not all servers have the same service monitoring requirements
  • The number of variations to the template will mean too many assignment level adjustments will be necessary

Suddenly the template you were creating to monitor your services just got a whole lot less easy to set up.

So, do we create a basic template with only a few service monitors and add additional components on a per-server basis? Very messy.

Do we create a different template for every server? Even messier and this flies in the face of the purpose of templates!

Keep reading and I will bestow upon you a more elegant solution!

By making use of PowerShell, we can create a single component monitor to run a script which selects all services with a start-up type of automatic and will monitor them and alert us should one stop running.

Let’s have a look at the code:

[code]$IPAddress = ‘${IP}’
$ExludeServices = ‘SysmonLog’,’Ati HotKey Poller’,’spupdsvc’,’McShield’

$Services = Get-WmiObject Win32_Service -ComputerName $IPAddress -Credential ‘${CREDENTIAL}’ | Where-Object {$_.StartMode -eq ‘auto’ -and $_.state -ne ‘Running’} | where ({$ExludeServices -notcontains $_.Name}) | select name, state

$Message=”
$Statistic=0

foreach ($service in $Services){
$Message+=$service.name + " "
$Statistic++
}

if ($Error.Count -eq 0) {
write-host "Message: $Message";
write-host "Statistic: $Statistic";
exit 0;
}
Write-Host "Message: $($Error[0])";
Exit 1;[/code]

If you are familiar with PowerShell then the code above should be pretty readable to you, but let’s delve a bit deeper into the code and break it down into sections:

$IPAddress = ‘${IP}’ – Populates the IPAddress variable which will get the IP address of the node that the script is assigned to run on.

$ExludeServices = ‘SysmonLog’,’Ati HotKey Poller’ – This variable (you probably guessed) will exclude any automatic start services defined here from being monitored. For example, if any service listed here happens to stop, the script will ignore it and continue to report as being in an ‘Up’ state. This is a string value passed in the script parameters.

$Services = Get-WmiObject Win32_Service -ComputerName $IPAddress -Credential ‘${CREDENTIAL}’ – Here, we are defining the Services variable and populating it by running a command to get all services on the node. We are also specifying which node by using the IPAddress variable earlier defined. CREDENTIAL is a variable in SolarWinds that inherits the node’s credentials from the template.

Where-Object {$_.StartMode -eq ‘auto’ -and $_.state -ne ‘Running’} – This is the 2nd part of the line of code above. This is defining what information from the Get-WmiObject command to keep.

where ({$ExludeServices -notcontains $_.Name}) – 3rd part. Here we are filtering results and comparing them to our list of excluded services. If it finds any matches, it will then exclude them from the final results.

Select name, state – 4th part. Display only the name and the state of the services in our final results.

$Message = ‘ ‘ – Variable ‘Message’ being defined with nothing inside it.

$Statistic = 0 – Variable ‘Statistic’ being defined with a value of 0.

[code]foreach ($service in $Services){
$Message+=$service.name+ " "
$Statistic++
}[/code]

The foreach function is pretty self-explanatory. It is then updating our ‘Message’ variable with the service names listed and increasing the statistic by 1 for each service found.

[code]if ($Error.Count -eq 0) {
write-host "Message: $Message";
write-host "Statistic: $Statistic";
exit 0;
}[/code]

If no errors were detected in our code then we are instructing the script to output our ‘Message’ variable and our ‘Statistic’ variable.

[code 1=”"Message:” 2=”$($Error[0″ language=”}Write-Host”])";
Exit 1;[/code]

Aaaaaand if something went wrong, output the ‘Error’ variable.

Now that we have the code and we’ve got some idea of what it’s doing, how do we apply this to our SolarWinds Server and Application Monitor template?

Head over to SolarWinds Server and Application Monitor settings and create a new template. In the template we are going to add a Windows PowerShell Monitor:

Confirm inherit credential from the node is selected, or select the appropriate credential.

Execution mode must be set to Local Host. You will also need to check ‘Run the script under specified account’ as by default PowerShell will try and run any scripts executed on the Local Host under the SYSTEM account.

Don’t forget to add a value into the Warning or Critical threshold for SolarWinds Server and Application Monitor to change the status. Pick your preference and put a value of 1.

We’re almost done…

Test your script against a relevant server and assign your new template.

Should you want to exclude any additional services on a specific server, override the template and add the service name you wish to exclude.

Let’s summarize the benefits of this method of monitoring:

Pros:

• Efficient use of scripting to monitor multiple services in one component
• Easily editable per server to add or remove exclusions
• Licence efficient – using only one component means only one license

There is a caveat to this – We lose certain monitoring capability on each specific service. For instance, the ability to track and report on CPU, physical and virtual memory and IOPs. We also forfeit the ability to start and stop the service(s) in SolarWinds.

This isn’t so much of an issue if you consider why we’re using this script, which is for the fundamental purpose of checking if the automatic-start services are running or not, and alerting us should it detect any.

And that’s it!

I and the team here at Prosperon Networks are continually looking for ways to enhance how customers make use of SolarWinds and ultimately improve efficiency. Adding value to your IT environment is our goal!