Configuring the PowerShell adapter
The PowerShell actor adapter supports empty and multiple configurations. The PowerShell adapter considers the target as localhost and executes the command on the command line under the following conditions:
- The adapter has an empty configuration, and the dynamic target is not defined
- You do not define a dynamic target, and the configuration has a blank target or no target
- You define a dynamic target and do not specify the host name
Adapter type: bmc-adapter-microsoft-windows-powershell-actor [baob201402: version].
Default name: MicrosoftPowerShell
To configure the PowerShell adapter, see Configuring base adapters.
BMC recommends that you do not use empty elements in an adapter configuration because they might cause errors.
Prerequisites for the PowerShell adapter remoting feature
- Set
<powershell-version>
to 2.0. - Install PowerShell version 2.0 on the peer on which the adapter is enabled. For more information about PowerShell remoting, go to http://technet.microsoft.com/en-us/magazine/ff700227.aspx
Note
If PowerShell 3.0 or 4.0 installed on the remote server, the PowerShell module cmdlets commands generates an invalid handle message when run in the xCMD mode. To run the adapter requests successfully, enable the remoting feature for the adapter.
Configuring the PowerShell adapter
The following table describes the adapter configuration elements for the PowerShell adapter that you can specify by using the form view, XML view, or both. You cannot use the form view to configure elements and attributes that do not have an entry in the "UI label" column.
Configuration node elements for the PowerShell adapter
UI label | Element | Definition | Required |
---|---|---|---|
Target |
| Specifies the fully-qualified (absolute) host name or IP address of the remote or the local computer | No |
User Name |
| Specifies the user name required to authenticate the remote host computer | Conditional; required based your environment |
Password |
| Specifies the password that corresponds to the user-name provided | Conditional; required based your environment |
Encryption Type |
| Indicates whether the password specified is encrypted; is an attribute of the | No |
Powershell Version |
| Specifies the version of Microsoft Windows PowerShell Note: This element specifies the version on the local server. When you run PowerShell commands on a remote host which has PowerShell version 3.0 or 4.0 installed, the PowerShell module commands such as import-module or get-module might fail. As a workaround, you can enable the PowerShell remote commands feature to run commands. | Conditional; required if the |
Powershell Consolefile |
| Specifies the Microsoft Windows PowerShell console file, which is the library used by PowerShell that must be loaded | Conditional; required if the |
Character Set |
| Specifies the supporting CharSet | No |
Logon With User Credentials |
| Starts a service on the remote computer
| No |
Use Userprofile |
| Determines whether to load the user profile | No |
Script File Path |
| Specifies the script file path relative to the local (peer) or target (remote) computer | No |
Enable Psremoting |
| Specifies whether to enable the remoting feature of PowerShell version 2.0 If you specify the | No |
Impersonate User | <impersonate-user> | Specifies whether to enable the user impersonation and allow the specified user to execute tasks by using the security context of another user (For example, BAO service running under a user account) For example, a service running as LocalSystem could access network resources by impersonating a specific user account. This account would have been configured with the necessary permissions to access a network resource, something the service would not be able to do otherwise. For more information about how user impersonation works, see Impersonation If set to true, the Service Control Manager (SCM) API is invoked with the user specified in the adapter request or configuration. By default, the xCmd utility runs under the security context of the BAO service running under a user account. When we specify Valid values: true, false (default) | No |
Service Launch Mode | <service-launch-mode> | Specifies the mode to launch the xCommand service on a remote system By default, the xCommand utility is launched on 32-bit mode. Valid value: 64bit, none Note Specify 64bit only if you want to launch the xCommand service on a 64-bit image mode on the target system. BMC recommends that you do not specify any value if 64bit is not required as it can affect the time taken for the request to execute. | No |
The following figure shows an XML sample for the PowerShell adapter configuration.
XML sample of the PowerShell adapter configuration
<config>
<target>host1</target>
<user-name>user1</user-name>
<password encryption-type="Plain">pass1</password>
<powershell-version>2.0</powershell-version>
<use-userprofile>true</use-userprofile>
<script-file-path>local</script-file-path>
<character-set>gb18030</character-set>
<logon-with-user-credentials>true</logon-with-user-credentials>
</config>
The following figure shows an XML sample for a PowerShell adapter configuration with the <powershell-consolefile>
tag.
XML sample of the PowerShell adapter configuration with <powershell-consolefile>
tag
<config>
<target>host1</target>
<user-name>user1</user-name>
<password encryption-type="Plain">pass1</password>
<powershell-consolefile>
Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Console.psc1
</powershell-consolefile>
</config>
The following figure shows an XML sample for the PowerShell adapter configuration when the remoting feature is enabled.
XML sample of the PowerShell adapter configuration when the remoting feature is enabled
<config>
<target>10.128.249.29</target>
<user-name>bmcadmin</user-name>
<password encryption-type="Plain">asdfgh@123</password>
<powershell-version>2.0</powershell-version>
<use-userprofile>false</use-userprofile>
<script-file-path>local</script-file-path>
<enable-psremoting>true</enable-psremoting>
</config>
The following figure shows an XML sample for the PowerShell adapter configuration when the <impersonate-user>
element is set to true.
XML sample for the PowerShell adapter configuration when the Impersonate User is set to true.
<config>
<target>vm-yyy-w2k</target>
<user-name>domain.local\domainuser1</user-name>
<password>password</password>
<protocol>default</protocol>
<service-launch-mode>64bit</service-launch-mode>
<logon-with-user-credentials>true</logon-with-user-credentials>
<impersonate-user>true</impersonate-user>
</config>
The following figure shows an XML sample for the PowerShell adapter configuration when the <service-launch-mode>
is 64-bit.
XML sample for the PowerShell adapter configuration when the <service-launch-mode>
is 64-bit
<config>
<target>vm-yyy-w2k</target>
<user-name>domain.local\domainuser1</user-name>
<password>password</password>
<protocol>default</protocol>
<service-launch-mode>64bit</service-launch-mode>
<logon-with-user-credentials>true</logon-with-user-credentials>
<impersonate-user>false</impersonate-user>
</config>
Comments
The <powershell-version> element only determines what PowerShell version runs on the local BAO server. The version of PowerShell used on the remote system when <host> is specified or <enable-psremoting> is true, will be whatever the default is on the remote machine, which is usually the highest version available.
If <host> is specified and <enable-psremoting> isn't true, then no PowerShell will be executed on the BAO system by the adapter. The version of PowerShell executed on the remote system will be the default version on that system. The <powershell-version> is effectively ignored in this use case.
Updated the description for the <powershell-version> and <enable-psremoting> elements to reflect this behavior.
Thanks!
Log in or register to comment.