How to run Windows CLI commands from WFA workflow?

[bachman]

Team,

I apologize for the noob question. I have a customer that wants to control a Windows-based application via the CLI using WFA. My question is how issue those commands to a Windows server? If it were Linux, I could use ssh and it would be simple. I haven't found anything that explains how to do this - or did I miss a document?

Phil

[goodrum]

The fastest answer that I can give is to use remote powershell calls.  You can use Invoke-Command.  Just make sure that you either pass credentials or that the WFA service is running as a user with rights on the box.

http://technet.microsoft.com/en-us/library/dd819505.aspx

Jeremy Goodrum, NetApp

The Pirate

Twitter: @virtpirate

Blog: www.virtpirate.com

[sinhaa]

Invoke-Command is a very good option for running remote commands on a destination Windows host. It allows to run direct commands or execute a Powershell script ( on remote server). I also remember having to use Get-WmiObject as well, but Invoke-Command is definitely simpler.

It has the following prerequisites.

1. On the Powershell console of the Destination Windows host, configure winrm ( Windows Remote Management ).

2. Make your WFA server as a TrustedHost: winrm set winrm/config/client @{TrustedHosts="wfahost_name_or_IP"}

3. This is enough to get the command execution working. But there are other winrm config option you can set as per your needs. Read more here :http://pubs.vmware.com/orchestrator-plugins/index.jsp?topic=%2Fcom.vmware.using.powershell.plugin.doc_10%2FGUID-D4ACA4EF-D018-448A-866A-DECDDA5CC3C1.h...

Attaching the command which can be imported in a WFA2.1 or above. I must say,it was little more difficult than I initially thought. WFA doesn't support [scriptblock] as an input parameter type. So the command in [string] entered needs to be created as a [ScriptBlock] type in the code.

Command code:

===

param (

  [parameter(Mandatory=$false, HelpMessage="Command to execute")]

  [string]$CmdBlock,

  [parameter(Mandatory=$true, HelpMessage="Windows Host Name")]

  [string]$WinHost,

  [parameter(Mandatory=$false, HelpMessage="Posh script path")]

  [string]$PoshScript

)

$creds =  Get-WfaCredentials -Host $WinHost

# Convernt string command block to Script Block

$ScriptBlock = [Scriptblock]::Create($CmdBlock)

if ($CmdBlock) {

$returnData= Invoke-Command -ComputerName $WinHost -Credential $creds -ScriptBlock $ScriptBlock

Get-WFALogger -Info -Message $returnData

}

if ($PoshScript) {

# Posh Script should be present on the WFA server.

Invoke-Command -ComputerName $WinHost -Credential $creds -FilePath $PoshScript

}

=====

[bachman]

One minor correction the the above:

2. Make your WFA server as a TrustedHost: winrm set winrm/config/client @{TrustedHosts="wfahost_name_or_IP"}

should be

winrm set winrm/config/client '@{TrustedHosts="wfa_hostname_or_IP"}'

The @{Trusted...} section needs to be enclosed in single quotes.

Phil

[bachman]

Thank you for the sample command. I imported it into my WFA 2.2RC1 server, but am getting errors on execution. I believe that WinRM and PowerShell are configured correctly, as I can execute the remote command from the PowerShell prompt on the WFA host.

Example of error when doing "Test" of the imported command:

Example of execution of Invoke-Command from PowerShell prompt on WFA server:

[sinhaa · Accepted solution]

Ahh Phil. A bit of miss from me. This is not the code error actually, its thrown by the Get-WFALogger -Info -Message $returnData which expects that $returnData will always be a String type and in your case its returning a list.

Remove the line : Get-WFALogger -Info -Message $returnData

from code and it will work. Also modified the code to convert to script block after only when CmdBlock is provided.

$returnData will depend on how output your command returns, it could be a list, object anything, string etc. Now its up to you to parse it and use it.

Attaching the new .dar file with the correction.

===

param (

  [parameter(Mandatory=$false, HelpMessage="Command to execute")]

  [string]$CmdBlock,

  [parameter(Mandatory=$true, HelpMessage="Windows Host Name")]

  [string]$WinHost,

  [parameter(Mandatory=$false, HelpMessage="Posh script path")]

  [string]$PoshScript

)

$creds =  Get-WfaCredentials -Host $WinHost

# Convernt string command block to Script Block

if ($CmdBlock) {

$ScriptBlock = [Scriptblock]::Create($CmdBlock)

$returnData= Invoke-Command -ComputerName $WinHost -Credential $creds -ScriptBlock $ScriptBlock

}

if ($PoshScript) {

# Posh Script should be present on the WFA server.

Invoke-Command -ComputerName $WinHost -Credential $creds -FilePath $PoshScript

}

===

sinhaa

[bachman]

sinhaa,

One last noob question. Is there a facility to display the return value?

The main reason I'm building this is to show a customer we can control NetBackup through WFA. Ultimately they want to add a step to provisioning workflows to add volumes to a NetBackup policy as the volumes are created, so they are protected "automatically".

Being able to show the results - a list of the NetBackup policies - is all I need to complete this. Then we'll have them engage our ACS folks to help with the actual implementation.

Phil

[sinhaa]

@ Is there a facility to display the return value?

====

Of course. But you need to know what is the type of object returned by the Command. That you can know by manually running the Invoke-command once. Like for the command you have provided in your list, the return object is an array list. If you use powershell3.0, the Powershell ISE shows very well the kind of objects returned and what methods you can call on them. Its useful, but its up to you.

so from the script you can get lit like

$first_value = $returnData[0]

$second_value = $returnData[1]

If these are not objects themselves but strings, then you can always use Get-WFALogger to print them now.

If they are then you can still call method on them to get string values.

Get-WFALogger -Info -Message $first_value

Get-WFALogger -Info -Message $second_value

I hope this helps.

warm regards,

Abhishek

[bachman]

Is PowerShell 3.0 preferred?

[JGPSHNTAP]

Powershell 3.0 is the way to go...

[hill]

Yep... agreed.  PowerShell 3.0 is the way to go... especially as it is the default version of PoSH on Windows Server 2012 xx.

[bachman]

One last question:

Following Microsoft directions to install PowerShell 3.0, it wants me to load either .NET Framework 4.0 or 4.5 which includes PowerShell 3.0. Do we care whether .NET is 4.0 or 4.5?

Phil

[JGPSHNTAP]

Only reason to go to 4.5 is if you plan on in the future to goto powershell 4.0 which isn't necassary.

Stick with 4.0

that's just my opinion