Introduction

Powershell is a interface for interacting with Windows systems in a scripted or automated method similar to what can be done with Bash within the Linux world.

One of powershell's biggest features/paradigms is that it treats everything as an Object instead of as Files or Text like traditional scripting languages(ie Bash, Perl, Python etc)

This object orientated approach means that powershell also handles it's output differently then the traditional standard out/standard in conventions. 

From the up.time perspective this means we need to use a slightly different approach when triggering powershell scripts as Custom Monitors or Action Profiles. As well when using powershell scripts as custom commands via the Windows Agent.

Another thing to keep in mind when working with Powershell scripts in general is that by default they're set to only run in 'Interactive Mode', i.e. when an actual user triggers them from within a Powershell Prompt. The 'ExecutionPolicy Bypass ' flag in the samples below allows us to override this default behaviour when calling powershell.exe. You may want to change this ExecutionPolicy value based on your own internal rules/policies. 

One last thing to keep in mind with Powershell is that it handles 'white space' in paths differently then the normal Windows command prompt. This is also complicated by powershell's behaviour to just echo out any strings wrapped in double quotes. The easiest way to avoid this by placing your scripts in a path that doesn't have any white-spaces, like in the examples below. But if you do need call a script from a path that contains white-space you'll need to use the escape back-tick ( ie. ` ) before every white space character.

Monitoring Station Side: 

Obviously in order to leverage powershell scripts on your up.time monitoring station, it needs to be running on a Windows system. 

The first step to setting up your Powershell script for use with up.time is to create a simple wrapper script in batch similar to the 'mypowershell.bat' example below.

This bat script does two important things:

• Calls powershell.exe with the appropriate ExecutionPolicy Flags and tells it which ps1 script to execute, as explained above.
• The '<NUL ' at the end of the line tells the up.time JVM to stop waiting for more output from the ps1 script and return the contents to up.time.  

@ECHO OFF
powershell.exe -noprofile -ExecutionPolicy Bypass -Command "& 'c:\uptime-scripts\backlog-monitor.ps1' " <NUL

Once you have your batch wrapper script created, you can then use the path to the .bat file in the various 'Script Name' fields within up.time's custom monitors or as part of Alert/Action Profiles just like you would any other script.

Agent Side:

 Setting up powershell script as custom commands for the Windows Agent is easier then the monitoring station example above, as we don't need to create the .bat wrapper script, and instead can provide the powershell.exe flags/arguments directly in the Agent Console's 'Path to Script' field. Though we still need to account for the ExecutionPolicy and whitespace behaviour outlined in the introduction above.

Here's an example of a powershell script setup a Custom Script within the Windows Agent:

Here's the full contents of the 'Path to Script' field in the screenshot above.

powershell.exe -ExecutionPolicy Bypass -Command "& C:\path\to\your.ps1"