Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.

PowerShell for Discovery and Service Mapping

Log in to subscribe to topics and get notified when content changes.

PowerShell for Discovery and Service Mapping

MID Servers use PowerShell and PowerShell Remoting for accessing configuration items (CIs) during horizontal and top-down discovery. Review MID Server parameters and script includes, probe parameters, and credentials for using PowerShell.

PowerShell is used to control and automate the administration of Windows servers and applications.

MID Servers can use PowerShell to directly communicate with Windows servers using both WMI and WinRM protocols. For Windows services using the WinRM protocol, the PowerShell process establishes a secure PSSession (PowerShell Remoting session) that stays open until the MID Server finishes querying a Windows server. For Windows servers using the WMI protocol, the PowerShell process sends every PowerShell command with credentials.

As default, MID Servers use a WMI (Windows Management Instrumentation) Collector service that helps MID Servers to communicate with Windows servers. Patterns used to discover Windows servers or applications running on them, contain WMI and WinRM queries and commands to run on Windows servers. A WMI Collector service transfers WMI and WinRM queries and commands from the MID Server to Windows-based CIs and brings the results of the queries to the MID Server.

PowerShell is also the preferred method for performing discovery over multiple Windows domains. PowerShell allows a single MID Server to authenticate on servers on different domains using credentials stored on the instance.

If you do not configure MID Servers to use PowerShell and PowerShell Remoting, MID Servers use WMI Collector.

How PowerShell Discovery works

The following descriptions explain how MID Servers use PowerShell to deploy probes.
Probe and sensor

When a Windows machine is classified with PowerShell, and an MSSQL instance is detected, a probe called Windows - MSSQL is launched. The probe returns the SQL database catalogs and version to a matching sensor.

Probe parameter

The WMI_ActiveConnections.ps1 probe parameter contains a script that runs netstat.exe on a target server when PowerShell is enabled. This script extracts the information on Windows server connections, such as process IDs, ports, and IP addresses.

Credentials

Discovery uses Windows PowerShell credentials from the Credentials [discovery_credentials] table or the domain administrator credentials of the MID Server service. If Discovery cannot find PowerShell credentials in the Credentials table of the type, Windows), it uses the login credentials of the MID Server service.

MID Server Script Includes
The following script includes were added for PowerShell discoveries. These scripts run on the MID Server to generate the scripts that Discovery uses for WMIRunner and PowerShell.
  • GenerateWMIScriptJS: Generates a Javascript script for the WMIRunner probe.
  • GenerateWMIScriptPS1: Generates a PowerShell script for PowerShell discovery.
MID Server parameters for PowerShell
Optional parameters for the MID Server can be found at MID Server parameters for PowerShell. After changing the setting for any parameter, be sure to restart the MID Server service.

PowerShell version requirements

MID Servers using PowerShell must be installed on a supported Windows operating system. ServiceNow supports these PowerShell versions:
Version 2.0
  • Regular Discovery
Version 3.0
  • Regular Discovery
  • Application Dependency Mapping (ADM)
  • File-based Discovery
  • PowerShell version 3.0 does not support Windows Server 2003.
Version 4.0
  • Regular Discovery
  • Application Dependency Mapping (ADM)
  • File-based Discovery
Version 5.0
  • Regular Discovery
  • Application Dependency Mapping (ADM)
  • File-based Discovery
Note: PowerShell version 6.0 is not supported. Many of the cmdlets that discovery relies on have been removed from this version. For example, only cmdlets using WinRM are available for remote operations.

Windows PowerShell execution policies

Windows PowerShell has four different execution policies. Customers can set the script execution policies with their group policy settings. For more information, see the Microsoft website for PowerShell documentation.
  • Restricted: No scripts can be run. Windows PowerShell can be used only in interactive mode.
  • AllSigned: Only scripts signed by a trusted publisher can be run.
  • RemoteSigned: Downloaded scripts must be signed by a trusted publisher before they can be run.
  • Unrestricted: No restrictions; all scripts can be run.
Note: If you have any policy other than Unrestricted, the script needs to be signed.
Feedback