PowerShell Community Management Pack in Action - Monitors and Run As Accounts

Welcome to this series of posts that will run through using the PowerShell Community Management Pack for SCOM to enhance your SCOM monitoring.

In the first part of this series, I will walk through using a PowerShell script to check the number of files in a remote share and then tweak the code to allow for the use of a Run As Account.

Scenario

A customer has an image processing application that temporarily stores images on a share. These should be archived within 5 minutes but sometimes things don't go as planned and they want a monitor to check the number of files in the share every 15 minutes and alert if there are more than 5 files present.

Pre-requisites

1. I have already installed the PowerShell Community Management Pack from here.
2. I have created a file share with some files.
   1. I have configured the file share with share permissions of Everyone = Read. This is because the SCOM agent is running as local system and will need to remotely access the share.
   2. I will change the monitor configuration later in the post so that the monitor will use a windows domain account via a Run As Account \ Run As Profile. This would allow us to restrict share permissions to the Run As Account rather than Everyone.

Let's go!

PowerShell Script

Let's make sure that this thing works before we try and put it into SCOM.

$RemoteFolderPath = "\\SCOM-MS2\ImageStore"
$State = "Unknown"
$FileCount = 0
$Threshold = 5
$whoami = whoami.exe

#####
#
# This script needs permissions set on Everyone = Read on the share otherwise it will return a file count of 0. Test-Path will validate that the share exists but won't have permissions to count files (but won't error)
#
######

Try {
    If (Test-Path $RemoteFolderPath) {
        $FileCount = (Get-ChildItem $RemoteFolderPath -File | Measure-Object).Count
        if ($FileCount -lt $Threshold) {
            $State = "UnderThreshold"
            }
        else    {
            $State = "OverThreshold"
            }
        }

    }
      
    finally  {

    Write-Output "FileCount = $FileCount"
    Write-Output "Threshold = $Threshold"
    Write-Output "RemoteFolderPath = $RemoteFolderPath"
    write-Output "WhoamI = $whoami"

}

This produces the following output in VS Code so it looks like we are good to go.

From PowerShell Script to SCOM Monitor

Some useful links:

1. Ideally, use this PowerShell template from Kevin to give a consistent approach to your scripting.
2. And this is great for troubleshooting - Monitoring Guys

The Script updated to be a SCOM monitor. I can create another blog doing a deep dive into the SCOM code but as a quick overview for the moment:

• We need to load the MOMScriptAPI and then create a PropertyBag to pass data back to SCOM.

$ScomAPI = New-Object -comObject "MOM.ScriptAPI" 
$PropertyBag = $ScomAPI.CreatePropertyBag()

• I find it useful to drop an entry into the Operations Manager event log to use for troubleshooting (and to verify that the script is actually running).

$ScomAPI.LogScriptEvent

• We need to populate the PropertyBag

$PropertyBag.AddValue("FileCount",$FileCount)
$PropertyBag.AddValue("Threshold",$Threshold)
$PropertyBag.AddValue("RemoteFolderPath",$RemoteFolderPath) 
$PropertyBag.AddValue("WhoamI",$whoami)     
$PropertyBag.AddValue("State",$State) 

• We need pass the PropertyBag to SCOM

$PropertyBag

Putting it all together gives us the following:

param([string]$Arguments)

$ScomAPI = New-Object -comObject "MOM.ScriptAPI"
$PropertyBag = $ScomAPI.CreatePropertyBag()

$RemoteFolderPath = "\\SCOM-MS2\ImageStore"
$State = "Unknown"
$FileCount = 0
$Threshold = 5
$whoami = whoami.exe


#####
#
# This script needs permissions set on Everyone = Read on the share otherwise it will return a file count of 0. Test-Path will validate that the share exists but won't have permissions to count files (but won't error)
#
######

