Concurrent PowerShell Collection

The following sections describe how to configure and use concurrent PowerShell collection. Concurrent PowerShell collection allows multiple collection tasks to run at the same time with a reduced load on Data Collectors.

Concurrent PowerShell collection also prevents missed polls and data gaps because collection will execute more quickly. As a result, Data Collectors can collect more data using fewer system resources. The PowerShell Collector is an independent service running as a container on a Data Collector.

Do not use concurrent PowerShell collection if you are not using shared credentials, like Active Directory, on multiple servers. For example, concurrent PowerShell collection is not recommended for secure environments with unique credentials for each server, because concurrent PowerShell collection will use up a large amount of memory for processing the collections.

Use the following menu options to navigate the SL1 user interface:

To view a pop-out list of menu options, click the menu icon ().
To view a page containing all of the menu options, click the Advanced menu icon ().

Prerequisites

The following prerequisites are required to use concurrent PowerShell collection:

SL1 version 10.1.4 or greater
"Microsoft: Windows Server" PowerPack version 110 or greater
" SL1: Concurrent PowerShell Monitoring" PowerPack version 100 or greater (for SL1 versions prior to 11.3.0).

As of SL1 version 11.3.0, the "SL1: Concurrent PowerShell Monitoring" PowerPack is no longer a requirement for concurrent PowerShell monitoring.

Scope

When the concurrent PowerShell collection service is enabled, PowerShell Configuration and PowerShell Performance Dynamic Applications are sent to the service.

The following PowerPacks can use the concurrent PowerShell collection service:

Microsoft: Active Directory Server
Microsoft: DHCP Server
Microsoft: DNS Server
Microsoft: Exchange Server
Microsoft: IIS Server
Microsoft: Lync Server 2013
Microsoft: SharePoint Server
Microsoft: SQL Server
Microsoft: Hyper-V Server (partially)
Microsoft: Windows Server (partially)

Enabling and Disabling Concurrent PowerShell for Collector Groups

To improve the process of collecting data via PowerShell and to collect metrics, you can enable concurrent PowerShell collection. You can enable one or more collector groups to use concurrent PowerShell collection.

If you have enabled concurrent collection and you have used it to discover a very large number of devices or interfaces, disabling concurrent collection could have unintended consequences. After disabling concurrent collection, your Data Collector might become overburdened when it attempts to collect data for the same number of devices or interfaces but without the added processing capacity of concurrent collection.

By default, a loopback to 127.0.0.1 is configured on the collector with the line localhost localhost.localdomain localhost4 localhost4.localdomain4 in the /etc/hosts file. If this line is removed, concurrent PowerShell collection will not function properly.

NOTE: Concurrent PowerShell collection is for PowerShell Performance and Performance Configuration Dynamic Application types and does not include Snippet Dynamic Applications that happen to run PowerShell commands.

Enabling and Disabling Concurrent PowerShell on All Collector Groups

To enable and disable concurrent PowerShell collection for all collector groups:

Go to the Behavior Settings page (System > Settings > Behavior).
Select the Enable Concurrent PowerShell Collection checkbox and click Save.
To disable concurrent PowerShell collection, deselect the Enable Concurrent PowerShell Collection checkbox and click Save.

Enabling and Disabling Concurrent PowerShell on a Specific Collector Group

To enable and disable concurrent PowerShell collection for a specific collector group:

Go to the Collector Group Management page (System > Settings > Collector Groups).
Locate the collector group for which you want to enable concurrent PowerShell, and click its wrench icon ().
In the Enable Concurrent PowerShell Collection dropdown menu, select Yes and click Save.
To disable concurrent PowerShell collection, select No in the Enable Concurrent PowerShell Collection dropdown and click Save.

The SL1: Concurrent PowerShell Monitoring PowerPack

The "SL1: Concurrent PowerShell Monitoring" PowerPack includes a device template, two Dynamic Applications that use SSH to monitor collectors with concurrent PowerShell enabled, and a number of event policies.

