The Remote powershell condition is a custom condition that will execute a Powershell command or script on a remote server to check if a condition is met.
Note: This requires Powershell 2.0
Enabling remote powershell - follow the 2 steps described below:
1 - Enable Remoting: run the Enable-PSRemoting cmdlet on each machine. (answer 'yes', and 'yes', to the prompts)
2 - On your target machine, retrieve the connection info: dir WSMan:\localhost\Listener\Listener_*\* to get the value for the "Remote Port" variable
All general custom condition settings are described below, to develop your own condition plugin read more here.
The custom condition is called "Traxion.IM.Scheduler.Plugins.Powershell.RemotePowershellCondition"
The following parameters apply for the Remote powershell condition.
|This points to a Powershell script with the extension *.ps1, you can configure this or use the Script text parameter|
|If you configured the Script file parameter then the contents will be read from the file and then executed, when you set this to true the Script file will be started directly without reading the contents.|
|This can contain the direct Powershell commands to be executed, you can configure this or use the Script file parameter|
|The parameters that need to be provided to the Powershell script file, this does not apply for the Script text parameter|
The parameter format is like "encryption=true;remote=false;url=http://localhost", multiple parameters are splitted using ';', if the parameter has no value ommit the '=' and only provide the parameter name.
|You can set this global variable to indicate that the condition is or is not valid, set a global variable name like this "$global:<variableName>" in your Powershell command where the variable name is the same as the value configured for the "Custom isValid variable" parameter. The value can be set to a integer (0 or 1) or to a boolean value ($true or $false).|
If this variable is not used then the condition will evaluate to true if the Powershell result was "0", indicating nothing went wrong.
|The name of the computer where the remote runspace is opened. The value can be a fully qualified domain name, a NetBIOS name, or an IP address. For the local computer name (default), use localhost, or use a dot (.) to specify the local computer. When the remote computer is in a different domain from the user, a fully qualified domain name must be used.|
|The port to connect to. Default 5985, to get the correct port on the target server execute step 2 (described above) on the target server |
|Set to true to use the current service account, cannot be used when using basic authentication|
|If current credentials are not used, provide the username and password|
|Password that belongs to the provided username|
|The application end point to connect to, default /wsman|
|The URI of the shell that is launched when the connection is made, default: http://schemas.microsoft.com/powershell/Microsoft.PowerShell|
|Type of authentication mechanism used to create a PSSession using this connection, default is Kerberos. Allowed values:|
|The connection is made using basic authentication|
| The connection is made using CredSSP authentication, which allows the user to delegate credentials. This type of authentication is designed for commands that require a second hop, that is, they run on one computer, but then they connect to other computers to collect data or run additional commands.|
| The connection is made using the authentication mechanism specified by the transport being used. In the case of WSMan, either Negotiate or Kerberos is used.|
|The connection is made using Digest authentication. Digest authentication operates much like Basic authentication. However, unlike Basic authentication, Digest authentication transmits credentials across the network as a hash value, also known as a message digest. The user name and password cannot be deciphered from the hash value. In comparison, Basic authentication sends a Base 64 encoded password, essentially in clear text, across the network.|
|The connection is made using Kerberos or NTLM. The server uses Kerberos to authenticate a domain account and NTLM for local computer accounts. The user name should be specified in the form domain\username for domain users or servername\username for a local users on a server computer.|
|- NegotiateWithImplicitCredential |
|The connection is made using the credentials cached on the PSSession computer.|
|Specifies whether content is transmitted across a secure connection such as HTTPS. If true, Windows PowerShell content is transmitted across a secure connection. If false (the default), content is transmitted across an unsecured connection.|
|indicates whether data encryption is used|
|Set to true to bypass the powershell execution policy for this condition only. You can also disable or change the powershell execution policy on the system by opening a powershell console using administrator rights and type 'Set-ExecutionPolicy Unrestricted', see https://technet.microsoft.com/en-us/library/ee176961.aspx for more information about the powershell execution policy.|
|•||Script credential variables|
If the script needs to have a specific username or password it can be configured and stored encrypted, this way you do not need to store the username/password in the script directly.
You can access the configured username and password via the global variables like "$global:ScriptUserName" for the username and "$global:ScriptUserPassword" for the password.
| Powershell condition settings|
Page url: http://www.traxionsolutions.com/imsequencer/help/index.html?remotepowershellconditiontype.htm