Try {
    If (Test-Path $RemoteFolderPath) {
        $FileCount = (Get-ChildItem $RemoteFolderPath -File | Measure-Object).Count
        if ($FileCount -lt $Threshold) {
            $State = "UnderThreshold"
            }
        else    {
            $State = "OverThreshold"
            }
        }

    }
      
    finally  {
    # Properties of our alert

    $ScomAPI.LogScriptEvent("RemoteFolderCheck.ps1",9999,2,"Run As = " + $whoami + ", Remote Folder Path = " + $RemoteFolderPath + ", State = " + $State + ", FileCount = " + $FileCount + ", Threshold = " + $Threshold)

    $PropertyBag.AddValue("FileCount",$FileCount)
    $PropertyBag.AddValue("Threshold",$Threshold)
    $PropertyBag.AddValue("RemoteFolderPath",$RemoteFolderPath)
    $PropertyBag.AddValue("WhoamI",$whoami)
    
    # Property Bag for Health State
    $PropertyBag.AddValue("State",$State)

    # Return $PropertyBag to SCOM
    $PropertyBag
}

Creating the Monitor

In the SCOM Authoring Tab, under Authoring > Management Pack Objects, right click on Monitors and select Create a Monitor > Unit Monitor.

Drill down through Scripting > PowerShell based and you'll see the wizards created by the PowerShell Community Management Pack.

Select PowerShell Script Two State Monitor (Community).

I'll create a Management Pack for monitoring of the Image Processing Application.

And then we can start creating our monitor. Note that I have:

• Scoped to Windows Server 2016 and above Operating System. Ideally we would scope to a more specific class but that would require creating custom class which is outside the scope of this blog.
• I have created the monitor disabled. I will enable via an override for a specific server later.
• It would be better to create a group of watcher nodes and to enable the monitor for the group via an override. I've not done this as I don't want to spend time creating groups as part of this blog.

I've set a schedule of every 15 minutes.

And then pasted the script into the Script window.

I've then set the Unhealthy Expression to "OverThreshold"

I've then set the Healthy Expression to "UnderThreshold"

I've set the Unhealthy Monitor Condition to Critical (rather then the default of warning).

I have then set the Configure Alerts page to have a (hopefully) useful Alert Description and the severity of the alert to match the monitors health (which was set to critical on the previous window).

I then enabled the monitor for a specific object of class Windows Server 2016 Operating System. In practice, it would be preferable to have create a group and enabled the monitor for the group, especially later when we distribute the Run As Account to multiple servers as we could just ditribute to the group.

On the Authoring tab in the SCOM console, I scoped the Monitors to Windows Server 2016 and above Operating System.

Then enabled the monitor for a specific object of class Windows Server 2016 Operating System. Don't forget a description!

Finally, for this part of the monitoring, I created an Alert View to see the Active Alerts generated by this monitor. In the SCOM Monitoring View, I right clicked the Folder for my application (which was automatically created when I created the Management Pack in the wizard) and chose, New > Alert View.

I configured the view to show data from Windows Server 2016 and above operating system where the conditions of the view where to show Alerts from this specific monitor that were not in a resolution state of 255.

Then I sat back and waiting for the alert to come in. You'll see that I have included the threshold and the number of files in the folder in the the Alert Description as U believe this is useful information for whoever has to manage the alert (especially if the alert triggers an incident in a Service Management tool).

I then manually deleted some files (wouldn't it be neat to be able to run a diagnostic to view the files and \ or a recovery to delete the files - we'll do that in later posts).

With the files deleted, the alert closes and we can also verify in Health Explorer that everything is health again.

Take note that the monitor is running as local system on the server that is doing the remote check. That might not be ideal as it means that the Share Permissions need to be Everyone = Read.

So the final part of this post will update the Management Pack to use a Run As Profile so that the monitor can execute using alternate, windows credentials.

Using a Run As Account \ Run As Profile

The final step in this blog will be to create Run As Account (Windows) and a Run As Profile for the remote monitoring. We'll then update the monitor to use this Run As Profile.