The "ScienceLogic: PowerShell Collector Performance" Dynamic Application is an optional Dynamic Application used for troubleshooting.
The "ScienceLogic: PowerShell Service Log Parser" Dynamic Application parses the log file from the PowerShell servers and converts errors into events aligned to the related device.
The "SL1: Concurrent PowerShell Monitoring" device template can be used to align multiple Data Collectors to the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application.
Event policies and corresponding alerts that are triggered when devices meet certain status criteria.

Configuring the SL1: Concurrent PowerShell Monitoring PowerPack for Military Unique Deployment (MUD) Environments

To use the "SL1: Concurrent PowerShell Monitoring" PowerPack on Military Unique Deployment (MUD) environments, you must create a new user on each MUD collector. After you have created a new user on each MUD collector, you must edit the sudo config file and the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application.

Configuring the Sudo Config File

CAUTION: ScienceLogic recommends that you use the command sudo visudo. This command verifies changes to the sudoers file before you save it.

After you create a new user on each MUD collector, you must add the following permission to the sudo config file (/etc/sudoers) to allow the new user to use sudo without a password:

User_Alias SL1PARSER = "sl1monitor"

Cmnd_Alias PARSER = /opt/em7/bin/silo_mysql, /usr/bin/grep, /usr/bin/tail, /usr/bin/awk

SL1PARSER ALL = NOPASSWD: PARSER

Configuring the ScienceLogic: PowerShell Service Log Parser Dynamic Application

To edit the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application snippet for a MUD environment:

Go to the Dynamic Applications Manager page (System > Manage > Applications).
Find the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application and click its wrench icon ().
In the Dynamic Applications Properties Editor, click the Snippets tab.
In the Dynamic Applications Snippet Editor & Registry page, click the wrench icon () of the "ScienceLogic: PowerShell Service Log Parser" snippet.
The content of the snippet will appear. Edit the "False" value in the following snippet text to "True":

mud_system = False

NOTE: The only valid values for "mud_system" are "True" or "False". "True" or "False" must be capitalized, as using all lowercase or uppercase letters will result in a snippet exception.

Click Save.

Aligning the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application

To align the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application, first you must create an SSH/Key credential:

Go to the Credential Management page (System > Manage > Credentials).
In the Credential Management page, click the Actions menu. Select Create SSH/Key Credential.
The Credential Editor modal page appears. In this page, define the new SSH/Key credential using a valid username and password or SSH key for SL1 collectors:

Credential Name. Name of the credential. Can be any combination of alphanumeric characters.
Hostname/IP. Hostname or IP address of the device from which you want to retrieve data.

You can include the variable %D in this field. SL1 will replace the variable with the IP address of the current device (device that is currently using the credential).

You can include the variable %N in this field. SL1 will replace the variable with hostname of the current device (device that is currently using the credential). If SL1 cannot determine the hostname, SL1 will replace the variable with the primary, management IP address for the current device.

Port. Port number associated with the data you want to retrieve.

The default TCP port for SSH servers is 22.

Timeout (ms). Time, in milliseconds, after which SL1 will stop trying to communicate with the authenticating server.
Username. Username for the Data Collector to be monitored.
Password. Password for the Data Collector to be monitored.
Private Key (PEM Format). Enter an SSH private key for the SL1 Data Collector, in PEM format.

Click the Save button to save the new SSH/Key credential.

Next, you can align the Dynamic Application manually or configure the device template. Using the device template is recommended when you want to align the Dynamic Application to multiple Data Collectors.

Manually Aligning the Dynamic Application

After creating the SSH/Key credential, you will manually align the Dynamic Application.

Go to the Devices page and find the device you want to manually align the Dynamic Application to. Click on it to go to the Device Investigator.
In the Device Investigator, click the Collections tab. Click Edit and then click Align Dynamic App. The Align Dynamic Application window appears.
Click Choose Dynamic Application. The Choose Dynamic Application window appears.
Select the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application and click Select. The "ScienceLogic: PowerShell Service Log Parser" Dynamic Application appears in the Align Dynamic Application window.
If a default credential is listed below the Dynamic Application and you want to use that credential, skip ahead to step 8. Otherwise, uncheck the box next to the credential name.
Click Choose Credential. The Choose Credential window appears.
Select the credential for the Dynamic Application and click the Select button. The name of the selected credential appears in the Align Dynamic Application window.
Click the Align Dynamic App button. When the Dynamic Application is successfully aligned, it is added to the Collections tab, and a confirmation message appears at the bottom of the tab.

