Submit a ticketCall us

AnnouncementsAre You “Flying Blind?”

When it comes to your complex IT infrastructure, you want to ensure you have a good grasp of what’s going on to avoid any fire drills that result from guesswork. Read our white paper to learn how proactively monitoring your IT environment can help your organization while giving you peace of mind.

Get your free white paper.

Home > Success Center > Server & Application Monitor (SAM) > SAM - Knowledgebase Articles > Use PowerShell in SAM

Use PowerShell in SAM

Updated October 30, 2018

Created by Microsoft, PowerShell is a task automation and configuration management framework that consists of a command-line shell and associated scripting language, built on the .NET Framework. PowerShell scripts are used in several out-of-the-box SAM templates, including Log Parser and Office 365 templates. You can also create custom scripts for SAM templates that support PowerShell scripts, as described in the SAM Custom Template Guide

The ability to deploy PowerShell scripts to remote machines within SAM is a powerful advantage for system administrators. With an interactive prompt and scripting environment, PowerShell provides access to the file system on remote computers, along with data stores such as the registry. 

Your organization should internally review and assess to what extent PowerShell is incorporated into your environment. This is especially important when importing scripts from third parties, including content posted by other customers in the  online IT community, THWACK. To learn more, see PowerShell security considerations.

PowerShell does not process text; it processes objects based on the .NET Framework.

PowerShell includes built-in commands with a consistent interface (as shown here), plus an Integrated Scripting Environment (ISE) host application.


PowerShell also includes default cmdlets — simple commands you can use to manipulate objects — and you can write your own cmdlets. Cmdlets have a unique format — a verb and noun separated by a dash (-), such as Get-Help. You can use them separately or combine them in scripts that perform complex tasks. 

SolarWinds provides customer support for PowerShell scripts and functionality built into SAM, but not for scripting languages or custom scripts. For scripting support from the  online IT community, visit THWACK.
Some ways you can use Powershell scripts with SAM include:

Review these topics to learn more:

PowerShell security considerations

Depending on how you configure PowerShell in your environment, it can make your system vulnerable to unauthorized access. For example, running monitors as Local Host on the Orion server with Admin privileges gives scripts unlimited power. Your organization should internally review and assess to what extent PowerShell scripts will be incorporated into your environment. 

PowerShell can be used with the Orion Platform in many ways. For example, you can use it with the Orion Software Development Kit (SDK) to perform IP Address Manager (IPAM) operations, such as creating subnets. When used in SAM component monitors and application templates, PowerShell provides the ability to:

  • Access file systems on computers.
  • Access data stores, including the system registry.
  • Deploy scripts to run on multiple remote machines. 

While PowerShell enhances SAM functionality, it's important to consider the security risks inherent in using PowerShell scripts.  recommends the use of a dedicated Windows account with low-level privileges for PowerShell monitors, especially for scripts executed on a polling engine that uses the same Windows account as the Orion server. 

You can also avoid security risks, such as malicious OS command injections, by using PowerShell's built-in security, as described in documentation available at (© 2018 Microsoft Corp., link available at, obtained on October 30, 2018)

PowerShell requirements

Following are PowerShell requirements for a typical SAM environment:

  • PowerShell version: Version 1.0 or later is required for local execution. For remote execution of scripts, PowerShell 2.0 or later is required on the main polling engine (that is, the Orion server), Additional Polling Engines (APEs), and target servers. Install and configure, as necessary.
    • Note that some scripts require PowerShell 2.0 to execute certain actions. Later versions of PowerShell shipped with Windows Server include a backwards compatibility mode you can enable to run 2.0 with a later version. 
    • Another consideration is whether to use 32-bit (x84) or 64-bit (x64) PowerShell. For best results, match the PowerShell version to the OS and application configurations on a server.  For example, on a 64-bit main polling engine that polls a 64-bit server, install PowerShell 64 bit (x64). 
  • Accounts and permissions: Local Admin rights are required to run scripts on the Orion server. To execute scripts on target servers, select a Windows credential with rights to log into the Orion server plus sufficient rights on the target node to execute tasks in the script. For example, if a script does something with WMI, the credentials also need WMI rights on the target node. Without the correct permissions for a target server, scripts return an Unknown status.

    SolarWinds recommends using a dedicated Windows account with minimal privileges for PowerShell monitors, especially for scripts executed on the main polling engine.

  • Microsoft .NET Framework: Many PowerShell scripts require .NET 3.5.x but the latest Orion Platform products include later versions during installation. For example, SAM 6.7 includes .NET 4.6.2. If necessary, use Server Manager's Add Roles and Features wizard to add .NET Framework 3.5.x.
  • Remote access: To use Remote Host as the Execution Mode for a PowerShell script, enable the Windows Remote Management (WinRM) service on the Orion server so it can access remote target servers, as described next.

Enable remote access for PowerShell with WinRM

If you select Remote Host as the Execution Mode for a SAM component monitor, the WinRM service must be enabled and properly configured on the main Orion server. WinRM cannot be enabled on target servers remotely, but you can configure the Orion server to grant permission for PowerShell to access the target servers.

There are several automated ways to enable remote access for PowerShell on servers:

You can also enable remote access for servers in the PowerShell console, as described next.

On the Orion server and each remote server you want to run PowerShell on:

  1. Change the startup type for the WinRM service to Automatic.
    1. Start the WinRM service.
    2. Run the get-service winrm PowerShell command to verify WinRM is running.
    3. On the Orion server, click Start > Accessories > Windows PowerShell > Windows PowerShell.
  2. In the PowerShell console, run: Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI -force
  3. Enable the "Full Control for everyone" option.
  4. Verify the group to which the polling user belongs can access PowerShell.
  5. Repeat these steps for all remote target servers.


Disclaimer: Please note, any content related to third-party software posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.

Last modified