Hi,
is there a way to execute powershell-scripts from Orchestrator-workflows?
I only got it work with an powershell-ssh-server on another system (http://www.powershellinside.com/powershell/ssh/)
and execut a ssh-command inside the workflow.
Regards,
joerg
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
com.vmware.js.allow-local-process=true
and save the config file.
The details of how this is done is in the admin guide under "Setting System Properties" -> "Set JavaScript Access to Operating System Commands"
2. Create a new workflow and paste the following line into a "scriptable task" box.
//command = new Command("cmd /c copy c:
orchestrator
test.txt c:
orchestrator
test1.txt");
command = new Command("powershell.exe -command copy c:
orchestrator
test.txt c:
orchestrator
test2.txt");
command.execute (true);
3. Optional: if you want to get access to another part of the file system, please take a look at "Set Server File System Access for Workflows and JavaScript" section in the Admin Guide. The config file referenced in the guide is not there by default, so you would have to create it.
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.
Sia
Hi Joerg,
Presently it is not possible for the vCO workflows to run Powershell scripts. However, we are targeting this for future releases.
- Angela
Angela,
any idea on timeframes? We have quite a bit invested in PS snippets and would really welcome using this functionality within VCO. Thanks!
--Mike
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,
Sia
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
com.vmware.js.allow-local-process=true
and save the config file.
The details of how this is done is in the admin guide under "Setting System Properties" -> "Set JavaScript Access to Operating System Commands"
2. Create a new workflow and paste the following line into a "scriptable task" box.
//command = new Command("cmd /c copy c:
orchestrator
test.txt c:
orchestrator
test1.txt");
command = new Command("powershell.exe -command copy c:
orchestrator
test.txt c:
orchestrator
test2.txt");
command.execute (true);
3. Optional: if you want to get access to another part of the file system, please take a look at "Set Server File System Access for Workflows and JavaScript" section in the Admin Guide. The config file referenced in the guide is not there by default, so you would have to create it.
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.
Sia
Sia,
very helpful, and we will be testing this shortly-thank you!
This is interesting, i've got it somewhat working, however powershell seems to get hung as a PID and never completes/closes.
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");
command.execute(true);
#Run a script
command = new Command("cmd /c powershell.exe -File c:\\orchestrator\\input.ps1 < NUL");
command.execute(true);
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
we ran into a couple issues, one being the NUL option mentioned above, we we also needed to:
create the following directory for excel to save correctly: and set the following PowerCLI configuration:
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:
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
AccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Quest.ActiveR
oles.ArsPowerShellSnapIn.Cmdlets.MoveObjectCmdlet
My "js-io-rights.conf" file:
-rwx c:/
+rwx c:/SYSMGR/scripts
+rx ../../configuration/jetty/logs/
+rx ../server/vmo/log/
+rx ../bin/
+rx ./boot.properties
+rx ../server/vmo/conf/
+rx ../server/vmo/conf/plugins/
+rx ../server/vmo/deploy/vmo-server/vmo-ds.xml
+rx ../../apps/
+r ../../version.txt
Hi!
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.
regards,
joerg
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.
I don't know for 100% sure, but I don't think its possible to execute a local command as other user (might be a limitation not really by Orchestrator, but by the underlying JBoss).
As an unsupported workaround you can try to run the Orchestrator service with a different account.
(See for one of my older posts about the discussion, I had no bad impacts)
Regards,
Joerg