To manually align the Dynamic Application using the SL1 classic user interface:

Go to the Device Manager page (Devices > Device Manager)
In the Device Manager page, find the device for which you want to view Dynamic Applications. Select its wrench icon ()
In the Device Administration panel, select the Collections tab.
Click the Actions button and then select Add Dynamic Application. The Dynamic Application Alignment page appears
In the Dynamic Applications field, select the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application.
In the Credentials field, select the proper credential.
Click the Save button.

Configuring the Device Template

After creating the SSH/Key credential, you will need to configure the device template included in the PowerPack.

NOTE: If you have already manually aligned the Dynamic Application, you do not need to perform the steps in this section.

To configure the device template:

Go to the Configuration Templates page (Registry > Devices > Templates).
Locate the "SL1: Concurrent PowerShell Monitoring" sample template and click its wrench icon (). The Device Template Editor modal page appears.
Type a new name for the device template in the Template Name field so the sample template is not overwritten.
Click the Dyn Apps tab. The Editing Dynamic Application Subtemplates page appears.

In the Subtemplate Selection pane, select the "ScienceLogic: PowerShell Service Log Parser" Dynamic Application.
In the Credentials drop-down list, select the SSH/Key credential that you created.
Click Save As.

Applying the Device Template

If your Data Collector devices already exist on your SL1 system, perform the following steps to apply the device template:

Go to the Device Manager page (Registry > Devices > Device Manager) and select the checkbox for each of your Data Collector devices.
In the Select Action menu, select MODIFY By Template and then click Go.
In the Device Template Editor, select the template you created in the Template field.
Click Apply.

If your devices have not yet been discovered, perform the following steps to discover the devices and apply the device template:

Go to the Discovery Control Panel page (System > Manage > Classic Discovery) and click Create.
Supply values in the following fields:

Name. Type a name for the discovery session.

Description. Optionally, type a description of the discovery session.

IP Address/Hostname Discovery List. Provide a list of IP addresses for your Data Collectors.

SNMP Credentials. Select EM7 Default V2.

Model Devices. Select this checkbox.

Apply Device Template. Select the device template that you created.

Log All. Select this checkbox.

Click the Save button to save the discovery session. Close the Discovery Session Editor page.
In the Discovery Control Panel page, click the Reset button. The new discovery session will appear in the Session Register pane.
To launch the new discovery session, click its Queue this Session icon ().
If no other discovery sessions are currently running, the session will be executed immediately. If another discovery session is currently running, your discovery session will be queued for execution.

Aligning the "ScienceLogic: PowerShell Collector Performance" Dynamic Application

If you want to monitor your Data Collectors with the "ScienceLogic: PowerShell Collector Performance" Dynamic Application, you must manually align it to your Data Collectors using the SSH/Key credential. To do this:

Go to the Devices page and find the device you want to manually align the Dynamic Application to and click on it to go to the Device Investigator.
In the Device Investigator, click the Collections tab. Click Edit and then click Align Dynamic App. The Align Dynamic Application window appears.
Click Choose Dynamic Application. The Choose Dynamic Application window appears.
Select the "ScienceLogic: PowerShell Collector Performance" Dynamic Application and click Select. The "ScienceLogic: PowerShell Collector Performance" Dynamic Application appears in the Align Dynamic Application window.
If a default credential is listed below the Dynamic Application and you want to use that credential, skip ahead to step 8. Otherwise, uncheck the box next to the credential name.
Click Choose Credential. The Choose Credential window appears.
Select the credential for the Dynamic Application and click the Select button. The name of the selected credential appears in the Align Dynamic Application window.
Click the Align Dynamic App button. When the Dynamic Application is successfully aligned, it is added to the Collections tab, and a confirmation message appears at the bottom of the tab.

