VMware Cloud Community
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

Struggling to run Powershell scripts / commands

Hi all!

I'm struggling to get Powershell workflows working from vCO.  I suspect I've missed something really obvious, but I just can't see it...

I've done the Kerberos set up on the command line of my vCO 5.5.2 appliance.  I've added a Powershell v2 host using the VMWare provided workflows from the Powershell 1.0.4 plugin install, doing Kerberos authentication, and using a shared account (mine, as I know I'm an admin on the Windows server).  I've ensured Kerberos authentication and unencrypted traffic is accepted on the Powershell host.  If I validate the object created in vCO, it says it's fine.

When I come to run another of the VMWare provided workflows, I'm either getting error responses because the workflows don't seem to be correctly formed, or I'm getting a response of null.  When I run a workflow, I can see my account logging on in the Windows 2008 server's security log, so I am fairly confident that the basic connection and Kerberos portions are all ok.

I've just tried to simplify one of the VMWare provided workflows, to make it as basic as possible (code below).  I still get a response of Null.  Does anyone have any ideas why?  Or is anyone able to provide the code for a very simple Powershell based workflow that they know works so I can test on my set up?

Simple powershell script based on the VMWare provided one to get some directory contents, and the values I've been using - this returns Null:

input of host, type:PowerShell:PowerShellHost, value:<myPowershellHostSelectedFromPluginManually>

input of directory, type:String, value: I'm manually entering $home.  Or C:.  Or C:\Windows.  Or any other directory I know exists that my user account has no issues seeing.

output of Result, type:string, value:<whatever the ("DIR " + directory) outputs>

var sess;

// connect to host

  sess = host.openSession()

// send command to powershell

  sess.addCommandFromString("dir " + directory)

// invoke command

  invResult = sess.invokePipeline();

// get result

  Result = invResult.getResults()

// Send out to log

  System.log("Result is " + Result)

Thanks a lot in advance!

Tags (1)
1 Solution

Accepted Solutions
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

And there we go...  That fixed it: powershell.exe wasn't in the path of the Windows Host!

Thanks for the help everyone, especially igaydajiev for giving me the final pointer to my answer! Smiley Happy

View solution in original post

Reply
0 Kudos
14 Replies
siglert
Enthusiast
Enthusiast
Jump to solution

Make sure that the PowerShell on the PowerShell Host is set to "Set-ExecutionPolicy unrestricted"

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

It was set to remotesigned.  I've set to unrestricted, but I'm still getting null. Smiley Sad

Reply
0 Kudos
ExpletiveDelete
Enthusiast
Enthusiast
Jump to solution

can you verify powershell or PowerCLI? Can you run basic gets'? If you are running powershell, can you try basic 'gets' in PowerCLI and see what the difference is? Also assuming there are no permission set issues with your account within Powershell/Windows OS.

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

Ok, I've modified the script above, so now line:

sess.addCommandFromString("dir " + directory)

is now

sess.addCommandFromString("get-date")


If I run get-date, as me, manually in powershell on the host, I get the date and time as expected.  Running my vCO workflow which just contains the script object detailed earlier (with above ammendments), I get null as a result.

My Windows account is an admin on the box.  UAC is enabled (Corporate policy and needs to be in place in the long-term), but I'm not trying to do anything through a vCO connection running as me that I can't do manually directly in Powershell on the host as me.

Edit: I've exported and attached my workflow.  Could someone run it on their working system and let me know if it even works?

Reply
0 Kudos
igaydajiev
VMware Employee
VMware Employee
Jump to solution

Any errors/exceptions in the client?

Have you checked server.log for errors?

To verify that the configuration is fine you can check the plugin inventory. If it shows then it should be good to go for executing scripts.

Try invoking execute "Invoke a  powershell script" workflow and provide "Write-Output "Hello world"" as script.

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

No errors on the client.  I see successful log on attempts in the security event log, but nothing more.

The device appears in the plug-in directory.  If I use the context menu and verify it, it reports back as fine.

I've just used the "Invoke a  powershell script" workflow, selected my Powershell object manually, and put in Write-Output "Hello world" as the script.  The log for the vCO job reports back:

[2014-10-31 14:18:00.320] [D] Invoke command in session 951ec946-7d70-4126-86a0-e65617266a9a

[2014-10-31 14:18:00.563] [I] null

In checking the server.log at debug level, I can see the session open, the session ID be obtained.  Then I get an error (see below for error & attached for part of server.log - I've amended usernames, hostnames and domains) but I've no idea what it means, and finally the session closes reporting a success.

Perhaps I've inadvertently found a 'feature'...??

2014-10-31 14:18:00.558+0000 [WorkflowExecutorPool-Thread-474] ERROR {DefiantFrog:Invoke a PowerShell script:2D8080808080808080808080808080801A80808001304933636362ce882292c2a:ff808081490f601a01496691eae933ac} [BaseSession]

java.lang.NullPointerException

  at com.vmware.o11n.plugin.powershell.remote.impl.BrokerOutputHandler.parseOutput(BrokerOutputHandler.java:73)

  at com.vmware.o11n.plugin.powershell.remote.impl.BrokerOutputHandler.getInvResult(BrokerOutputHandler.java:57)

  at com.vmware.o11n.plugin.powershell.remote.impl.WinRmPowerShellTerminal.readResult(WinRmPowerShellTerminal.java:134)

  at com.vmware.o11n.plugin.powershell.remote.impl.WinRmPowerShellTerminal.sendShellCommand(WinRmPowerShellTerminal.java:118)

  at com.vmware.o11n.plugin.powershell.model.BaseSession.invoke(BaseSession.java:159)

  at com.vmware.o11n.plugin.powershell.model.BaseSession.invoke(BaseSession.java:150)

  at com.vmware.o11n.plugin.powershell.scripting.PowerShellSession.invokeScript(PowerShellSession.java:56)

  at sun.reflect.GeneratedMethodAccessor6655.invoke(Unknown Source)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

  at java.lang.reflect.Method.invoke(Unknown Source)

  at ch.dunes.vso.sdk.WrappedJavaMethod.call(WrappedJavaMethod.java:142)

  at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1473)

  at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:815)

  at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:109)

  at ch.dunes.scripting.server.script.DynamicFunction.call(DynamicFunction.java:172)

  at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:1473)

  at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:815)

  at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:109)

  at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:394)

  at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3091)

  at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:120)

  at ch.dunes.scripting.server.script.MainScriptingObject.executeScript(MainScriptingObject.java:237)

  at ch.dunes.scripting.server.script.MainScriptingObject.executeScript(MainScriptingObject.java:223)

  at ch.dunes.workflow.engine.mbean.WorkflowScriptRunner.execute(WorkflowScriptRunner.java:192)

  at ch.dunes.workflow.engine.mbean.runner.WorkflowItemTaskRunner.execute(WorkflowItemTaskRunner.java:43)

  at ch.dunes.workflow.engine.mbean.runner.WorkflowItemTaskRunner.execute(WorkflowItemTaskRunner.java:24)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.executeItem(WorkflowHandler.java:937)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.requestElementExecution(WorkflowHandler.java:901)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.handleWorkflowTokenNextStep(WorkflowHandler.java:618)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.executeToken(WorkflowHandler.java:505)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.handleTokenExecution(WorkflowHandler.java:444)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.access$100(WorkflowHandler.java:102)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler$1.execute(WorkflowHandler.java:354)

  at ch.dunes.model.ar.AccessRightsTemplate.executeWithAccessRights(AccessRightsTemplate.java:16)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.doExecute(WorkflowHandler.java:350)

  at ch.dunes.workflow.engine.mbean.helper.WorkflowHandler.run(WorkflowHandler.java:236)

  at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)

  at java.util.concurrent.FutureTask.run(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

  at java.lang.Thread.run(Unknown Source)

Reply
0 Kudos
igaydajiev
VMware Employee
VMware Employee
Jump to solution

Could you provide a screen shot of PS plugin inventory including Snapins folder extended?

See attached screenshot from my machine.

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

Hi!

Sorry, I don't feel comfortable sending company specific information on a public forum, however I can tell you that I can't drill any deeper than the Snapins 'folder' - there are no levels below that.

For the general properties of the device, they are:

Name:                    FQDN of the server

ID:                         long alpha-numeric string

Type:                    WinRM

port:                         5985

username:               me@MY.DOMAIN.COM

transportProtocol:     HTTP

connectionURL:     FQDN of the server

This is the first server I've tried to connect to the Powershell plugin.  Having now seen your screen grab example, I'm thinking something may not be right with the device I've connected to.  I'm also going to try connecting to something else.

Reply
0 Kudos
siglert
Enthusiast
Enthusiast
Jump to solution


So log in as the vCO user not as yourself.  Remember that the user that is running the vCO service is passing the workflow to the PowerShell Host.  Then launch powershell from their and Set-ExecutionPolicy unrestricted.  Unless you've done this previously that user probably does not have rights to run a powershell,

Reply
0 Kudos
igaydajiev
VMware Employee
VMware Employee
Jump to solution

You should not be able to add PowerShell host unless it is valid and you are able to connect to it.

At the time when PowerShell host was registered in vCO you were able to connect. Probably something has changed in the environment. You can try to add again the same host.

I guess you already gone trough them but here are some usefull link:

vCO PowerShell plug-in | VMware vCenter Orchestrator Blog - VMware Blogs

[vCO PowerShell plugin] How to set up and use Kerberos authentication | VMware vCenter Orchestrator ...

http://kaloferov.com/blog/using-credssp-with-the-vco-powershell-plugin/

http://kaloferov.com/blog/tag/powershell-host/

First thing I would do is to veerify that you are able to connect to winrm server and execute powershell scripts.


Verify that I am able to connect and authenticate against winrm service

>winrm identify -r:http://winrm_server:5985 -auth:kerberos -u:someuser@somedomain.com -p:password -encoding:utf-8


Verify that I am able to execute ps using winrs client

>winrs -r:http://winrm_server:5985  -u:someuser@somedomain.com -p:somepassword  powershell.exe write-output 'Hello'

Once both command succeed will mean that winrm is properly configured and you can try registering power shell host in vCO.

One more thing. Do you use "Shared session" or "Session per user" mode for configured PowerShell host (see screenshot)?



DefiantFrog
Enthusiast
Enthusiast
Jump to solution

The Powershell connection from vCO is using my Domain user account as a shared user id (Kerberos authentication) to establish the connection from vCO to PS, and I am (sometimes) simultaneously logged in to the server with the same account.  The commands I am trying to pass from vCO are checked on the host directly in powershell (with the same account logged in) to confirm what the output should be before I run the vCO workflow.

And I believe the execution policy is a per-machine thing, not a per-user thing...

Thanks for persisting with the help and ideas though - it's greatly appreciated! Smiley Happy

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

igaydajiev

Yep, I've seen all those URLs Smiley Happy  Everything is set up as it should be with the exception of the CredSSP.  Given that I don't (yet) need to contact other systems from the Powershell host, I assume that's not something I need to look in to just yet...?

I can do the identify bit fine.  The WinRS command isn't working though.  I'll dig in to that - thanks for the pointer! Smiley Happy

And I am using Shared session, with my user id as the account the connection is using.  My user id is an Administrator on the server and am able to run powershell commands direct on the host with no issues.

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

Ah, WinRS IS working, but I don't have powershell.exe in my path on the Windows host.  If I qualify the .exe with a path it works fine.

Reply
0 Kudos
DefiantFrog
Enthusiast
Enthusiast
Jump to solution

And there we go...  That fixed it: powershell.exe wasn't in the path of the Windows Host!

Thanks for the help everyone, especially igaydajiev for giving me the final pointer to my answer! Smiley Happy

Reply
0 Kudos