Sciencelogic Monitoring Windows Powershell 8-14-1
Sciencelogic Monitoring Windows Powershell 8-14-1
PowerShell
SL1 version 8.14.1
Table of Contents
Introduction 4
Monitoring Windows Devices in the ScienceLogic Platform 5
What is SNMP? 5
What is PowerShell? 5
PowerPacks 6
Configuring Windows Systems for Monitoring with SNMP 7
Configuring SNMP for Windows Server 2016 and Windows Server 2012 8
Configuring Ping Responses 8
Installing the SNMP Service 9
Configuring the SNMP Service 14
Configuring the Firewall to Allow SNMP Requests 19
Configuring Device Classes for Windows Server 2016 and Windows 10 19
Manually Align the Device Class 20
Edit the Registry Key 20
Configuring SNMP for Windows Server 2008 21
Configuring Ping Responses 21
Installing the SNMP Service 22
Configuring the SNMP Service 25
Configuring the Firewall to Allow SNMP Requests 30
Configuring Windows Servers for Monitoring with PowerShell 31
Prerequisites 32
Configuring PowerShell 32
Step 1: Configuring the User Account for the ScienceLogic Platform 33
Option 1: Creating an Active Directory Account with Administrator Access 33
Option 2: Creating a Local User Account with Administrator Access 34
Option 3: Creating a Non-Administrator User Account 34
Optional: Configuring the User Account for Remote PowerShell Access to Microsoft Exchange Server 36
Optional: Configuring the User Account for Remote PowerShell Access to Hyper-V Servers 36
Creating a User Group and Adding a User in Active Directory 36
Setting the Session Configuration Parameters and Group Permissions 37
Creating a PowerShell Credential 38
Optional: Configuring the User Account for Access to Windows Failover Cluster 38
Step 2: Configuring a Server Authentication Certificate 38
Option 1: Using the Microsoft Management Console to Create a Self-Signed Authentication Certificate 39
Option 2: Using the MakeCert Tool to Create a Self-Signed Authentication Certificate 41
Option 3: Using PowerShell Commands to Create a Self-Signed Authentication Certificate 41
Step 3: Configuring Windows Remote Management 42
Option 1: Using a Script to Configure Windows Remote Management 42
Option 2: Manually Configuring Windows Remote Management 47
Option 3: Using a Group Policy to Configure Windows Remote Management 50
Step 4: Configuring a Windows Management Proxy 68
Step 5: Increasing the Number of PowerShell Dynamic Applications That Can Run Simultaneously 69
SNMP and PowerShell Dynamic Applications for Windows Devices 70
SNMP Dynamic Applications for Windows Devices 71
PowerShell Dynamic Applications 71
Microsoft: Active Directory Server 71
Microsoft: DHCP Server 72
Microsoft: DNS Server 72
Microsoft: Exchange Server 73
Microsoft: Exchange Server 2010 73
Microsoft: Hyper-V Server 74
Microsoft: IIS Server 75
Microsoft: Lync Server 2010 75
Microsoft: SharePoint Server 76
Microsoft: Skype for Business 76
Microsoft: SQL Server 77
Microsoft: Windows Server 78
Microsoft: Windows Server Event Logs 79
Microsoft: Windows Server Services 80
Run Book Automations and Actions Associated with PowerShell Dynamic Applications for Windows
Servers 80
Error Messages for PowerShell Collection 81
Relationships with Other Types of Component Devices 82
Creating SNMP and PowerShell Credentials for Windows Devices 83
Creating an SNMP Credential 83
Creating a PowerShell Credential 86
Testing Windows Credentials 89
SNMP Credential Test 89
PowerShell Credential Test 89
Running a Windows Credential Test 89
Discovering Component Devices on Hyper-V Systems 91
Viewing Component Devices 91
Manually Aligning the Microsoft: Print Server Dynamic Application 92
Executing the SL1 Agent with Windows PowerShell 94
What is an SL1 Agent? 94
Agent-Compatible PowerPacks 95
The Credential for the SL1 Agent 95
Configuring the SL1 Agent Device Template 96
Windows Dashboards 97
Installing the Microsoft Server Dashboards 97
Microsoft: Active Directory Server Performance 99
Microsoft: DNS Server Performance 102
Microsoft: Exchange Server 2010 Performance 104
Microsoft: Exchange Server 2013 Performance 107
Microsoft: IIS Server Performance 110
Microsoft: Lync Server 2010 Dashboards 112
Microsoft: Lync Server 2010 Performance 112
Microsoft: Lync Server 2010 Utilization 115
Microsoft: Skype for Business Dashboards 118
Microsoft: Lync Server 2013 Performance 118
Microsoft: Lync Server 2013 Utilization 121
Microsoft: SQL Server Performance 124
Troubleshooting 128
Troubleshooting WinRM Error Messages 128
Debugging Code 401 Errors 129
Debugging Code 500 Errors 130
Troubleshooting PowerShell Error Messages 131
Chapter
1
Introduction
Overview
This manual describes how to monitor Windows systems in SL1 using SNMP and PowerShell credentials and
Dynamic Applications.
The following sections provide an overview of SNMP and PowerShell, as well as the PowerPacks you can use to
monitor Windows systems in SL1:
NOTE: ScienceLogic provides this documentation for the convenience of ScienceLogic customers. Some of
the configuration information contained herein pertains to third-party vendor software, which is
subject to change without notice to ScienceLogic. ScienceLogic makes every attempt to maintain
accurate technical information and cannot be held responsible for defects or changes in third-party
vendor software. There is no written or implied guarantee that information contained herein will work
for all third-party variants. See the End User License Agreement (EULA) for more information.
4
Monitoring Windows Devices in the ScienceLogic Platform
SL1 can monitor a Windows device using the following methods:
NOTE: This manual describes how to monitor Windows with SNMP and PowerShell. For more information
about using WMI to monitor Windows devices, see the Monitoring Windows with WMI manual.
What is SNMP?
SNMP (Simple Network Management Protocol) is a set of standard protocols for managing diverse computer
hardware and software within a TCP/IP network. SNMP is the most common network protocol used by network
monitoring and management applications to exchange management information between devices. SL1 uses this
protocol and other protocols to collect availability and performance information.
SNMP uses a server-client structure. Clients are called agents. Devices and software that run SNMP are agents.
The server is called the management system. SL1 is the management system.
Most network hardware is configured for SNMP and can be SNMP-enabled. Many enterprise software applications
are also SNMP-compliant. When SNMP is running on a device, it uses a standard format to collect and store data
about the device and/or software. For example, SNMP might collect information on each network interface and
the traffic for each interface. SL1 can then query the device to retrieve the stored data.
What is PowerShell?
Windows PowerShell is a command-line shell and scripting language for administration of Windows systems. SL1
can execute PowerShell requests on target Windows devices via WinRM (Windows Remote Management). For an
overview of Windows PowerShell, see https://docs.microsoft.com/en-us/powershell/scripting/powershell-
scripting?view=powershell-6.
SL1 supports the following PowerShell versions for monitoring Windows devices:
l PowerShell 3.0
l PowerShell 4.0
l PowerShell 5.1
PowerPacks 6
Chapter
2
Configuring Windows Systems for Monitoring
with SNMP
Overview
The following sections describe how to configure Windows Server 2016, Windows Server 2012, and Windows
Server 2008 for monitoring by SL1 using SNMP:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 8
Configuring Ping Responses 8
Installing the SNMP Service 9
Configuring the SNMP Service 14
Configuring the Firewall to Allow SNMP Requests 19
Configuring Device Classes for Windows Server 2016 and Windows 10 19
Manually Align the Device Class 20
Edit the Registry Key 20
Configuring SNMP for Windows Server 2008 21
Configuring Ping Responses 21
Installing the SNMP Service 22
Configuring the SNMP Service 25
Configuring the Firewall to Allow SNMP Requests 30
7
Configuring SNMP for Windows Server 2016 and Windows
Server 2012
To configure SNMP on a Windows 2016 Server or a Windows 2012 Server, you must:
The default configuration for a Windows Server does not allow ICMP "Ping" requests and does not allow
connections to TCP ports 21, 22, 23, 25, or 80. Therefore, to discover a Windows Server in SL1, you must
perform one of the following tasks:
l Reconfigure the firewall on the Windows Server to allow ICMP "Ping" requests. This section describes how to
perform this task.
l Reconfigure the firewall on the Windows Server to allow connections to port 21, 22, 23, 25, or 80. If you
have already configured your Windows Server to accept SSH, FTP, Telnet, SMTP, or HTTP connections, this
task might have been completed already. You should perform this task only if you were already planning to
allow SSH, FTP, Telnet, SMTP, or HTTP connections to your Windows Server.
l When you create the discovery session that will discover the Windows Server, select at least one port in the
Detection Method & Port field that is open on the Windows Server. For example, if your Windows Server is
configured as an MSSQL Server, you could select port 1433 (the default port for MSSQL Server) in the
Detection Method & Port field.
To reconfigure the firewall on a Windows Server to allow ICMP "Ping" requests, perform the following steps:
1. In the Start menu search bar, enter "firewall" to open a Windows Firewall with Advanced Security
window.
2. In the left pane, select Inbound Rules.
3. If you want SL1 to discover your Windows Server using an IPv4 address, locate the File and Printer Sharing
(Echo Request - ICMPv4-In) rule.
8 Configuring SNMP for Windows Server 2016 and Windows Server 2012
4. If you want SL1 to discover your Windows Server using an IPv6 address, locate the File and Printer Sharing
(Echo Request - ICMPv6-In) rule.
5. Right click on the rule that you located, then select Enable Rule:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 9
3. If the server does not skip the Before you begin page, click the [Next >] button to manually skip it. The
Select installation type page is displayed:
10 Configuring SNMP for Windows Server 2016 and Windows Server 2012
4. Click the [Next >] button to continue with Role-based or feature-based installation. The Select destination
server page is displayed:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 11
5. Ensure the Windows 2012 server or Windows 2016 Server is selected and then click the [Next >] button.
The Select server roles page is displayed.
6. Click the [Next >] button without selecting any additional roles. The Select features page is displayed:
12 Configuring SNMP for Windows Server 2016 and Windows Server 2012
7. Select the SNMP Service checkbox. The following confirmation window is displayed:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 13
10. Click the [Next >] button. The Confirm installation selections page is displayed:
NOTE: If you recently installed the SNMP service, you must wait for the Server Manager window to refresh to
allow the SNMP service snap-in to be added. You can manually refresh the Server Manager
window by closing the Server Manager and then re-opening the Server Manager.
1. In the upper-right of the Server Manager window, select [Tools] > Services. The Services window is
displayed.
14 Configuring SNMP for Windows Server 2016 and Windows Server 2012
2. In the Services window, right-click on SNMP Service, and then select Properties. The SNMP Service
Properties window appears:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 15
4. Select the [Security] tab. The security settings are displayed:
16 Configuring SNMP for Windows Server 2016 and Windows Server 2012
5. In the Accepted community names panel, click the [Add...] button. The SNMP Service Configuration
pop-up window is displayed:
l Community rights. Select one of the following options from the drop-down list:
o READ ONLY. Select this option to allow SL1 to request information from this Windows 2012 Server
or Windows 2016 Server using this SNMP community string. This option does not allow SL1 to
perform write operations on this Windows 2012 Server or Windows 2016 Server using this SNMP
community string.
o READ WRITE. Select this option to allow SL1 to request information from this Windows 2008 server
and to perform write operations on this Windows 2012 Server or a Windows 2016 Serve using this
SNMP community string.
Configuring SNMP for Windows Server 2016 and Windows Server 2012 17
l Community name. Enter the SNMP community string that SL1 will use when making SNMP requests
to this Windows 2012 Server or Windows 2016 Server. When you create a credential for this
Windows 2012 Server or Windows 2016 Server in SL1, you will enter this community string in one
the following fields in the Credential Editor modal page:
o SNMP Community (Read-Only). Enter the SNMP community string in this field if you selected READ
ONLY in the Community rights drop-down list.
o SNMP Community (Read/Write). Enter the SNMP community string in this field if you selected
READ WRITE in the Community rights drop-down list.
7. Click the [Add] button to add the community string to the list of community strings this Windows 2012 Server
or Windows 2016 Server accepts.
8. In the Accept SNMP packets from these hosts panel, click the Add... button. The SNMP Service
Configuration pop-up window is displayed:
9. In the Host name, IP or IPX address field, enter the IP address of the All-In-One Appliance or Data
Collector that will monitor this server.
18 Configuring SNMP for Windows Server 2016 and Windows Server 2012
10. Click the [Add] button to add the appliance to the list of authorized devices.
11. If you are using SL1 with a distributed architecture, repeat steps 8–10 for each Data Collector in the collector
group that will monitor this server.
12. Click the [Apply] button to apply all changes.
1. In the Start menu search bar, enter "firewall" to open a Windows Firewall with Advanced Security
window.
2. In the left pane, click Inbound Rules.
3. Locate the two SNMP Service (UDP In) rules.
4. If one or both of the rules is not enabled, right-click on the rule and then select Enable Rule:
Configuring SNMP for Windows Server 2016 and Windows Server 2012 19
Because Microsoft has deprecated support of SNMP on Microsoft Server 2016 and Windows 10, users who want
to use SNMP to monitor Windows 10 and Microsoft Server 2016 should use one of these workarounds:
l After discovering a Microsoft Server 2016 or Windows 10 device, manually align the device class and
disable nightly auto-discovery
l Edit the registry key
After discovering Microsoft Server 2016 devices and Windows 10 devices, you can manually align a device class
with the discovered devices. To preserve your manual changes, you must disable nightly auto-discovery for those
devices. You can manually align the discovered devices with one of these device classes:
For details on manually assigning a device class to a device, follow the steps in the section on Manually Changing
the Device Class for a Device in the Device Management manual chapter on Managing Device Classes and
Device Categories. For details on disabling nightly auto-discovery for a device, see the section on Maintaining the
New Device Class During Auto-Discovery in the Device Management manual chapter on Managing Device
Classes and Device Categories.
You can log in to the device that you want to monitor and manually edit the Windows Registry Key "HKEY_LOCAL_
MACHINE\Software\Microsoft\Windows NT\CurrentVersion". You can define the value CurrentVersion as either
"2016" or "10.0". To do this:
20 Configuring SNMP for Windows Server 2016 and Windows Server 2012
Configuring SNMP for Windows Server 2008
To configure SNMP on a Windows 2008 Server, you must:
The default configuration for a Windows Server does not allow ICMP "Ping" requests and does not allow
connections to TCP ports 21, 22, 23, 25, or 80. Therefore, to discover a Windows Server in SL1, you must
perform one of the following tasks:
l Reconfigure the firewall on the Windows Server to allow ICMP "Ping" requests. This section describes how to
perform this task.
l Reconfigure the firewall on the Windows Server to allow connections to port 21, 22, 23, 25, or 80. If you
have already configured your Windows Server to accept SSH, FTP, Telnet, SMTP, or HTTP connections, this
task might have been completed already. You should perform this task only if you were already planning to
allow SSH, FTP, Telnet, SMTP, or HTTP connections to your Windows Server.
l When you create the discovery session that will discover the Windows Server, select at least one port in the
Detection Method & Port field that is open on the Windows Server. For example, if your Windows Server is
configured as an MSSQL Server, you could select port 1433 (the default port for MSSQL Server) in the
Detection Method & Port field.
To reconfigure the firewall on a Windows Server to allow ICMP "Ping" requests, perform the following steps:
1. In the Start menu search bar, enter "firewall" to open a Windows Firewall with Advanced Security
window.
2. In the left pane, select Inbound Rules.
3. If you want SL1 to discover your Windows Server using an IPv4 address, locate the File and Printer Sharing
(Echo Request - ICMPv4-In) rule.
4. If you want SL1 to discover your Windows Server using an IPv6 address, locate the File and Printer Sharing
(Echo Request - ICMPv6-In) rule.
3. If the Features Summary displays "SNMP Service" and "SNMP WMI Provider" in the list of installed services
(as shown above), you can skip to the section on configuring the SNMP service. If "SNMP Service" and
"SNMP WMI Provider" are not included in the list of installed services, select Add Features:
5. Click the [Next >] button. The Confirm Installed Selections window is displayed with "SNMP Service" and
"SNMP WMI Provider" in the list of features that will be installed:
NOTE: If you recently installed the SNMP service, you must wait for the Server Manager window to refresh
before it will display the SNMP service snap-in. You can manually refresh the Server Manager
window by closing the Server Manager and then re-opening the Server Manager.
1. In the left pane of the Server Manager window, expand the Configuration section, and then select Services.
l Community rights. Select one of the following options from the drop-down list:
o READ ONLY. Select this option to allow SL1 to request information from this Windows 2008 Server
using this SNMP community string. This option does not allow SL1 to perform write operations on
this Windows 2008 Server using this SNMP community string.
o READ WRITE. Select this option to allow SL1 to request information from this Windows 2008 server
and to perform write operations on this Windows 2008 Server using this SNMP community string.
o SNMP Community (Read-Only). Enter the SNMP community string in this field if you selected READ
ONLY in the Community rights drop-down list.
o SNMP Community (Read/Write). Enter the SNMP community string in this field if you selected
READ WRITE in the Community rights drop-down list.
7. Click the [Add] button to add the community string to list of community strings this Windows 2008 Server
accepts.
8. In the Accept SNMP packets from these hosts panel, click the Add... button. The SNMP Service
Configuration pop-up window is displayed:
9. In the Host name, IP or IPX address field, enter the IP address of the All-In-One Appliance or Data
Collector that will monitor this server.
10. Click the [Add] button to add the appliance to the list of authorized devices.
1. In the Start menu search bar, enter "firewall" to open a Windows Firewall with Advanced Security
window.
2. In the left pane, click Inbound Rules.
3. Locate the two SNMP Service (UDP In) rules.
4. If one or both of the rules is not enabled, right-click on the rule and then select Enable Rule:
3
Configuring Windows Servers for Monitoring
with PowerShell
Overview
The following sections describe how to configure Windows Server 2016, 2012, 2012 R2, or 2008 R2 for
monitoring by SL1 using PowerShell:
Prerequisites 32
Configuring PowerShell 32
Step 1: Configuring the User Account for the ScienceLogic Platform 33
Option 1: Creating an Active Directory Account with Administrator Access 33
Option 2: Creating a Local User Account with Administrator Access 34
Option 3: Creating a Non-Administrator User Account 34
Optional: Configuring the User Account for Remote PowerShell Access to Microsoft Exchange Server 36
Optional: Configuring the User Account for Remote PowerShell Access to Hyper-V Servers 36
Creating a User Group and Adding a User in Active Directory 36
Setting the Session Configuration Parameters and Group Permissions 37
Creating a PowerShell Credential 38
Optional: Configuring the User Account for Access to Windows Failover Cluster 38
Step 2: Configuring a Server Authentication Certificate 38
Option 1: Using the Microsoft Management Console to Create a Self-Signed Authentication Certificate 39
Option 2: Using the MakeCert Tool to Create a Self-Signed Authentication Certificate 41
Option 3: Using PowerShell Commands to Create a Self-Signed Authentication Certificate 41
Step 3: Configuring Windows Remote Management 42
31
Option 1: Using a Script to Configure Windows Remote Management 42
Option 2: Manually Configuring Windows Remote Management 47
Option 3: Using a Group Policy to Configure Windows Remote Management 50
Step 4: Configuring a Windows Management Proxy 68
Step 5: Increasing the Number of PowerShell Dynamic Applications That Can Run Simultaneously 69
Prerequisites
Before configuring PowerShell, ensure the following:
l Forward and Reverse DNS should be available for the target Windows server from the SL1 Data Collector.
Port 53 to the domain's DNS server should thus be available.
l When using an Active Directory user account as the SL1 credential, port 88 on the Windows Domain
Controller, for the Active Directory domain, should be open for Kerberos authentication.
l If encrypted communication between the SL1 Data Collector and monitored Windows servers is desired, port
5986 on the Windows server should be open for HTTPS traffic. If unencrypted communications is being
used, then port 5985 on the Windows server should be opened for HTTP traffic
l If multiple domains are in use, ensure that they are mapped in the [domain_realm] section of the Kerberos
krb5.conf file.
Configuring PowerShell
To monitor a Windows Server using PowerShell Dynamic Applications, you must configure the Windows Server to
allow remote access from SL1. To do so, you must perform the following general steps:
1. Configure a user account that SL1 will use to connect to the Windows Server. The user account can either
be a local account or an Active Directory account.
TIP: For ease of configuration, ScienceLogic recommends using an Active Directory account that is a member
of the local Administrators group on the Windows Server.
2. Configure a Server Authentication Certificate to encrypt communication between SL1 and the Windows
Server.
NOTE: If you are configuring multiple Windows servers for monitoring by SL1, you can apply these settings
using a Group Policy.
32 Prerequisites
5. Optionally, you can increase the number of PowerShell Dynamic Applications that can run
simultaneously against a single Windows server.
To configure the Windows Server user account that SL1 can use to make PowerShell requests, complete one of
the following options:
TIP: For ease-of-configuration, ScienceLogic recommends creating an Active Directory user account.
After creating your Windows Server user account, depending on your setup and the servers you want to monitor,
you might also need to configure the user account for remote PowerShell access to the following server types:
l If you use SL1 to monitor Microsoft Exchange Servers, you must configure the user account for remote
PowerShell access to Microsoft Exchange Server.
l If you use SL1 to monitor Hyper-V Servers, you must configure the user account for remote PowerShell
access to the Hyper-V Servers.
l Otherwise, you can skip the remainder of this section and proceed to Step 3.
WARNING: This method does not work for Windows Server 2008.
After creating your local user account with Local Administrator access:
l If you use SL1 to monitor Microsoft Exchange Servers, you must configure the user account for remote
PowerShell access to Microsoft Exchange Server.
l If you use SL1 to monitor Hyper-V Servers, you must configure the user account for remote PowerShell
access to the Hyper-V Servers.
l Otherwise, you can skip the remainder of this section and proceed to Step 2.
l You must configure the Windows servers to allow that non-administrator user access. To do so, follow the
steps in this section.
l If you use SL1 to monitor Microsoft Exchange Servers, you must also configure the user account for
remote PowerShell access to Microsoft Exchange Server.
l If you use SL1 to monitor Hyper-V Servers, you must also configure the user account for remote
PowerShell access to the Hyper-V Servers.
1. Start a Windows PowerShell shell with Run As Administrator and execute the following command:
2. On the Permissions for Default window, click the [Add] button, and then add the non-administrator user
account.
3. Select the Allow checkbox for the Read (Get, Enumerate, Subscribe) and Execute (Invoke) permissions for
the user, and then click [OK].
NOTE: To open services.msc, press the Windows + R keys, type "services.msc", and then press Enter.
15. In the Management console, go to System Tools > Local Users and Groups > Groups.
16. Right-click Performance Monitor Users, and then select Properties.
17. On the Performance Monitor Users Properties window, click the [Add] button.
18. In the Enter the object names to select field, type the non-administrator domain user or group name, and
then click [Check Names].
19. Select the user or group name from the list and then click [OK].
20. In the Performance Monitor Users Properties window, click [OK].
21. Perform steps 16-20 for the Event Log Readers user group and again for the Distributed COM Users user
group, the Remote Management Users user group, and if it exists on the server, the
WinRMRemoteWMIUsers__ user group.
22. If you intend to use encrypted communications between the SL1 collector host and your monitored Windows
servers, each Windows server must have a digital certificate installed that has "Server Authentication" as an
Extended Key Usage property. You can create a self-signed certificate for WinRM by executing the following
command:
24. Ensure that your local firewall allows inbound TCP connections on port 5986 if you are going to use
encrypted communications between the SL1 collector(s) and the Windows server, or port 5985 if you will be
using unencrypted communications between the two. You may have to create a new rule on Windows
Firewall if one does not already exist.
1. Follow the steps in the section Configuring the User Account for SL1.
2. Add the new user account to the “Server Management” Exchange security group in Active Directory.
3. The user account will then be able to connect to the relevant WinRM endpoint to use cmdlets installed with
the Exchange Management Shell. For example, this will give the user account access to the cmdlet “Get-
ExchangeServer”.
1. In Active Directory, in the same DC as the Hyper-V host you want to monitor, in the OU called Users, create
a group. For example, we called our group PSSession Creators.
2. Add a user that meets the requirements for monitoring a Windows server via PowerShell to the group. This is
the user that you will specify in the PowerShell credential.
Setti ng the Sessi on Confi g ura ti on Pa ra m eters a nd Group Perm i ssi ons
To set the Session Configuration and the Group Permissions on the Hyper-V Server:
l Group or user names. Select the name of the group you created in Active Directory.
l Permissions for group. For Full Control (All Operations), select the Allow checkbox.
To create a PowerShell credential using the new user account, follow the instructions in the Creating a
PowerShell Credential section.
1. Start a Windows PowerShell shell with Run As Administrator and execute the following command:
If you have created a local account on the Windows Server that uses Basic Auth and that account will allow
communication between SL1 and the Windows server, the best practice for security is to enable HTTPS to support
encrypted data transfer and authentication. To do this, you must configure WinRM to listen for HTTPS requests. This
is called configuring an HTTPS listener.
NOTE: For details on configuring WinRM on your Windows servers to use HTTPS, see
https://support.microsoft.com/en-us/help/2019527/how-to-configure-winrm-for-https.
The sections below describe how to configure a Server Authentication Certificate on the Windows Server. This is
only one task included in configuring an HTTPS listener. However, not all users need to configure a Server
Authentication Certificate. You can find out if your Windows computer has a digital certificate installed for Server
Authentication by running 'Get-ChildItem -Path Cert:\LocalMachine\My -EKU "*Server
Authentication*"' from a PowerShell command shell.
To support encrypted data transfer and authentication between SL1 and the servers, one of the following must be
true:
l You have created an Active Directory user account on the Windows Server to allow communication
between SL1 and the server. In this scenario, Active Directory will use Kerberos and AES-256 encryption to
ensure secure data transfer and authentication, which means you do not need to configure a self-signed
Server Authentication Certificate. You can skip this section and proceed to Step 3.
NOTE: Self-signed certificates are appropriate for use on a trusted network, such as a LAN that includes both
a ScienceLogic Data Collector and the Windows Server to be monitored.
1. Log in to the Windows Server that you want to monitor with SL1.
2. In the Start menu search bar, enter "mmc" to open a Microsoft Management Console window.
l For details on creating a self-signed certificate with MakeCert and installing the certificate in the Trusted Root
Certification Authorities store, see:
https://msdn.microsoft.com/en-us/library/ms733813%28v=vs.110%29.aspx
l You can use the New-SelfSignCertificate command to create a self-signed certificate. For information on
New-SelfSignCertificate, see:
https://docs.microsoft.com/en-us/powershell/module/pkiclient/new-
selfsignedcertificate?view=win10-ps
l You can use the Export-PfxCertificate command to export the private certificate. For information on the
Export-PfxCertificate, see:
NOTE: This step is required regardless of the user account type that SL1 will use to connect to the Windows
Server.
1. Log in to the ScienceLogic portal, go to Downloads > Miscellaneous, and download the PowerShell script
named WinRM Configuration Wizard Script (winrm_configuration_wizard.ps1). The link is :
https://portal-cdn.sciencelogic.com/powerpackextras/5819/18486/winrm_configuration_wizard.zip
2. Unzip the downloaded file.
3. Using the credentials for an account that is a member of the Administrator's group, log in to the Windows
server you want to monitor. You can log in directly or use Remote Desktop to log in.
4. Copy the PowerShell script named winrm_configuration_wizard.ps1 to the Windows server that you want
to monitor with SL1.
5. Right-click on the PowerShell icon and select Run As Administrator.
6. At the PowerShell prompt, navigate to the directory where you copied the PowerShell script named winrm_
configuration_wizard.ps1.
7. At the PowerShell prompt, enter the following to enable execution of the script:
NOTE: If your Windows configuration requires further steps to allow execution of the script, PowerShell will
display prompts. Follow the prompts.
9. To run the script with interactive dialogs, enter the following at the PowerShell prompt:
The user account you wish to use for SL1 collection must be specified with the -user command-line
argument regardless of other arguments used. You can obtain the full help for the PowerShell configuration
script by entering the following:
10. If you start the script without using the -silent command-line argument, the WinRM Installation Wizard
modal page appears. Click [OK].
12. The Set Encryption Policy modal page appears. Select the appropriate choice for your environment.
l Click YES to us only encrypted data. Click Yes to configure an HTTPS listener for using encrypted
communications between the SL1 collectors and the Windows server. Setting up an HTTPS listener requires
a digital certificate with Server Authentication EKU to be available on the server. For information on creating
a self-signed certificate, see Configuring a Server Authentication Certificate.
l Click NO to allow unencrypted data. For communication between SL1 collectors and the Windows
server, if unencrypted traffic is allowed, an HTTP listener will be configured for communication.
14. The Set Ports for WinRM Traffic modal page appears, and it shows the current settings for the HTTP and
HTTPS ports. If you want to make a change to these, click [YES]; otherwise, click [NO] to continue.
16. The Set HTTPS Thumbprint modal page appears. Enter the information for your certificate thumbprint,
which is used to create an HTTPS listener, then click [OK].
NOTE: If the certificate structure for your certificate thumbprint is incomplete or incorrect, an error message
appears indicating that the WinRM client cannot process the request. If you think you made an error,
click [OK] and try to correct it. Otherwise, contact a system administrator for help.
18. The Complete modal page appears. If the settings are correct, click [OK].
The output should look like this (additional lines indicated by ellipsis):
Config
...
Client
...
Auth
Basic = true
...
Kerberos = true
...
...
Service
...
AllowUnencrypted = false
...
DefaultPorts
HTTP = 5985
HTTPS = 5986
...
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
...
11. In the Service section, if the parameter AllowRemoteAccess is set to false, execute the following command:
12. In the Winrs section, if the parameter AllowRemoteShellAccess is set to false, execute the following
command:
Set-Item WSMan:\Localhost\Winrs\AllowRemoteShellAccess -value true
13. If you are configuring this Windows server for unencrypted communication and the parameter
AllowUnencrypted (in the Service section) is set to false, execute the following command:
Set-Item WSMan:\Localhost\Service\AllowUnencrypted -value true
14. If you are configuring this Windows server for unencrypted communication, verify that "HTTP = 5985"
appears in the DefaultPorts section.
NOTE: ScienceLogic recommends using encrypted communication, particularly if you are also using
an Active Directory account. Using an Active Directory account for encrypted authentication
enables you to use Kerberos ticketing for authentication.
15. If you are configuring this Windows server for encrypted communication, verify that "HTTPS = 5986" appears
in the DefaultPorts section.
16. If you are using an Active Directory account to communicate with this Windows server and in the Auth section,
the parameter Kerberos is set to false, execute the following command:
Set-Item WSMan:\Localhost\Service\Auth\Kerberos -value true
17. If you are using a local account to communicate with this Windows server and in the Auth section, the
parameter Basic is set to false, execute the following command:
Set-Item WSMan:\Localhost\Service\Auth\Basic -value true
TIP: You will import this certificate into the new group policy in step 21.
8. On the Group Policy Management page, in the left panel, right-click the domain name where you want
the new group policy to resideand then select Create a GPO in this domain and Link it here.
10. In the left panel, navigate to Computer Configuration > Policies > Windows Settings > Security
Settings > System Services. In the right panel, locate the Windows Remote Management (WS-
Management) service. Right-click the service, then select Properties.
12. In the left panel of the Group Policy Management Editor page, navigate to Computer Configuration
> Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security >
Windows Firewall with Advanced Security - LDAP > Inbound Rules. In the right panel, right-click and
select New Rule.
14. Select the Windows Firewall Remote Management (RPC) and Windows Firewall Remote Management (RPC-
EPMAP) check boxes, then click [Next].
16. In the left panel of the Group Policy Management Editor page, navigate to Computer Configuration
> Policies > Windows Settings > Security Settings > Public Key Policies > Automatic Certificate
Request Settings. In the right panel, right-click and select New > Automatic Certificate Request.
18. Select the Computer certificate template. Click [Next], and then click [Finish].
20. The Certificate Import Wizard modal page appears. Click [Next].
22. Select the Place all certificates in the following store radio button, then select the Trusted Root
Certification Authorities certificate store and click [Next].
24. In the left panel of the Group Policy Management Editor page, navigate to Computer Configuration
> Policies > Administrative Templates > Network > Network Connections > Windows Firewall
> Domain Profile. In the right panel, right-click Windows Firewall: Define inbound port exceptions and
select Edit.
25. The Windows Firewall: Define inbound port exceptions modal page appears. Under Options, click
[Show].
l 5985:TCP:*:enabled:WSMan
l 5986:TCP:*:enabled:WSMan
32. In the left panel of the Group Policy Management Editor page, navigate to Computer Configuration
> Policies > Administrative Templates > Windows Components > Windows Remote Management
(WinRM) > WinRM Service. In the right panel, double-click the Allow Basic authentication setting.
36. In the left panel of the Group Policy Management Editor page, navigate to Computer Configuration
> Preferences > Windows Settings > Registry. In the right panel, right-click and select New > Registry
Item.
41. In the New Service Properties modal page, edit the values in one or more of the following fields:
42. Click the [Recovery] tab, then edit the values in one or more of the following fields:
45. To enable your group policy, in the left panel of the Group Policy Management Editor page, navigate to
Forest > Domains > [your local domain] > Group Policy Objects > WinRM Policy. Right-click
WinRM Policy, then select GPO Status > Enabled.
To configure the target and proxy servers, perform the following steps:
1. Configure a user account that SL1 will use to connect to the proxy server and the proxy server will use to
connect to the target server. The user account can either be a local account or an Active Directory account;
however, the user account must have the same credentials on the target and proxy servers and be in the
Local Administrator's group on both servers.
2. If you have created a local user account on the Windows Server instead of an Active Directory account, you
must configure encrypted communication between SL1 and the Windows server. To do this, you must
configure a Server Authentication certificate.
3. Configure Windows Remote Management on the target server and the proxy server.
4. Log in to the proxy server as an administrator.
5. Open the PowerShell command window.
6. Right-click on the PowerShell icon in the taskbar and select Run as Administrator.
7. Execute one of the following commands on the proxy server to allow the proxy server to trust one or more
target servers:
l To allow the proxy server to trust all servers (not recommended), execute the following command:
Set-Item WSMan:\Localhost\Client\TrustedHosts -value *
l To allow the proxy server to trust only specific target servers, execute the following command, inserting
a list that includes the IP address for each target server. Separate the list of IP addresses with commas.
Set-Item WSMan:\Localhost\Client\TrustedHosts -value <comma-delimited-list-
of-target-server-IPs>
8. Execute the following command on the proxy server to configure the LocalAccountTokenFilterPolicy:
New-ItemProperty
“HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System” -Name
“LocalAccountTokenFilterPolicy” -Value 1 -PropertyType “DWORD"
l On the domain controller for each domain (domain A and domain B), create new forward-lookup
zones and reverse-lookup zones that allow name resolution to work between the two domains.
l On the domain controller for each domain (domain A and domain B), create a non-transitive realm
trust between the two domains.
l Login to the proxy server and add the Active Directory account (from domain A) to the Local
Administrator's group for the proxy server. You should be able to select the account on the proxy server
after you create the non-transitive realm trust between the two domains.
To do so:
1. Determine the number of Dynamic Applications that will be used to monitor the Windows server. Multiply this
number by three.
2. Open a PowerShell command prompt. Log in as an Administrator.
3. At the prompt, execute the following commands:
Restart-Service WinRM
4. Repeat these steps on each Windows server that will be monitored by SL1.
Step 5: Increasing the Number of PowerShell Dynamic Applications That Can Run 69
Chapter
4
SNMP and PowerShell Dynamic Applications
for Windows Devices
Overview
The following sections describe the SNMP and PowerShell Dynamic Applications that SL1 uses to monitor
Windows devices:
70
Error Messages for PowerShell Collection 81
Relationships with Other Types of Component Devices 82
In addition to the common SNMP data collection, you can install an optional agent that reports WMI information
through SNMP. The following SNMP Dynamic Applications can be used to collect the information reported by the
optional agent:
l MSSQL: General
l MSSQL: Memory
l MSSQL: SQL Stats
All of the PowerShell Dynamic Applications include a discovery object. If you include a credential for PowerShell
Dynamic Applications in the discovery session that includes your Windows system, SL1 will automatically align the
appropriate PowerShell Dynamic Applications to the Windows system. For more information about creating a
discovery session, see the Discovery & Credentials manual.
The following PowerPacks include PowerShell Dynamic Applications for Microsoft Servers.
NOTE: The Dynamic Applications in this PowerPack support Windows Server 2012 R2.
The following PowerShell Dynamic Applications can be used to collect performance data from Active Directory
servers:
NOTE: The Dynamic Applications in this PowerPack support Windows Server 2012.
The following PowerShell Dynamic Applications can be used to collect performance data from DHCP servers:
The following PowerShell Dynamic Applications can be used to collect configuration data from DHCP servers:
NOTE: The Dynamic Applications in this PowerPack support Windows Server 2008 R2, 2012, and 2012
R2.
The following PowerShell Dynamic Applications can be used to collect performance data from DNS servers:
NOTE: The Dynamic Applications in this PowerPack support Hyper-V Server 2008 R2, 2012, and 2012 R2.
The following PowerShell Dynamic Applications can be used to collect performance data from Hyper-V servers:
The following PowerShell Dynamic Applications can be used to collect configuration data from Hyper-V servers:
This PowerPack also includes Snippet Dynamic Applications that discover virtual machines managed by the Hyper-
V host. Although the Dynamic Applications are of type "Snippet", the snippets themselves perform PowerShell
requests to collect data and use PowerShell credentials. See the Discovering Component Devices on Hyper-V
Systems section for more information.
This PowerPack also includes Snippet Dynamic Applications that retrieve performance data from virtual machines
managed by the Hyper-V host. Although the Dynamic Applications are of type "Snippet", the snippets themselves
perform PowerShell requests to collect data and use PowerShell credentials:
NOTE: The Dynamic Applications in this PowerPack support Internet Information Services (ISS) versions 7.5,
8.0, 8.5, and 10.0.
The following PowerShell Dynamic Applications can be used to collect performance data from IIS servers:
The following PowerShell Dynamic Applications can be used to collect configuration data from IIS servers:
The following PowerShell Dynamic Applications can be used to collect configuration data from Lync 2010 servers:
NOTE: The Dynamic Applications in this PowerPack support SharePoint Server 2010 SE.
The following PowerShell Dynamic Applications can be used to collect performance data from SharePoint servers:
NOTE: This PowerPack was previously named Microsoft: Lync Server 2013.
The following PowerShell Dynamic Applications can be used to collect performance data from Lync 2013 servers:
The following PowerShell Dynamic Applications can be used to collect configuration data from Lync 2013 servers:
NOTE: The Dynamic Applications in this PowerPack support SQL Server 2008, 2012, 2014, and 2016.
The following PowerShell Dynamic Applications can be used to collect performance data from SQL servers:
NOTE: The Dynamic Applications in this PowerPack support Windows Server 2008 R2, 2012, 2012 R2,
and 2016, as well as Windows 10.
The following PowerShell Dynamic Applications can be used to collect configuration data from Windows servers:
NOTE: The "Microsoft: Windows Server Configuration Cache" Dynamic Application caches data that is
consumed by all of the other configuration Dynamic Applications in the list.
NOTE: When the "Microsoft: Windows Server OS Configuration" or "Microsoft: Windows Server Device
Discovery" Dynamic Applications automatically align to Windows servers, they trigger events and Run
Book Actions that classify the server.
The following PowerShell Dynamic Applications can be used to collect performance data from Windows servers:
The following Snippet Dynamic Application, which uses PowerShell requests to collect data, can be used to collect
journal data from Windows servers:
The following Dynamic Applications use PowerShell to collect data as a supplement to SL1's internal collection
capabilities:
To customize how the Microsoft: Windows Server Event Logs Dynamic Applications filter event logs, perform the
following steps for each Dynamic Application:
1. Go to the Dynamic Applications Manager page (System > Manage > Applications) and search for the
Dynamic Application you want to customize in the Dynamic Application Name column.
2. Click the wrench icon ( ) for the Dynamic Application you want to edit.
3. In the [Snippets] tab, click the wrench icon ( ) next to the item in the Snippet Registry pane.
4. In the Snippet Editor, you can edit the following fields:
NOTE: The Dynamic Applications in this PowerPack support Windows Server 2008 R2, 2012, and 2012
R2.
The following PowerShell Dynamic Applications can be used to collect configuration data from a Windows server
about each Windows Service running on the Windows server:
l Microsoft: Windows Server Device Class Alignment (Run Book Automation Policy)
l Microsoft: Windows Server Device Class Alignment (Run Book Action Policy)
The automation policy is configured to trigger when the "Microsoft: Windows Server OS Configuration" or
"Microsoft: Windows Server Device Discovery" Dynamic Applications are aligned with a device during discovery.
These Dynamic Applications collect the name of the Windows operating system and store the name in a collection
object named "Edition". The Run Book Automation policy and Run Book Action policy use the value of the
collection object named "Edition" to assign a device class to each Windows device that does not support SNMP.
For example, if the collection object named "Edition" contains the value "Microsoft Windows Server 2012 R2
Datacenter", the Run Book Automation policy and the Run Book Action policy will assign the device to the device
class "Microsoft Windows Server 2012 R2".
Preauthentication failed while getting initial Incorrect Password (Active Directory Accounts only)
credentials
Client not found in Kerberos database Username does not exist in Active Directory (Active
Directory Accounts only)
KRB5 error code 68 while getting initial credentials Incorrect domain name (Active Directory Accounts
only)
Bad HTTP response returned from server. Code 401, Incorrect username/password or target server does
basic auth failed not allow user account to perform WinRM operations.
Hostname cannot be canonicalized Forward and/or reverse name resolution are not
working from the Data Collector or All-In-One
Appliance
Cannot resolve network address for KDC in requested Forward and/or reverse name resolution are not
realm working from the Data Collector or All-In-One
Appliance
Configuration file does not specify default realm Forward and/or reverse name resolution are not
working from the Data Collector or All-In-One
Appliance
No credentials cache found Forward and/or reverse name resolution are not
working from the Data Collector or All-In-One
Appliance
Server not found in Kerbers database Forward and/or reverse name resolution are not
working from the Data Collector or All-In-One
Appliance
l If you discover Dynatrace devices using the Dynamic Applications in the Dynatrace PowerPack, SL1 will
automatically create relationships between Windows servers and Dynatrace hosts.
l If you discover Cisco AppDynamics devices using the Dynamic Applications in the Cisco:
AppDynamics PowerPack, SL1 will automatically create relationships between Windows servers and
AppDynamics nodes.
l If you discover New Relic devices using the Dynamic Applications in the New Relic APM Pro PowerPack, SL1
will automatically create relationships between Windows servers and New Relic servers.
5
Creating SNMP and PowerShell Credentials
for Windows Devices
Overview
The following sections describe how to create SNMP and PowerShell credentials for Windows devices that you
want to monitor with SL1, as well as how to discover component devices on Hyper-V systems:
2. Click the [Actions] button and select Create SNMP Credential. The Credential Editor page appears.
These fields appear if you selected SNMP V1 or SNMP V2 in the SNMP Version field. The fields are
inactive if you selected SNMP V3.
l SNMP Community (Read-Only). The SNMP community string (password) required for read-only
access of SNMP data on the remote device or application. For SNMP V1 and SNMP V2 credentials,
you must supply a community string, either in this field or in the SNMP Community (Read/Write)
field.
l SNMP Community (Read/Write). The SNMP community string (password) required for read and
write access of SNMP data on the remote device or application. For SNMP V1 and SNMP V2
credentials, you must supply a community string, either in this field or in the SNMP Community (Read
Only) field.
SNMP V3 Settings
These fields appear if you selected SNMP V3 in the SNMP Version field. These fields are inactive if you
selected SNMP V1 or SNMP V2.
o No Authentication / No Encryption.
o Authentication Only. This is the default value.
o Authentication and Encryption.
l SNMP v3 Engine ID. The unique engine ID for the SNMP agent you want to communicate with.
(SNMPv3 authentication and encryption keys are generated based on the associated passwords and
the engine ID.) This field is optional.
l Context Name. A context is a mechanism within SNMPv3 (and AgentX) that allows you to use
parallel versions of the same MIB objects. For example, one version of a MIB might be associated with
SNMP Version 2 and another version of the same MIB might be associated with SNMP Version 3. For
SNMP Version 3, specify the context name in this field. This field is optional.
l Privacy Protocol Passphrase. Privacy password for the credential. This field is optional.
NOTE: When you define an SNMP Credential, SL1 automatically aligns the credential with all organizations
of which you are a member.
All of the PowerShell Dynamic Applications include a discovery object. If you include a credential for PowerShell
Dynamic Applications in the discovery session that includes your Windows system, SL1 will automatically align the
appropriate PowerShell Dynamic Applications to the Windows system. For more information about creating a
discovery session, see the Discovery & Credentials manual.
4. The Credential Editor page appears, where you can define the following fields:
l Profile Name. Name of the credential. Can be any combination of alphanumeric characters.
o You can include the variable %D in this field. SL1 will replace the variable with the IP address of the
device that is currently using the credential.
o You can include the variable %N in this field. SL1 will replace the variable with the hostname of the
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.
o You can include the prefix HOST or WSMAN before the variable %D in this field if the device you
want to monitor uses a service principal name (for example, "HOST://%D" or "WSMAN://%D").
SL1 will use the WinRM service HOST or WSMan instead of HTTP and replace the variable with
the IP address of the device that is currently using the credential.
l Username. Type the username for an account on the Windows device to be monitored or on the
proxy server.
NOTE: The user should not include the domain name prefix in the username for Active Directory accounts.
For example, use "em7admin" instead of "MSDOMAIN\em7admin".
l Encrypted. Select whether SL1 will communicate with the device using an encrypted connection.
Choices are:
o yes. When communicating with the Windows server, SL1 will use a local user account with
authentication of type "Basic Auth". You must then use HTTPS and can use a Microsoft Certificate or
a self-signed certificate.
o no. When communicating with the Windows server, SL1 will not encrypt the connection.
l Port. Type the port number used by the WinRM service on the Windows device. This field is
automatically populated with the default port based on the value you selected in the Encrypted field.
l Account Type. Type of authentication for the username and password in this credential. Choices are:
o Active Directory. On the Windows device, Active Directory will authenticate the username and
password in this credential.
o Local. Local security on the Windows device will authenticate the username and password in this
credential.
l Timeout (ms). Type the time, in milliseconds, after which SL1 will stop trying to collect data from the
authenticating server. For collection to be successful, SL1 must connect to the authenticating server,
execute the PowerShell command, and receive a response within the amount of time specified in this
field.
l Password. Type the password for the account on the Windows device to be monitored or on the proxy
server.
l PowerShell Proxy Hostname/IP. If you use a proxy server in front of the Windows devices you want to
communicate with, type the fully-qualified domain name or the IP address of the proxy server in this
field.
5. To save the credential, click the [Save] button. To clear the values you set, click the [Reset] button.
l Test Reachability. Performs an ICMP ping request to the host specified in the credential.
l Test Port Availability. Performs an NMAP request to the UDP port specified in the credential on the host
specified in the credential.
l Test SNMP Availability. Attempts an SNMP getnext request to .1.3.6.1 using the credential.
l Test Reachability. Performs an ICMP ping request to the host specified in the credential.
l Test Port Availability. Performs an NMAP request to the TCP port specified in the credential on the host
specified in the credential.
l Test Name Resolution. Performs an nslookup request on the host specified in the credential.
l Test Kerberos. If the credential does not specify local authentication, attempts to acquire a kerberos ticket
using the credential.
l Test WinRM Connection. Attempts a WinRM connection using the credential.
l Execute PowerShell Cmdlet. Attempts to execute the 'Get-WmiObject Win32_Process | Select Name'
PowerShell Cmdlet using the credential.
4. Click the [Run Test] button to run the credential test. The Test Credential window appears:
The Test Credential window displays a log entry for each step in the credential test. The steps performed
are different for each credential test. The log entry for each step includes the following information:
l Step Tip. Mouse over the question mark icon ( ) to display the tip text. The tip text recommends
what to do to change the credential and/or the network environment if the step has a status of "Failed".
5. Optionally, you can click the [Execute Discovery Session] button to run a discovery session using the
Credential, Hostname/IP, and Collector you selected in the Credential Tester modal page.
To discover the virtual machines on a Hyper-V system as component devices, align the following two Dynamic
Applications with a Hyper-V system:
When these Dynamic Applications are aligned to a Hyper-V system, the platform will automatically create a device
record for each virtual machine. The platform will also automatically align other Dynamic Applications from the
Microsoft: Hyper-V Server PowerPack to each virtual machine.
In addition to the Device Manager page, you can view the Hyper-V system and all associated component devices
in the following places in the user interface:
l The Device Components page (Registry > Devices > Device Components) displays a list of all root devices
and component devices discovered by the platform. The Device Components page displays all root devices
and component devices in an indented view, so you can easily view the hierarchy and relationships between
child devices, parent devices, and root devices. To view the component devices associated with a Hyper-V
system, find the Hyper-V system and select its plus icon (+):
1. Find your Windows device in the Device Manager page (Registry > Devices > Device Manager and click
its wrench icon ( ).
2. From the Device Properties page for the Windows system, click the [Collections] tab. The Dynamic
Application Collections page appears.
3. Click the [Action] button and then select Add Dynamic Application. The Dynamic Application Alignment
page appears:
6
Executing the SL1 Agent with Windows
PowerShell
Overview
The following sections provide an overview of local Agent execution on Windows devices with PowerShell:
Because an agent is always running on a device, the SL1 Agent can collect more granular data than can be
collected by polling the device periodically with a Data Collector. You can collect data from devices using only the
SL1 Agent or using a combination of the SL1 Agent and Data Collectors.
For more information, see the Monitoring with the SL1 Agent manual .
95 Agent-Compatible PowerPacks
Configuring the SL1 Agent Device Template
A device template allows you to save a device configuration and apply it to multiple devices. Windows
PowerPacks include a device template for executing the SL1 Agent with PowerShell. If you apply this device
template during discovery, SL1 aligns the appropriate Dynamic Applications to the discovered PowerShell device.
This device template does not need to be edited and will work as-is, unless you would like to remove a Dynamic
Application from the template. To remove any Dynamic Applications you may not need:
5. To remove a Dynamic Application listed in the Subtemplate Selection section on the left side of the page,
click it's bomb icon ( ) and then click [OK] when asked to confirm. select the SL1 Agent PowerShell
credential in the Credentials field.
6. Click [Save].
7
Windows Dashboards
Overview
The following sections describe how to install the dashboards included in SL1 for Microsoft servers and a
description of each:
To view these dashboards in SL1, you must first install the corresponding PowerPack. To do so:
4. Click the lightning-bolt icon ( ) for the PowerPack that you want to install.
6. The PowerPack now appears in the PowerPack Manager page. The contents of the PowerPack are
automatically installed in your SL1 System.
Context Quick Selector. This widget contains buttons for time span preset and the Organizations Selector.
Server List. This widget displays a list of Active Directory servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected Active Directory server during the selected duration. Each parameter is
represented by a color-coded line.
Replication. Replication is the process by which the changes that are made on one domain controller are
synchronized with and written to all other domain controllers in the domain or forest. The Replication widget
displays a line graph. The line graph displays information about data that is replicated from the current Active
Directory server to other Active Directory servers (the Outbound Properties Per Second) and information about data
that is replicated from other Active Directory server to the current Active Directory server (Inbound Objects Per
Second).
LDAP - Client Sessions. This widget displays the number of connected LDAP client sessions over time.
LDAP - Active Threads. This widget displays the number of threads in use by the LDAP subsystem of the local
directory service.
Pages Per Second. This widget displays a line graph. The line graph displays DS (domain server) directory reads
per second, DS directory writes per second, and DS directory searches per second. Each parameter is represented
by a color-coded line.
LDAP - Writes and Searches. This widget displays a line graph. The line graph displays LDAP writes per second
and LDAP searches per second. Each parameter is represented by a color-coded line.
l The y axis displays writers per second and searches per second.
l The x axis displays time. The increments vary, depending upon the date range selected in the Context Quick
Selector widget.
l Mousing over any point in any line displays the average value at that time-point.
l Clicking on a data point displays the Device Performance graph for the selected parameter on the selected
Active Directory server.
LDAP - Bind Time. This widget displays a line graph. The line graph displays the time required for completion of
each successful LDAP binding.
Context Quick Selector. This widget contains buttons for time span presets and the Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of DNS servers that appear in the Server List widget.
Server List. This widget displays a list of DNS servers. Selecting a server drives the context for the other widgets in
the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected DNS server during the selected duration. Each parameter is represented
by a color-coded line.
Overall Performance. This widget displays a line graph. The line graph displays Total Responses Sent per Second
and Total Queries Received per Second. Each parameter is represented by a color-coded line.
l The y axis displays responses per second and queries per second.
l The x axis displays time. The increments vary, depending upon the date range selected in the Context Quick
Selector widget.
l Mousing over any point in any line displays the average value at that time-point.
l Clicking on a data point displays the Device Performance graph for the selected parameter on the selected
DNS server.
Recursive Queries. This widget displays a line graph. The line graph displays Recursive Queries per Second.
Recursive Errors. This widget displays a line graph. The line graph displays Recursive Query Failures per Second
and Recursive Time-Outs per Second. Each parameter is represented by a color-coded line..
Context Quick Selector. This widget contains buttons for time span presets and the Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Exchange 2010 servers that appear in the Server List widget.
Server List. This widget displays a list of Exchange 2010 servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, swap memory
usage, and CPU usage for the selected Exchange 2010 server during the selected duration. Each parameter is
represented by a color-coded line.
User Active Connections. This widget displays a line graph. The line graph displays the number of active user
connections for the selected Exchange 2010 server during the selected duration.
OWA Requests. This widget displays a line graph. The line graph displays two lines: One for the frequency of
Outlook Web Access requests for the selected Exchange 2010 server during the selected duration and another for
the frequency of Web Services requests for the selected Exchange 2010 server during the selected duration.
RPC Averaged Latency. This widget displays a line graph. The line graph displays the average latency of remote
procedure calls (RPCs) for the selected Exchange 2010 server during the selected duration.
MBS Databases. This widget displays a line graph. The line graph displays two lines: One for I/O write latency for
the mailbox server database for the selected Exchange 2010 and one for I/O read latency to the mailbox server
for the selected Exchange 2010 server during the selected duration.
l The y axis displays the write and read latency statistics in milliseconds.
l The x axis displays time. The increments vary, depending upon the date range selected in the Context Quick
Selector widget.
l Mousing over any point in any line displays the average value at that time-point.
l Clicking on a data point displays the Device Performance graph for the selected parameter on the selected
Exchange 2010 server.
Total Queue Messages. This widget displays a line graph. The line graph includes three lines: One for the
number of messages in the submission queue, one for the number of messages in the delivery queue, and one for
the number of queued message that were delivered for the selected Exchange 2010 server during the selected
duration.
SMTP Messages. This widget displays a line graph. The line graphs includes two lines: One for the number of
SMTP messages sent from the selected Exchange 2010 server and one for the number of SMTP messages
received by the selected Exchange 2010 server during the selected duration.
Buckets Allocated. This widget displays a line graph. The line graph displays the number of buckets of version
store memory used by the selected Exchange 2010 server during the selected duration.
Context Quick Selector. This widget contains buttons for time span presets and the Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Exchange 2013 servers that appear in the Server Listwidget.
Server List. This widget displays a list of Exchange 2013 servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays three lines: One for memory
usage, one for swap memory usage, and one for CPU usage for the selected Exchange 2013 server during the
selected duration. Each parameter is represented by a color-coded line.
User Active Connections. This widget displays a line graph. The line graph displays the number of active user
connections for the selected Exchange 2013 server during the selected duration.
OWA Requests. This widget displays a line graph. The line graph displays two lines: One for the frequency of
Outlook Web Access requests and one for the frequency of Web Services requests for the selected Exchange
2013 server during the selected duration.
RPC Averaged Latency. This widget displays a line graph. The line graph displays the average latency for remote
procedure calls (RPCs) for the selected Exchange 2013 server during the selected duration.
MBS Databases. This widget displays a line graph. The line graph displays two lines: One for I/O write latency to
the mailbox server database and one for I/O read latency to the mailbox server database for the selected
Exchange 2013 server during the selected duration.
l The y axis displays the average write and read latency in milliseconds.
l The x axis displays time. The increments vary, depending upon the date range selected in the Context Quick
Selector widget.
l Mousing over any point in any line displays the average value at that time-point.
l Clicking on a data point displays the Device Performance graph for the selected parameter on the selected
Exchange 2013 server.
Total Queue Messages. This widget displays a line graph. The line graph displays three lines: One for the the
number of messages in the submission queue, one for the number of messages in the delivery queue, and one for
the number of queued message that were delivered for the selected Exchange 2013 server during the selected
duration.
SMTP Messages. This widget displays a line graph. The line graph displays two lines: One for the number of
SMTP messages sent from the selected Exchange 2013 server and one for the number of SMTP messages
received by the selected Exchange 2013 server during the selected duration.
Buckets Allocated. This widget displays a line graph. The line graph displays the number of buckets of version
store memory used by the selected Exchange 2013 server during the selected duration.
Context Quick Selector. This widget contains buttons for time span presets and the Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of IIS servers that appear in the Server List widget.
Server List. This widget displays a list of IIS servers. Selecting a server drives the context for the other widgets in the
dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected IIS server during the selected duration. Each parameter is represented by a
color-coded line.
Current Users. This widget displays a line graph. The line graph displays Current Anonymous Users and Current
Non Anonymous Users. Each parameter is represented by a color-coded line.
Bytes Sent and Received. This widget displays a line graph. The line graph displays Bytes Sent Per Second and
Bytes Received Per Second. Each parameter is represented by a color-coded line.
Connections. This widget displays a line graph. The line graph displays the number of Active HTTP Connections.
Pages Per Second. This widget displays a line graph. The line graph displays the number of Pages (served) Per
Second.
Cache Hit %. The IIS server caches (in memory) frequently requested files. This widget displays a line graph. The
line graph displays the ratio of kernel URI cache hits to total cache requests.
404 Errors Per Second. This widget displays a line graph. The line graph displays the number of errors due to
requests that couldn't be satisfied by the server because the requested document couldn't be found, per second.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Lync 2010 servers that appear in the Server List widget.
Server List. This widget displays a list of Lync 2010 servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected Lync 2010 server during the selected duration. Each parameter is
represented by a color-coded line.
Connections Established. This widget displays a line graph. The line graph displays Connections Established.
SIP Message. SIP is a protocol for instant messaging and VOIP. This widget displays a line graph. The line graph
displays Incoming Message and Outgoing Messages. Each parameter is represented by a color-coded line.
SIP Network Errors. This widget displays information about errors during instant messaging or VOIP. This widget
displays a line graph. The line graph displays Connections Above Per-User Limit Dropped, Connections Refused
Due to Server Overload, Failed DNS SRV Queries, Time Out DNS SRV Queries, and TLS Negotiations Failed.
Each parameter is represented by a color-coded line.
Incoming Response Breakdown. This widget displays information about the number of responses generated by
the server. This widget displays a line graph. The line graph displays Incoming 2xx Responses. A 2xx Response
means that a connection has been established.
Incoming Response Breakdown. This widget displays information about the number of responses generated by
the server. This widget displays a line graph. The line graph displays Incoming 1xx (non-100) Responses,
Incoming 3xx Responses, Incoming Other 4xx Responses, Incoming Other 5xx Responses, and Incoming 6xx
Responses. Each parameter is represented by a color-coded line. For a description of SIP response codes, see the
Wikipedia page http://en.wikipedia.org/wiki/List_of_SIP_response_codes.
Incoming Response Breakdown. This widget displays information about the number of responses generated by
the server. This widget displays a line graph. The line graph displays Incoming 482 Responses and Incoming 483
Responses. Each parameter is represented by a color-coded line. For a description of SIP response codes, see the
Wikipedia page http://en.wikipedia.org/wiki/List_of_SIP_response_codes.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Lync 2010 servers that appear in the Server List widget.
Server List. This widget displays a list of Lync 2010 servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected Lync 2010 server during the selected duration. Each parameter is
represented by a color-coded line.
Active Registered Endpoints. Endpoints are devices that are connected to the Lync front-end server. This widget
displays a line graph. The line graph displays Endpoint Cache: Active Registered Endpoints.
Connected IM Users. This widget displays the current number of connected IM users. This widget displays a line
graph. The line graph displays Connected Users.
Number of Calls. This widget displays the current number of voice calls on the Lync server. This widget displays a
line graph. The line graph displays UpdateEndpoint: Number of Calls.
Active AS Conferences. This widget displays the number of active conferences using Application Sharing (AS).
This widget displays a line graph. The line graph displays Active Conferences.
Context Quick Selector. This widget contains the time span preset buttons and Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Lync 2013 servers that appear in the Server List widget.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected Lync 2013 server during the selected duration. Each parameter is
represented by a color-coded line.
Connections Established. This widget displays a line graph. The line graph displays Connections Established.
SIP Message. SIP is a protocol for instant messaging and VOIP. This widget displays a line graph. The line graph
displays Incoming Message and Outgoing Messages. Each parameter is represented by a color-coded line.
Sproc Latency. Stored Procedure Call (sproc) latency is the time it takes for the Lync database to process the
stored procedure call.
SIP Network Errors. This widget displays information about errors during instant messaging or VOIP. This widget
displays a line graph. The line graph displays Connections Above Per-User Limit Dropped, Connections Refused
Due to Server Overload, Failed DNS SRV Queries, Time Out DNS SRV Queries, and TLS Negotiations Failed.
Each parameter is represented by a color-coded line.
Incoming Response Breakdown. This widget displays information about the number of responses that are being
generated by the server. This widget displays a line graph. The line graph displays Incoming 2xx Responses. A 2xx
Response means that a connection has been established.
Incoming Respond Breakdown. This widget displays information about the number of responses that are being
generated by the server. This widget displays a line graph. The line graph displays Incoming 1xx (non-100)
Responses, Incoming 3xx Responses, Incoming Other 4xx Responses, Incoming Other 5xx Responses, and
Incoming 6xx Responses. Each parameter is represented by a color-coded line. For a description of all SIP
response codes, see the Wikipedia page http://en.wikipedia.org/wiki/List_of_SIP_response_codes.
Incoming Response Breakdown. This widget displays information about the number of responses that are being
generated by the server. This widget displays a line graph. The line graph displays Incoming 482 Responses and
Incoming 483 Responses. Each parameter is represented by a color-coded line. For a description of all SIP
responses codes, see the Wikipedia page http://en.wikipedia.org/wiki/List_of_SIP_response_codes.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of Lync 2013 servers that appear in the Server List widget.
Server List. This widget displays a list of Lync 2013 servers. Selecting a server drives the context for the other
widgets in the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected Lync 2013 server during the selected duration. Each parameter is
represented by a color-coded line.
Active Registered Endpoints. Endpoints are devices that are connected to the Lync front-end server. This widget
displays a line graph. The line graph displays Endpoint Cache: Active Registered Endpoints.
Connected IM Users. This widget displays the current number of connected IM users. This widget displays a line
graph. The line graph displays Connected Users.
Number of Calls. This widget displays the current number of voice calls on the Lync server. This widget displays a
line graph. The line graph displays UpdateEndpoint: Number of Calls.
Active AS Conferences. This widget displays the number of active conferences using Application Sharing (AS).
This widget displays a line graph. The line graph displays Active Conferences.
Context Quick Selector. This widget contains buttons for the time span presets and the Organizations Selector.
l Time span presets. Users select the time span over which they want to view data. Selections range from one
hour to 90 days.
l Organizations Selector. This drop-down list allows a user to select specific organizations for which they want
to view data. This field filters the list of SQL servers that appear in the Server List widget.
Server List. This widget displays a list of SQL servers. Selecting a server drives the context for the other widgets in
the dashboard.
System Utilization (%). This widget displays a line graph. The line graph displays memory usage, virtual-memory
usage, and CPU usage for the selected SQL server during the selected duration. Each parameter is represented
by a color-coded line.
Buffer Cache Hit Ratio. This widget displays information about the percentage of page requests that are satisfied
by data pages from the buffer cache without having to read from disk. The ratio is the total number of pages found
in the buffer divided by the total number of requests. This widget displays a line graph. The line graph displays
Buffer Cache Hit Ratio.
Average Wait Time. This widget displays information about the average wait time to acquire a lock. This widget
displays a line graph. The line graph displays Average Wait Time.
Lock Waits. This widget displays information about the number of lock requests per second that require the
requester to wait. This widget displays a line graph. The line graph displays Lock Waits Per Second.
Catalog Cache Hit Ratio. This widget displays information about the ratio between catalog metadata cache hits
and lookups. The ratio is the total number of pages found in the catalog metadata cache divided by the total
number of lookups. This widget displays a line graph. The line graph displays Catalog Cache Hit Ratio.
Page Life Expectancy. This widget displays information about the number of seconds a page will stay in the buffer
pool (memory cache) without references. This widget displays a line graph. The line graph displays Page Life
Expectancy.
l The y axis displays the number of seconds a page will stay in the buffer pool.
l The x axis displays time. The increments vary, depending upon the date range selected in the Context Quick
Selector widget.
l Mousing over any point in any line displays the average value at that time-point.
l Clicking on a data point displays the Device Performance graph for the selected parameter on the selected
SQL server.
Latch Waits. A latch is an object that ensures data integrity for objects in the buffer pool (memory cache). This
widget displays a line graph. The line graph displays Latch Waits Per Second.
8
Troubleshooting
Overview
The following sections describe some of the error messages that you might see when configuring SL1 to monitor
Windows devices:
Incorrect username and/or password provided in the Bad HTTP response returned from server. Basic
PowerShell Credential. authentication failed. Code 401. (For more
information, see the section Debugging Code 401
Errors.)
The device cannot respond to WinRM requests or the Kerberos-based authentication failed. Code 500. (For
PowerShell credential settings do not match the more information, see the section Debugging Code
device's WinRM configuration. 500 Errors.)
ParseError.
NOTE: If you receive an error message that is a combination of the first two error messages, then you must
run debugging steps for both Code 401 and Code 500.
o Ensure forward and reverse DNS are configured correctly when using Active Directory authentication:
o Ensure you are able to run the following command without error from the collector:
# kinit [username@DOMAINNAME]
o If you see the following error, change the domain name to all capital letters:
o If your ScienceLogic credential says no encryption, AllowUnencrypted should be set to True for both the
Client and the Service:
o If you are using AD type credentials, Kerberos Authentication should be set to True for both Client and
Service:
l In the ScienceLogic credential, ensure the Active Directory Hostname/IP field contains the FQDN and the
LDAP Domain field includes the domain.
l In the ScienceLogic credential, the value in the LDAP Domain field might need to be entered in all capital
letters.
l Ensure your ScienceLogic credentials are correct:
o SSH to your Data Collector and try running the following command:
NOTE: If you choose to copy and paste the above command from this document into a shell session, you
might have to replace the single and double quotation marks.
l If you are using Windows Servers 2012 and above, make sure that the user you are using belongs to the
group: WinRMRemoteWMIUsers__
l If you are using Windows Server 2008, 2008r2, or below, ensure that the user you are using is an
administrator. This is a Windows requirement.
l If multiple domains are in use, ensure that they are mapped in the [domain_realm] section of the Kerberos
krb5.conf file.
o The [domain_realm] section provides a translation from a domain name or hostname to a Kerberos
realm name.
l Ensure that the username and password are correct and that you can log on to the system.
l Ensure your credential cache is up-to-date:
l In the ScienceLogic credential, increase the value in the Timeout field (e.g., 180000 ms.).
l Ensure that the Windows device being monitored is not exceeding its resource thresholds. You can do this by
opening Resource Monitor on the Windows Device and monitoring the CPU usage.
Get-Counter The PowerShell object was not found on the device that
The specified object was not found on the computer. is being monitored. To test this, copy the PowerShell
request from the Dynamic Application and run it on the
Windows device in a PowerShell shell as Administrator.
If you get a similar error message, then the counter
does not exist on your Windows device. This means that
the user must install the necessary service on the
Windows device.
Other
If any provision of this agreement shall be unlawful, void, or for any reason unenforceable, then that
provision shall be deemed severable from this agreement and shall not affect the validity and enforceability
of any remaining provisions. This is the entire agreement between the parties relating to the matters
contained herein.
In the U.S. and other jurisdictions, trademark owners have a duty to police the use of their marks. Therefore,
if you become aware of any improper use of ScienceLogic Trademarks, including infringement or
counterfeiting by third parties, report them to Science Logic’s legal department immediately. Report as much
detail as possible about the misuse, including the name of the party, contact information, and copies or
photographs of the potential misuse to: [email protected]
800-SCI-LOGIC (1-800-724-5644)
International: +1-703-354-1010