There are many things that can go wrong with a PowerShell script. The purpose of this article is to focus on some of the more frequently seen issues.
Working with PowerShell credentials can be difficult and time consuming. To determine what type of credentials the device is going to use, let’s look at an example script. The script below initiates a remote PowerShell connection, and then executes the script on the remote device.
We can see in the screenshot provided that the WMI username and password are being collected from the remote device. A check is performed to insure that both a username and password is provided. If data is provided for both fields, then they are passed to the else statement and then converted to a remote credential. This new credential will then be used to run the commands that follow.
To use this type of credential you must have PowerShell Remoting configured. Additional information on how to set this up can be found here.
Note: When configuring this for the first time, make certain that the IP address range only includes the collector/s that will be running the script. Otherwise, the PowerShell session will be exposed to the network, which is a considered a security risk. Any device on the network would be able to execute remote commands on this device, so caution is advised.
If the script does not contain references to the properties wmi.user or wmi.pass, then the collector service credentials are used in place to execute the PowerShell commands. The commands will then be run on the specified device. With this type of script, make certain that the host and the collector are on the same domain. The collector user should be a local or domain admin account. Without this some commands may not be processed, or the full error may not be displayed.
If there are no issues with the credentials found, the “Test Script” button within the datasource definition can be run to get data
The script can also be run manually to view how the output is formatted, and to verify the datapoint matches the criteria. Copy the script and use the !posh command to execute it.
If data is returned when running the !posh script, but there is no output visible in the UI, then it is probably an issue with the datapoint definition.
You can use external tools to test your script output as well. For example, regex101.com. Paste the script output into the “Test String” box and then add the regex to the “Expression” field and verify that the returned value is green. This indicates whether or not the regular expression is valid.
Using the same scripts in a non-LM environment
It is a common misconception that making changes to a script, such as adding the hostname token, will allow the script to run successfully inside a datasource.
This is not always true, so sometimes comparing how the collector uses the OS to run the script is not the same as how discovered instances are passed into collection
Further clarification from LogicMonitor Support may be required. As explained here the AD portion may be needed to return/print the instances:
The instance_id is passed to collection as the WildValue, and the instance_name is what becomes visible in the UI.
Once that is configured, add the WildValue to the collection script. Then use key value pairs or regex to transfer the output to the datapoint. This is explained in greater detail here.