Presently it is not possible for the vCO workflows to run Powershell scripts. However, we are targeting this for future releases.
any idea on timeframes? We have quite a bit invested in PS snippets and would really welcome using this functionality within VCO. Thanks!
The functionality to initiate a PS script on the local file system vCO resides on will be available in the next update of vCO.
Good news that you have gotten this to work via ssh though.
Thanks for the update!
This can be done in the 4.0 Update 2 release (which came out on June 10th, 2010).
To do this, you will need to first modify the vCO server configuration file since issuing an OS command is prohibited by default for security reasons. Please also keep in mind that whatever you are doing here is executed with the credentials of the user running the vCO process (localSystem by default).
1. The file to modify is vmo.properties under the app-server/server/vmo/conf directory.
Add a line to the bottom
and save the config file.
2. Create a new workflow and paste the following line into a "scriptable task" box.
//command = new Command("cmd /c copy c:
command = new Command("powershell.exe -command copy c:
Please do keep in mind that allowing commands to be executed on a server with a workflow has certain security implications. Running PowerShell this way also implies that:
- you are limited to running the PowerShell script without the ability to interact with your script half way through the script
- You can build the string with which to start the PowerShell script (like providing a VM name with VM.name), but the output from the PowerShell script would have to be written to a file that you can subsequently open and read with another workflow (or action).
I hope this helps.
very helpful, and we will be testing this shortly-thank you!
I have spent some time on this and have a way to make it work. For some reason when run this way the $input variable in Powershell is expecting a pipeline and I believe it just waits for pipelined input.
The $input variable is of type System.Management.Automation.Runspaces.Pipeline instead of the usual System.Collections.ArrayList+ArrayListEnumeratorSimple when running scripts. I have tried using the methods in the Pipeline class to clear things up to no avail. I have also tried using the input property on the Orchestrator Command class, but I could not get it to work. I am just getting started with Orchestrator though, so it may be my lack of knowledge.
As a workaround you can input NUL to the script or command using cmd.exe.
#Run a command
command = new Command("cmd /c powershell.exe -Command dir variable: >> c:\\orchestrator\\input.out < NUL");
#Run a script
command = new Command("cmd /c powershell.exe -File c:\\orchestrator\\input.ps1 < NUL");
It has come to my attention that some times the scripts will still hang. After further research there appears to be an issue with stderr hanging the scripts in a similar way to the input. To be safe you should do something with the output from stderr (where error messages are sent).
You can do at least three things
Throw it away with 2>NUL
command = new Command("cmd.exe /c powershell.exe -File c:\\orchestrator\\test.ps1 < NUL 2>NUL");
Log it to a new file with 2> filename
command = new Command("cmd.exe /c powershell.exe -File c:\\orchestrator\\test.ps1 < NUL 2>c:\\orchestrator\\stderr.log");
Send it wherever standard output goes using 2>&1
command = new Command("cmd.exe /c powershell.exe -File c:\\orchestrator\\estest.ps1 < NUL 2>&1");
For further reading on the topic of standard input, output, and error please see
I'm also trying to execute a powershell script from Orchestrator right now. I think I did everything necessary but it doesn't work. I did the following things:
- Set Powershell Execution Policy to RemoteSigned
- Add "com.vmware.js.allow-local-process=true" to "vmo.properties" and restart service
- Grant execute rights to the script folder using "js-io-rights.conf" and restart service
I'm running the workflow as a domain administrator account which has definitely sufficient rights. I'm working with Orchestrator 4.1, are there any changes compared to 4.0?
When I copy exactly the command the workflow executes and execute it manually, it works. I think the "js-io-rights.conf" file could be the problem because it didn't exist, I had to create it. Any suggestions for this? Thanks.
The scripting task I'm using:
var OU = "Member Server";
var servername = "lab-hallo";
var ouStr = "\"OU=" + OU + ",OU=sou-lab,DC=lab,DC=intra\"";
var srvStr = "\"CN=" + servername + ",CN=Computers,DC=lab,DC=intra\"";
System.debug("new ouStr: " + ouStr);
System.debug("new srvStr: " + srvStr);
var cmd = new String();
cmd = "cmd.exe /c powershell.exe -file C:\\SYSMGR\\scripts\\moveOU.ps1 ";
cmd += srvStr + " " + ouStr;
var command = new Command(cmd + "2>C:\\SYSMGR\\scripts\\moveOU.log");
System.log("Executing System-Command: " + command);
var cmdReturn = command.execute(true);
System.log("...returns " + cmdReturn);
System.log("Output: \n" + command.output);
The powershell error message:
Move-QADObject : Access is denied.
At C:\SYSMGR\scripts\moveOU.ps1:4 char:15
+ Move-QADObject <<<< -Identity $server -NewParentContainer $ou
+ CategoryInfo : NotSpecified: (:) [Move-QADObject], Unauthorized
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Quest.ActiveR
My "js-io-rights.conf" file:
- Set Powershell Execution Policy to RemoteSigned
Usually the js-rights-file is created the first time you run a workflow which access a local file. so no issue if it hasn't existed.
I don't think the problem is related to the file, because the error comes from the powershell script. So it got started already.
Now you have to check as which user the orchestrator service runs (usually the local SYSTEM account). With the same user the external powershell script is started . So this account needs the permission to move the objects in AD.
Thank you. I can't test it right know but that has to be the reason then. Isn't it possible to change this? I actually planned to prompt the user for credentials to run the script later. But if this isn't possible I don't even have to try.