To manually align the Dynamic Application using the SL1 classic user interface:

Go to the Device Manager page (Devices > Device Manager)
In the Device Manager page, find the device for which you want to view Dynamic Applications. Select its wrench icon ()
In the Device Administration panel, select the Collections tab.
Click the Actions button and then select Add Dynamic Application. The Dynamic Application Alignment page appears
In the Dynamic Applications field, select the "ScienceLogic: PowerShell Collector Performance" Dynamic Application.
In the Credentials field, select the proper credential.
Click the Save button.

Enabling HTTPS Between SL1 and the PowerShell Data Collector

You can enable or disable HTTPS as the mode of transport for communication between SL1 and the PowerShell Data Collector. The Powershell Data Collector is a service that runs on the Collector Group. The Data Collection service on the Collector Group can optionally communicate with the PowerShell Service to queue jobs and check for results using HTTPS. You would enable HTTPS if you must meet federal requirements to encrypt all network traffic, even if it never leaves the host.

To enable or disable HTTPS as the mode of transport for communication between SL1 and the PowerShell Data Collector, you must make some changes to the /opt/em7/services/powershell_collector/powershell_collector.env configuration file. This file can also be used to configure the certificates used by the container when running on HTTPS.

The keys used are:

Key	Value
USE_HTTPS	Default value is True. If set to False, HTTPS is disabled and the remaining SSL-related keys have no effect.
SSL_PRIVATE_KEY SSL_SERVER_CERT SSL_CA_CERT	These keys are used to specify the full path and filename of the certificate to be used by the PowerShell Data Collector when HTTPS is enabled. If these keys are not set, a self-signed certificate will be generated when the container is started. When specifying the file name and path, they must be accessible to the PowerShell Data Collector. For example, the directory /etc/ssl/certs is mapped to the PowerShell Data Collector, meaning any files within this directory are accessible to the PowerShell Data Collector, subject to the files' permissions. Any certificates placed in the directory on the PowerShell Data Collector must have the keys set as follows: SSL_PRIVATE_KEY=/etc/ssl/certs/my_cert.key Once the key is set, the Data Collector will pick up the files in the directory on startup. NOTE: USE_HTTPS must be set to True for these keys to work.
SSL_VERIFY	When USE_HTTPS is set to True, this key is used by SL1 when communicating with the PowerShell Data Collector. By default, the value is False. If set to True, the HTTPS connection will fail if the Data Collector is using a self-signed certificate.

Enabling and Disabling the Python PowerShell Remoting Protocol Client

If you have concurrent PowerShell enabled in SL1, the default Python module used for transport to monitor Windows Devices is "pyWinRm". However, the "pypsrp" Python module can provide more efficient processing of PowerShell commands, particularly when virus detection software is enabled. To use the "pypsrp" module instead, run the following SQL query on the Database Tool page (System > Tools > DB Tool):

Select your database from the Select Database list.
Enter the following in the SQL Query field.

INSERT master.system_custom_config (field, field_value) VALUES ('enable_pypsrp_lib', 1)

A value of 1 will enable the "pypsrp" module. A value of 0 (or not having any setting for 'enable_pypsrp_lib') will revert to using "pyWinRM".

Click Go.

To disable "pypsrp", use the following SQL query:

UPDATE master.system_custom_config set field_value = 0 WHERE field = 'enable_pypsrp_lib'

Currently, you can only use the "pypsrp" module with concurrent PowerShell. Classic PowerShell monitoring will continue to use the "pyWinRM" module regardless of this database setting.

Optional PowerShell CLI Parameters

You can use the following parameters in PowerShell for the associated reasons:

-NoProfile. Does not load the PowerShell profile.
-NoLogo. Hides the copyright banner at startup.
-NonInteractive. Does not present an interactive prompt to the user.

To enable concurrent PowerShell collection to use one of these parameters:

Go to the Database Tool page (System > Tools > DB Tool).
If this row does not already exist in the master.system_custom_config table, enter the following in the SQL Query field:

INSERT INTO master.system_custom_config (`powershell_prefix_setting`, `<PREFIX INTEGER>`)