This will require exporting the Management Pack and manually editing the code in your favourite editor.

Create a Run As Account

Pre-requisites

I've created a Windows Domain Run As Account call domain\scomwatchernode.

Let's go

In the SCOM Console, go to Administration > Run As Configuration > Accounts > Create Run As Account.

Configure the user name and password and domain.

Choose More Secure

Create Run As Profile

In the SCOM console, go to Administration > Run As Configuration > Accounts > Create Run As Profile..

• Make sure you select the management pack we created for the monitor.

Choose the Run As Account and then choose to use the Run As Account to mange a selected class, group or object.

• If you created a group for your watcher nodes, then you can select your group here.
• I will select my specific server object that is doing the monitoring.
  • SCOM does a really poor job here as it just lists the operating system of all the servers rather than the server name. I just happen to know my server is last on the list.

I can confirm on the next screen that it is the correct server (path) that has been selected.

Click create to create the Run As Profile.

Then I click on the hyperlink with the warning sign next to it.

I then need to make sure that the correct computer (health service) is chosen for distributing the RUn As Account to.

Click OK and Close to complete the Run As Account and Run As Profile configuration.

Export Management Pack and Update to use Run As Profile

To be able to use the Run As Account for monitoring, we need to configure the monitor to use the Run As Profile. To do this, we need to export the monitoring management pack that we have created.

In the SCOM Console, in the Administration tab, go to Administration > Management Packs > Installed Management Packs and find the monitoring management pack that we created earlier.

Right click the Management Pack and choose Export. Save it somewhere locally and then open in a code editor.

First, update the version number. I have changed this to 1.0.0.1. The version needs to be incremented for the updated management pack to be importable as an upgrade to the existing management pack.

Next, if you scroll down, you'll see a few lines of code as follows (your Run as Profile will have a different ID from mine).

Copy the ID (without quotes) - in my example, this is what I copy.

I then need to add the following to my monitor configuration.

RunAs="RunAsProfile_317400cdc03747f99536170d6c137550"

From

  <UnitMonitor ID="UIGeneratedMonitorfce0fefc1d424560ad57439ce2905782" Accessibility="Public" Enabled="false" Target="Windows!Microsoft.Windows.Server.10.0.OperatingSystem" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="PowerShellMonitoring!Community.PowerShellMonitoring.UnitMonitors.PowerShellTwoState" ConfirmDelivery="false">
    

      <UnitMonitor ID="UIGen      <UnitMonitor ID="UIGeneratedMonitorfce0fefc1d424560ad57439ce2905782" RunAs="RunAsProfile_317400cdc03747f99536170d6c137550" Accessibility="Public" Enabled="false" Target="Windows!Microsoft.Windows.Server.10.0.OperatingSystem" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="PowerShellMonitoring!Community.PowerShellMonitoring.UnitMonitors.PowerShellTwoState" ConfirmDelivery="false">
  eratedMonitorfce0fefc1d424560ad57439ce2905782" RunAs="RunAsProfile_317400cdc03747f99536170d6c137550" Accessibility="Public" Enabled="false" Target="Windows!Microsoft.Windows.Server.10.0.OperatingSystem" ParentMonitorID="Health!System.Health.AvailabilityState" Remotable="true" Priority="Normal" TypeID="PowerShellMonitoring!Community.PowerShellMonitoring.UnitMonitors.PowerShellTwoState" ConfirmDelivery="false">
  

You need to do the same but remember that you profile id will be different than mine.

Save the changes and import the updated management pack

And it should import succesfully.

Now if trigger a new alert, we can see in the alert description that the monitor is using the Run As Account that was specified in the Run As Profile for the monitor.

Summary

We have create a monitor using the Community PowerShell Management Pack.

We have configured the monitor to use a Run As Account rather than the default agent action account.

Let me know if you have any questions over at the SquaredUp Community Answers site or Direct Message me.