Documentation forServer & Application Monitor
Monitoring your applications and environment is a key capability of SolarWinds Observability Self-Hosted (formerly Hybrid Cloud Observability) and is available in the Essentials edition. Server & Application Monitor (SAM) is also available in a standalone module.

Use PowerShell in SAM

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 is included in most installations of Microsoft Windows Server or you can install it, if necessary.

Many SAM features, such as AppInsight for IIS and AppInsight for Exchange, leverage PowerShell to execute commands and gather data from remote systems. You can also use PowerShell with other SolarWinds Platform products; for example, in SolarWinds IP Address Manager (IPAM), you can use it to create subnets. The SolarWinds Platform SDK includes a specialized module for PowerShell called PowerOrion.

SolarWinds recommends upgrading to the latest version of PowerShell. At a minimum, use PowerShell 5.1.

The ability to deploy PowerShell scripts to remote systems from within the SolarWinds Platform 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 datastores such as the registry. It includes built-in commands with a consistent interface — the PowerShell Integrated Scripting Environment (ISE).

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

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

Some ways you can use PowerShell with SAM include:

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 SolarWinds online IT community, visit THWACK.

Review these topics to learn more:

PowerShell security considerations

Depending on how it's configured, PowerShell can make your deployment vulnerable to unauthorized access. For example, running script monitors in Local Host mode on the SolarWinds Platform server with Admin privileges gives scripts unlimited power. Your organization should internally review and assess to what extent PowerShell scripts are incorporated into your environment. This is especially important when importing scripts from third parties, including content posted by other customers in the SolarWinds online IT community, THWACK.

When used in SolarWinds Platform modules such as SAM, PowerShell can be a powerful tool that provides the ability to:

  • Access file systems on computers.
  • Access datastores, 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. Do not run untested PowerShell scripts against a production instance of the SolarWinds Platform. SolarWinds recommends using a dedicated Windows account with low-level privileges for PowerShell monitors, especially for scripts executed on polling engines that use the same Windows account as the SolarWinds Platform server.

You can also avoid security risks, such as malicious OS command injections, by using PowerShell's built-in security, as described in Microsoft PowerShell documentation (© 2021 Microsoft Corp., link available at docs.microsoft.com, obtained on May 24, 2021).

PowerShell requirements

Following are PowerShell requirements for a typical SAM environment:

  • PowerShell version: SolarWinds recommends upgrading to the latest version of PowerShell. At a minimum, use PowerShell 5.1.

    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, use PowerShell 64 bit (x64).

  • Accounts and permissions: Local Admin rights are required to run scripts on the SolarWinds Platform server. To execute scripts on target servers, select a Windows credential with rights to log in to the SolarWinds Platform 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.

    SolarWinds recommends using a dedicated Windows account with minimal privileges for PowerShell monitors, especially for scripts executed on the Main Polling Engine.

    Without the correct permissions for a target server, scripts return an Unknown status.

  • Microsoft .NET Framework: Many PowerShell scripts require .NET 3.5.x but most SolarWinds Platform products include later versions. For example, SAM 2019.4 includes .NET 4.8. 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 SolarWinds Platform server so it can access remote target servers, as described next.
  • AppInsight for Exchange: If manually configuring target servers for AppInsight for Exchange, use RestrictedLanguage mode for PowerShell instead of FullLanguage mode.

    For security reasons, SolarWinds recommends that you do not set FullLanguage mode on IIS endpoints. Starting in SAM 2020.2.6, a minimum of RestrictedLanguage mode is required.

To simplify PowerShell plugin management in an environment with multiple polling engines, consider assigning all nodes with PowerShell templates to a single polling engine.

Enable remote access for PowerShell with WinRM

To support SAM features that use PowerShell, such as AppInsight for IIS, the WinRM service must be enabled and properly configured on the main SolarWinds Platform server. WinRM cannot be enabled on target servers remotely, but you can configure the SolarWinds Platform server to grant permission for PowerShell to access the target servers.

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

If you deploy an SolarWinds Platform agent to a target node and use Agent as the Preferred Polling method in an application monitor, PowerShell scripts can be executed directly on the node without the need to configure WinRM for remote PowerShell execution. See Use PowerShell with SolarWinds Platform agents.

To enable WinRM quickly from the command prompt:

  1. On the SolarWinds Platform server, open a command prompt as an Administrator, and enter:

    winrm quickconfig –q
    winrm set winrm/config/client @{TrustedHosts="*"}

  2. On each target server, open a command prompt as an Administrator and enter:

    winrm quickconfig
    winrm set winrm/config/client @{TrustedHosts="IP_ADDRESS"}

    TrustedHosts is case sensitive.

See also Installation and configuration for WinRM (© 2021 Microsoft Corp., available at docs.microsoft.com, obtained on March 12, 2021).

Another way to enable remote access for PowerShell manually is to follow these steps:

  1. On the SolarWinds Platform server and each remote server you want to run PowerShell on:
    1. Change the startup type for the WinRM service to Automatic.
    2. Start the WinRM service.
    3. Run the get-service winrm PowerShell command to verify WinRM is running.
  2. On the SolarWinds Platform server, click Start > Accessories > Windows PowerShell > Windows PowerShell.

  3. In the PowerShell console, run:

    Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI -force

  4. Enable the "Full Control for everyone" option.
  5. Verify the group to which the polling user belongs can access PowerShell.
  6. Repeat these steps for all remote target servers.

When finished, each target server should include the following elements:

  • An SSL certificate
  • A WinRM Listener
  • A firewall exception to allow outside requests to reach the WinRM service
  • The WinRM service to receive requests from other computers

The following log file contains details about the WinRM configuration process: C:\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log

Use Microsoft Exchange Management tools

Many SAM PowerShell components rely on Exchange Management tools.

To monitor a specific version of Microsoft Exchange:

  • Use the corresponding version of Exchange Management Tools.
  • Install Exchange Management Tools on the SolarWinds Platform server and Additional Polling Engines that use PowerShell scripts.
  • Review Set PowerShell permissions for Exchange.

Use PowerShell with SolarWinds Platform agents

When working with SAM application monitor templates and individual application monitors assigned to nodes, you can use a Windows Script Monitor with an SolarWinds Platform agent to run PowerShell, Perl, VBScript, or any other Windows script language remotely. In that configuration, you don't need to configure WinRM for remote PowerShell execution. All communication between the SolarWinds Platform server and the agent occur over a single fixed port.

Otherwise, agentless polling executes locally on the polling engine itself (that is, either the SolarWinds Platform server or an Additional Polling Engine).

To summarize:

  • With agentless polling, the local execution of the script is local and the script is executed on the polling engine.
  • With SolarWinds Platform agent polling, the local script execution allows the script to be run directly on the target node. There is no need to configure WinRM.

To learn more, see:

Learn more about PowerShell