where:

<PREFIX> is an integer that represents one of the prefix values described above. The integers are as follows:

0. Disabled
1. -NoProfile
2. -NoLogo
3. -NoProfile and -NoLogo
4. -NonInteractive
7. -NoProfile, -NoLogo, and -NonInteractive

For example, if a user wanted to configure their PowerShell Data Collector to not load their PowerShell profile, they would enter the following into the SQL Query field:

INSERT INTO master.system_custom_config (`powershell_prefix_setting`, `1`)

If this row already exists in the master.system_custom_config table, enter the following in the SQL Query field:

UPDATE master.system_custom_config SET field_value = 1 WHERE field = `powershell_prefix_setting`

After you have entered the command in the SQL Query field, click the Go button. Your changes will be picked up with the next batch of jobs that are processed.

Users with Windows 2008 R2 Servers or Windows 2012 Servers

Concurrent PowerShell collection will not work for Windows 2008 R2 servers or Windows 2012 servers when the Encyrpted field is set to Yes in the PowerShell credential. Windows 2008 R2 servers and Windows 2012 servers are no longer covered by Microsoft's Extended Support, but if you are still using those servers you have the following options:

Use PowerShell credentials that have Encryption set to No.
Disable the Concurrent PowerShell service on the Data Collector groups that include Windows 2008 R2 servers or Windows 2012 servers. This will reduce the number of servers that Data Collector group can support.
Use the Microsoft Base Pack (WMI-based) PowerPack for the Windows 2008 R2 servers or the Windows 2012 servers.
Use SNMP for the Windows 2008 R2 servers or the Windows 2012 servers.

Scale Recommendations

The following recommendations increase the number of Windows Servers the concurrent PowerShell collector can support:

In the Device Properties page for all Windows Server devices (Registry > Devices > wrench icon), unselect the Dynamic Discovery checkbox. Alternatively, this can be set in bulk using a device template and device group. This prevents nightly discovery from attempting to align Dynamic Applications with a discovery object to all the devices on the collector, which does not use the concurrent PowerShell collector and will dramatically limit the number of Windows Server devices that can be monitored.
Do not select any credentials in the discovery session used to discover new Windows Servers. Instead, use a template that includes unselecting the Dynamic Discovery checkbox and includes the desired Dynamic Applications with the appropriate credential aligned. When a credential is selected in the Discovery Session, it will attempt to align Dynamic Applications that include a discovery object, which does not use the concurrent PowerShell collector and will dramatically limit the number of Windows Server devices that can be monitored. The Microsoft: Windows Server PowerPack includes the "Microsoft: Windows Server Discovery Template" that you can use be used to create your template.

For information on creating and using device templates, see the Device Groups and Device Templates section.

Additional Scale Tips

The "Microsoft: Windows Server Services" PowerPack has been deprecated. To monitor services, use version 113 or later of the "Microsoft: Windows Server" PowerPack.
Limit the use of the "Microsoft: Windows Server Event Logs" PowerPack as it does not work with the concurrent PowerShell collector.
Use the "Microsoft: SQL Server" PowerPack instead of the "Microsoft: SQL Server Enhanced" PowerPack. The "Microsoft: SQL Server Enhanced" PowerPack does not work with the concurrent PowerShell collector.
Disable Dynamic Applications that are not providing information required to meet your Service Level Agreements. There is an enhancement in caching included with concurrent PowerShell collection that will not send a PowerShell request from a cache-producing Dynamic Application unless at least one Dynamic Application is asking for that data. Disabling a cache-consuming Dynamic Application will also disable the cache producer from collecting that data. For example, the following Dynamic Applications are now disabled by default, as they are more diagnostic in nature and may not be required for routine monitoring:

Microsoft: Windows Server IPStats Performance
Microsoft: Windows Server TCPStats Performance
Microsoft: Windows Server UDPStats Performance

Slow down the Poll Frequency for Dynamic Applications that do not include events. For example, the "Microsoft: Windows Server" PowerPack's Configuration Dynamic Applications used to be set to run every two hours and are now set to run every 12 hours.