Working with PowerShell

The GDMA for Windows can be used to run Windows PowerShell Commandlets, or small PowerShell programs that you write or modify to return results that can be interpreted as status and performance data by GroundWork Monitor. Especially in 64-bit environments, this is quite a powerful way to monitor your Windows systems.

GroundWork Monitor (6.4 and later) and GDMA (2.2.1 and later) come with some sample PowerShell scripts that leverage commandlets to check some otherwise difficult-to-access data about 64-bit Windows systems. This section will take you through getting GDMA set up to run these examples.

Installing PowerShell

Before you can run the PowerShell plugins, you must have PowerShell installed and working on your Windows system. Please see http://technet.microsoft.com/en-us/library/ee692944.aspx for information on getting PowerShell running. In particular you MUST enable PowerShell to run scripts. To do this, launch each version of the PowerShell interpreter on your system (both the 64 bit Windows PowerShell and the 32-bit Windows PowerShell (x86)), and type:

Set-ExecutionPolicy RemoteSigned
CODE

Loading Example Profile

You will notice a new GDMA profile; the host profile gdma-22-windows-host.xml contains the service profile gdma-22-powershell, which in turn contains three services:

  • gdma_22_powershell_getcluster: A plugin to get the status of a Microsoft cluster server, if it is installed
  • gdma_22_powershell_getcounter: A generic plugin that gets any perf counter, but must be modified before it will be useful
  • gdma_22_powershell_getwmi: An example of calling a WMI counter (CPU in this case) from a PowerShell script

The modification of these example scripts in to more useful or specific uses is ongoing at GroundWork, and will doubtless be the source for many more profiles. For the moment, however, these are a starting point. To get these examples loaded:

  1. Go to Configuration > Nagios Monitoring > Profiles > Profile Importer.
  2. Select gdma-22-windows-host.xml from the list.

  3. Click Import. This will result in a host profile, which you can then apply to a host. Make this the host on which you have installed and enabled PowerShell previously. Once you commit, and build externals these services will be active. Of course, it's normal not to have OK status on an un-configured service, so gdma_22_powershell_getcounter will be in warning until you modify the plugin and give it something to monitor. Also, unless you have Microsoft Cluster Server loaded on the host, you will not get logical output from gdma_22_powershell_getcluster.

    GDMA powershell output

    The service externals are not generic, and may need to be modified to work with your system.

    The service externals assume the default location of PowerShell and GDMA. The example here explicitly calls powershell.exe in the default location, and passes it the full, no-spaces version of the path to the PowerShell script to run. The quoting used is standard, and can be used in most cases. See 'Command='Line Tricks below.

    If you instal GDMA in a different directory, you will need to modify this path. The short form Progra~2 expands out to Program Files (x86), which is where GDMA, a 32-bit program, is installed in 64-bit Windows by default.

    Check_gdma_powershell_getcounter[1]_Command="c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe  'C:\Progra~2\groundwork\gdma\libexec\v3\getCounter.ps1
    CODE

'Command='line Tricks

In some cases you may want to execute a check command that does not fall under the usual formatting rules. In particular if you want to make your own plugins, or integrate a plugin that you download off of the Internet, you may need to adjust the format of the command line in the Service External you use to control the plugin execution.

The normal way GDMA plugins are executed is something like this:

Command line tricks

The entire command line is enclosed in double quotes. Within this enclosure, there are two main sections. The first is the executing program (cscript.exe, in this case, but in the PowerShell example in the previous section, it was powershell.exe). Any arguments to the executing program come next. If you are using UNIX, the executing program is implicit: the command shell. In that case you can stop there, for example:

Check_gdma_linux_mem[1]_Command="check_mem.pl -F -w 20 -c 10"
CODE

In Windows, as well, you can run compiled programs as plugins in this way without any further specifications. Just be sure to include the enclosing double quotes.

The second main part is the interpreted plugin, with its full path, encased in single quotes. You can usually use the $Plugin_Directory$ macro, and this will be replaced with the location of the plugins in your GDMA installation. Note that you can have subdirectories off of this main location, for example many of the VBScript plugins we supply are stored in the v2 subdirectory. PowerShell plugins are stored in v3 by convention.

After the single-quoted full path to the interpreted plugin, and before the terminating double quote mark, you can supply any arguments to the interpreted plugin. The GDMA will understand bare arguments, arguments specified with a dash "-", or with a slash "/".

Related Resources