Automating SAM Application Monitor Assignments

TL;DR The PowerShell script linked to below will assist in creating and assigning application monitors in SAM for windows servers.
Source code at: https://github.com/jmsysadmin/SWO_App_Mon

Generally, applications in production are monitored well where I work. I don’t hear that we missed much, and it’s fairly accurate at tell us about outages. But it takes effort, and we have about 2000 windows servers, and with another OS release, our normal replenishment rate is about to tick up again. If I don’t monitor 1000 newly built servers in the next 12 months, I will be surprised. We have some application templates that get used many times, but we have a lot of unique, 1-3 server applications. While I love using templates from Thwack, its only going to cover a small percent of our needs. Mostly I (and a few brave souls who assisted me over the years) have created templates by looking at the server and deciding what needs to get monitored.

My goal was to take the human out of it. I make mistakes, I get distracted, and I have other things to do. This led to iterations of what I have shared. My goal was to make a basic monitoring template without input from people.

Most of this is just how I choose to make a simple monitor. I won’t say that don’t get useful information from the analysts installing and upgrade applications, but I will say that they rarely tell me about something I would have missed, and the reverse is not always true when I show them what we monitor. The basic idea is that I know what is running on the server before the application is installed and configured. I don’t typically want to monitor that. (This is not always true, for instance my Citrix servers need the print spooler monitored.) I also know that Orion’s SAM module can do a bunch of things, its basically a swiss army knife, but I use a few components much more than everything else. I use service monitors, port monitors, http/s and certificate monitors. Some of you are thinking about process monitors right now, and on windows, I tend to ignore them unless I need to watch some important child process, or I need to watch specific thresholds for performance. Its not part of my basic monitor.

Services I am sure make sense to you, most applications are now written to run with them, and they do the bulk of traditional server compute these days. The ports I only look for some common ones unless asked for something specific. Port 80 and 443 tell me that I need to check a website, and I realize that other ports can be used, but again, I leave it off my basic monitor unless it is one of a dozen or so noteworthy ports. If you don’t like what I check , feel free to add your own you know your environment best.

This script in its simplest form uses PowerShell to gather a list of servers, checks for the services that get added after the build process, and the ports that are listening, then writes a template, saves it and imports it to Orion if possible.

Before we start the script, it needs rights to gather data from remote windows servers and to administer Orion if you want to automatically get a list of what needs rights, and to assign the monitors. I run the PowerShell console with those rights. If you need the script to ask for, them, feel free to edit the script.

How to use

Download or clone the git repository (which will let you keep the script update). Right now, it’s got a few folders and files in it, like below.


SWO_App_Monitor_Automation.ps1 is the script that you run and has all the important logic in it.
Servers.csv is one of the ways that you can load a list of servers. In fact, if you just put 1 server name, or 1 per line into the file it should work. The other data is bonus data that we will talk about later. If you want to fill in more, the columns expected are: Server, NodeID, NodeUsedFor, Applications

The filters folder is filled with csv files that filter out discovered services that we don’t want to monitor. We have slightly different desired filters by OS, so I wrote this to handle that. In the script there are also some services or service prefixes that get ignored by all operating systems.


The resources folder holds files that get read by the script, mostly to help build the template, but also CSS for the report. I just like to reduce the blocks of text that make the script harder to read.

The reports, logs, and templates folders currently do not have anything interesting in them, they are where files will get written by the script.

Below are things you may want to edit or set in the command line parameters.

.PARAMETER OrionServerName

Feel free to set your server information in the script as the default server name, but you can set it in the command running the script if you choose.

.PARAMETER Quiet Suppress Interactive prompts, use script defaults

I run this as a scheduled job and don’t want to answer questions. It gets enough information from the parameters. If you want to add things to the exclusion list or get used to the flow of the script, don’t use it.

.PARAMETER ServerListSource Select where to pull server list from, can be 'CSV' or 'Orion'

CSV allows you not to have rights to the script, but if I run reading a list of servers in a CSV, I don’t typically try to import to Orion. If you use Orion, its going to try to add a monitor to any windows server with no monitors.

.PARAMETER FilterForProduction Limits servers to nodes marked as 'Production'. Can be set to 'SKIP' to ignore the filter, or set to the name of a custom property where the value says "Production"

I don’t want to monitor my test and Dev servers unless there is a good reason. So typically, we use this parameter to include production servers. That value is set as a node custom property called “nodeusedfor” so we set this to -filterforproduction ‘nodeusedfor’. If you don’t tack that, skip this, or use whatever your property is named.

.PARAMETER ApplicationName Can be set to 'SKIP' to ignore, or the custom property name that holds the application name on the server

I automatically name my templates and monitors. We have a custom property that should hold this data, so I use it.

.PARAMETER TargetedServers Choose "All" or "Unmonitored" Servers to include in the list of servers

I never run this against all my servers, but you could.

.PARAMETER ImportTemplateToOrion $true will upload the template to Orion, $false does not

By default, we do not upload the template to Orion, this permits the script to try.

.PARAMETER AssignTemplateToNode If the template is uploaded to Orion, $true will assign it to the node it was created from, $false does not

Future improvements:

I plan to keep updating this script, I found a typos while writing this document. Its why github is nice. If you have thoughts, I'd love to hear them. 

Also, I might possibly add another function or perhaps an entire new script that helps keep existing monitors current. Not that an analyst would ever update a server and not ask to update monitoring. Nope, that wouldn't happen, and I never would suggest that it does.