Important

   

This space contains documentation for TrueSight Server Automation 8.9.03 and the later service packs for 8.9. For earlier releases, see BMC Server Automation 8.9.

Executing PowerShell scripts on target servers

TrueSight Server Automation provides integrated support for executing PowerShell scripts (PowerShell version 4 and later). The following topics describe the options to execute PowerShell scripts on target servers:

Before you begin

Check the blpowershell.cnf file that describes how the PowerShell command is formed when executing the script. This file is present in the share directory in the RSCD installation directory on the target servers. For more information, see Configuring the blpowershell.cnf file.

Ensure that you are using 8.9.04 or later version of the RSCD Agent.

You can use the remote NSH command blpowershell to configure the default values for PowerShell script execution. For information about how to use the blpowershell command, see To manage PowerShell configurations.

To execute PowerShell script through nexec command

If you have a PowerShell script present on the target server, you can use the nexec command to execute that PowerShell script. 

nexec $TARGET_NAME $script_name_with_path

For example, if you have a PowerScript file named getDetails.ps1 in C:\myscripts\ directory on the target server (for example, TargetHost) that provides the details of assets for the asset name provided as command-line argument. For example, to get the details of all processors, use the following nexec command to execute the PowerShell script: 

nexec TargetHost "c:\myscripts\getDetails.ps1" "processor"

If you want to override the PowerShell configurations at runtime, you can use the additional arguments in the nexec command. For information about the arguments to override PowerShell configurations at runtime, see To override PowerShell configurations.

 For example, if you want to ignore the default PowerShell arguments, use the -blpsignoreargs argument as follows:

nexec TargetHost "c:\myscripts\getDetails.ps1" -blpsignoreargs "processor"

You have a script getServiceDetails.ps1 in C:\myscripts\ directory on the target server (for example, TargetHost) that lists the details of the provided service and is written in PowerShell version 2.0. You must ensure that version 2.0 option is passed to the PowerShell command while executing the script. To add this as an additional PowerShell argument, use the -blpsaddargs argument as follows:

nexec TargetHost "c:\myscripts\getServiceDetails.ps1" -blpsaddargs "Version 2.0" "Windows Firewall

To add PowerShell script  as NSH Type 3 script and execute the script

This topic describes how to add PowerShell script  as NSH Type 3 script and store them in the Depot and execute the script.

Perform the following steps:

  1. Add a PowerShell script to the Depot as a Type 3 script by using the Copy and execute the script separately against each host option in the Script Options window. For information about how to add an NSH script to the Depot, see Adding a Network Shell script

  2. Click Add Parameter  in the Parameters window and add the additional PowerShell options that are used at runtime when executing the PowerShell script. For information about the options available at runtime, see To override PowerShell configurations.
    For example, you have a script named Test.ps1 that provides the details of assets for the asset name provided as command-line argument and is written in PowerShell version 2.0. You must ensure that version 2.0 option is passed to the PowerShell command while executing the script. 

    Example scenarioScreen
    To ignore the PS_ARGS values in the blpowershell.cnf file at runtime, use the -blpsignoreargs option.

    To get details of the processors, use processor as a parameter.

    To add version 2.0 as an additional PowerShell argument, use the -blpsaddargs option.

    For this example, the parameter screen will be as follows:

  3. Create a new NSH Script Job by using the same script that you added to the Depot. 

  4. Right-click the job and click Execute to execute the newly created job.

To execute PowerShell script through scriptutil utility

Scriptutil allows the execution of non-NSH scripts against remote targets. You can create a single execution command for a variety of Operating Systems, thus, helpful in creating consistent script results across multiple platforms using multiple scripting languages. Scriptutil copies the provided script to a remote server (to /tmp directory by default) and executes the script on the remote server as a local command. The output is returned to scriptutil and printed to StdOut on your local shell session.

Ensure that the script is located in the <BL_INSTALL_DIR>/share/sensors directory on the server where scriptutil is executed. Usually, the scriptutil is executed on Application Server. The format of the command is as follows:

scriptutil -h win1 -s $script_name

For example, if you have a PowerScript file named getDetails.ps1 that provides the details of assets for the asset name provided as command-line argument. For example, to get the details of all processors, use the following command: 

scriptutil -h win1 -s getDetails.ps1 "processor"

If you want to override the PowerShell configurations at runtime, you can use additional arguments in the command by using the -x operator. For information about the arguments to override PowerShell configurations at runtime, see To override PowerShell configurations.

For example, if you want to ignore the default PowerShell arguments, use the -blpsignoreargs argument as follows:

scriptutil -h win1 -s getDetails.ps1 -x -blpsignoreargs "processor"

You have a script getServiceDetails.ps1 that lists the details of the provided service and is written in PowerShell version 2.0. You must ensure that version 2.0 option is passed to the PowerShell command while executing the script. To add this as an additional PowerShell argument, use the -blpsaddargs argument as follows:

scriptutil -h win1 -s getDetails.ps1 -x -blpsaddargs "Version 2.0" "Windows Firewall" 

To use PowerShell script in Extended Objects

You can use the PowerShell scripts in extended objects. For information about creating an extended scripts, see Creating an extended object.

For example, you want to create a configuration object that provides the details of Windows services for the asset name provided as command-line argument. You created a PowerShell script named Windows_svcs_status.ps1. Ensure that the PowerShell script is located in the <BL_INSTALL_DIR>/share/sensors directory on the server where scriptutil is executed. You can create a new configuration object as follows:

Extended objects uses scriptutil utility. For more information about how to use the scriptutil utility, see Using scriptutil utility.

Videos

The following video (3:44) provides an overview of how to pass the arguments to a PowerShell script.

https://youtu.be/ju3NZVyYs50

The following video (2:27) provides an overview of how to add PowerShell scripts to the Depot.

https://youtu.be/MXdYV2HjF8Y

The following video (4:16) provides an overview of how to execute PowerShell scripts on the RSCD Agents.

https://youtu.be/jq8EbVNVds4

The following video (3:29) provides an overview of how to use PowerShell for compliance on the target servers.

https://youtu.be/Wlj0xuMnVE4

Related topics

Configuring the blpowershell.cnf file

FAQs and additional resources

Was this page helpful? Yes No Submitting... Thank you

Comments