tschoergez
Leadership
Leadership

howto execute powershell scripts from Orchestrator

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal

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

View solution in original post

0 Kudos
15 Replies
admin
Immortal
Immortal

Hi Joerg,

Presently it is not possible for the vCO workflows to run Powershell scripts. However, we are targeting this for future releases.

- Angela

0 Kudos
FSvcoe
Enthusiast
Enthusiast

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

0 Kudos
admin
Immortal
Immortal

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

0 Kudos
FSvcoe
Enthusiast
Enthusiast

Thanks for the update!

0 Kudos
admin
Immortal
Immortal

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

View solution in original post

0 Kudos
FSvcoe
Enthusiast
Enthusiast

Sia,

very helpful, and we will be testing this shortly-thank you!

0 Kudos
esarakaitis
Enthusiast
Enthusiast

This is interesting, i've got it somewhat working, however powershell seems to get hung as a PID and never completes/closes.

0 Kudos
ewannema
Enthusiast
Enthusiast

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);




http://wannemacher.us

http://wannemacher.us
0 Kudos
esarakaitis
Enthusiast
Enthusiast
0 Kudos
ewannema
Enthusiast
Enthusiast

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

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=...



http://wannemacher.us

http://wannemacher.us
0 Kudos
esarakaitis
Enthusiast
Enthusiast

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:

0 Kudos
AS2E
Contributor
Contributor

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
   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

0 Kudos
tschoergez
Leadership
Leadership

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

0 Kudos
AS2E
Contributor
Contributor

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.

0 Kudos
tschoergez
Leadership
Leadership

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

0 Kudos