PowerShell Dynamic Applications must include one or more requests that define how SL1 should request data from a device. Each request specifies a PowerShell command that will gather a response from the device.
Each collection object in a PowerShell Dynamic Application is associated with a request. The collection object definition specifies which property in the response should be used to populate the values for that collection object. A single request can be used to populate multiple collection objects.
Defining a PowerShell Request
To define a request for a PowerShell Dynamic Application:
- Go to the Dynamic Applications Manager page (System > Manage > Applications).
- Locate the Dynamic Application for which you want to define a request. Click its wrench icon (
). The Dynamic Applications Properties Editor page appears.
- Click the Dynamic Applications PowerShell Command Editor & Registry page appears. tab. The
- Supply values in the following fields:
- PowerShell Command Name. Enter a name for the command.
- Active State. Specifies whether SL1 should perform this request during collection for this Dynamic Application. Choices are Enabled or Disabled.
- Response Object Key. This field is not currently used.
- PowerShell Implicit Remoting. The mechanism by which a user or application accesses PowerShell cmdlets delivered via the Exchange Management Shell. This mechanism allows Dynamic Applications of type PowerShell to connect to the remote management shell for a Microsoft application and import the cmdlets published by that Microsoft application. Choices are Enabled or Disabled. If this field is set to Enabled, you can reference the imported cmdlets in the PowerShell Command Query field.
- Configuration Name. Grayed out unless PowerShell Implicit Remoting is set to Enabled. Select from a list of configuration names for PowerShell. By default, this field includes:
- Microsoft.PowerShell
- Microsoft.Exchange
To enter a custom configuration name, click the plus sign icon () and enter the custom value.
- Connection URI. Grayed out unless PowerShell Implicit Remoting is set to Enabled. Specifies a Uniform Resource Identifier (URI) that defines the connection endpoint for the session. The URI must be fully qualified. By default, this field includes:
- http://%D/PowerShell
- http://%D:%P/WSMAN
SL1 will replace %D with the hostname or FQDN of the Microsoft server specified in the PowerShell credential.
To enter a custom URI, click the plus sign icon () and enter the custom value.
- Cmdlets to Import. Grayed out unless PowerShell Implicit Remoting is set to Enabled. Enter a comma-separated list of one or more PowerShell cmdlet names that you want to use in this PowerShell session. If you leave this field blank, SL1 will import all cmdlets from the remote management shell for use in this PowerShell session.
- PowerShell Command Query. Enter the PowerShell command to execute. The PowerShell command must meet the following requirements:
- The command must not end with any of the Format-* cmdlets. This includes the use of their aliases (IE. "fl" for Format-list).
- The command must return output that can be piped to the Format-list cmdlet.
- The command must not return whitespace over multiple lines.
- The PowerShell cmdlets you invoke must exist on the target Windows server with the required version of PowerShell.
- The PowerShell cmdlets you invoke must not write to the standard out pipe unless the output needs to be processed and put into a collection object.
- The PowerShell cmdlets you invoke must be synchronous. Do not use asynchronous cmdlets, for example, Invoke-Async or Wait-Job.
- The PowerShell cmdlets you invoke must not be an interactive cmdlet, for example, Enter-PSSession.
- The PowerShell cmdlets you invoke must not query the same property twice.
- If an invoked PowerShell cmdlet creates a new PSSession object, you must invoke the Remove-PSSession cmdlet before the original command ends.
In addition to the requirements listed above, the following best practices are recommended when developing PowerShell commands:
- Perform as much computational work in the PowerShell command as possible to reduce the workload of SL1.
- Query only the pieces of information required to populate the collection objects in the Dynamic Application.
- Per Microsoft guidelines, do not query the Win32_Product WMI class. For more information, see http://support.microsoft.com/kb/974524.
- Click the button.
Editing a PowerShell Request
To edit a PowerShell request:
- Go to the Dynamic Applications Manager page (System > Manage > Applications).
- In the Dynamic Applications Manager page, find the Dynamic Application for which you want to edit a PowerShell request. Select its wrench icon (
).
- Select the Dynamic Application. tab for the
- In the Dynamic Applications PowerShell Command Editor & Registry page, find the PowerShell request and select its wrench icon (
).
- The fields in the top pane are populated with values from the selected PowerShell request. You can edit the value of one or more fields. For a description of each field, see the section Defining a PowerShell Request.
- Select the button to save your changes to the PowerShell request.
Deleting a PowerShell Request
To delete a PowerShell request in the Dynamic Applications PowerShell Command Editor & Registry page:
- Go to the Dynamic Applications Manager page (System > Manage > Applications).
- In the Dynamic Applications Manager page, find the Dynamic Application for which you want to delete a PowerShell request. Select its wrench icon (
).
- Select the Dynamic Application. tab for the
- In the Dynamic Applications PowerShell Command Editor & Registry page, find the request you want to delete. Select its bomb icon (
).
Converting Legacy PowerShell Requests
The 7.3 version of SL1 supported the use of PowerShell Dynamic Applications with an SSH-based proxy. Dynamic Applications developed for the SSH-based proxy are not compatible with the "agentless" PowerShell collection introduced in the 7.5 release.
To update a Dynamic Application developed for the SSH-based proxy for use with "agentless" PowerShell collection, edit each PowerShell request in the Dynamic Application and make the following changes to the PowerShell Command Query:
- Remove "-Computer %s".
- Remove the "Format-List" cmdlet from the end of the command. If you are using a cmdlet that returns properties that you do not want to collect and you want to continue returning a sub-set of properties, use the "Select" cmdlet instead of "Format-List".
For example, suppose you need to update the following legacy PowerShell command:
Get-WmiObject -Computer %s Win32_DiskDrive | Format-List Partitions, DeviceID, Model, Size, Caption
The new command would be:
Get-WmiObject Win32_DiskDrive | Select Partitions, DeviceID, Model, Size, Caption
In addition to updating the PowerShell requests in the Dynamic Application, you must also use a PowerShell credential with the Dynamic Application instead of a Basic/Snippet credential.