Highlighted
Contributor
Contributor

Adding a Powershell Host in VRO 7.2

Hi Everyone,

I am trying to add a Powershell host, but the point in which the workflow adds it, it just hands.  I have to stop VRO and, in troubleshooting. kill off any running scripts.

I have followed the various winrm configuration instructions and I can successfully test winrm from my PC to the server.  I have tried configuring 2 seperate servers, both of which are in different domains and a different domain to the VRO server (3 domains).

I am attempting to configure a host with basic authentication, with a local user with admin and RM rights.  I can see a connection being made on the host using netstat.  I've tried turning off the firewall and Mcafee, but get the same result.

If I build a new server, with no domain and configure in exactly the same way, it works.........so what am I missing?

14 Replies
Highlighted
VMware Employee
VMware Employee

Hi,

Are there any errors around the time the workflow hangs (in vRO server and client logs)?

It probably won't make a difference, but could you also try with the latest Tech Preview build of PowerShell plug-in available here https://communities.vmware.com/docs/DOC-25133

0 Kudos
Highlighted
VMware Employee
VMware Employee

Have you configured winrm to use basic authentication?

winrm set winrm/config/service/auth @{Basic=”true”}

Here's a blog with more information: https://www.definit.co.uk/2014/12/configuring-a-vrovcac-powershell-host-with-basic-authentication/

- DG If you find this or any other answer useful please mark the answer as correct or helpful.
0 Kudos
Highlighted
VMware Employee
VMware Employee

Please provide versions of vRO, PS plugin & PowerShell running on the PS host machine

Note that there was a regression introduced with PowerShell plugin version 1.0.10  that can lead to similar behavior.

I will suggest checking PS plugin version and using latest one from here :

Technical preview version of VMware vCenter Powershell Plug-in 1.0.x

Check vRO server log for connectivity related issues near "Add a PowerShell host" workflow execution.

Can you also provide output from following command executed on PS host?

>c:\> winrm get winrm/config

Could you also provide test command used for verification of proper WinRm service and it's output

0 Kudos
Highlighted
Contributor
Contributor

Hi All,

Thanks for your help thus far.....

The link to the configuration blog is exactly the one I used.

  I have also uninstalled the powershell package and reinstalled with the new version as suggested.  Same issue.

Config

    MaxEnvelopeSizekb = 500

    MaxTimeoutms = 60000

    MaxBatchItems = 32000

    MaxProviderRequests = 4294967295

    Client

        NetworkDelayms = 5000

        URLPrefix = wsman

        AllowUnencrypted = true [Source="GPO"]

        Auth

            Basic = true [Source="GPO"]

            Digest = true

            Kerberos = true

            Negotiate = true

            Certificate = true

            CredSSP = false

        DefaultPorts

            HTTP = 5985

            HTTPS = 5986

        TrustedHosts

    Service

        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD

XGW;;;WD)

        MaxConcurrentOperations = 4294967295

        MaxConcurrentOperationsPerUser = 1500

        EnumerationTimeoutms = 240000

        MaxConnections = 300

        MaxPacketRetrievalTimeSeconds = 120

        AllowUnencrypted = true [Source="GPO"]

        Auth

            Basic = true [Source="GPO"]

            Kerberos = true

            Negotiate = true

            Certificate = false

            CredSSP = true

            CbtHardeningLevel = Relaxed

        DefaultPorts

            HTTP = 5985

            HTTPS = 5986

        IPv4Filter = * [Source="GPO"]

        IPv6Filter = * [Source="GPO"]

        EnableCompatibilityHttpListener = false

        EnableCompatibilityHttpsListener = false

        CertificateThumbprint

        AllowRemoteAccess = true [Source="GPO"]

    Winrs

        AllowRemoteShellAccess = true

        IdleTimeout = 7200000

        MaxConcurrentUsers = 2147483647

        MaxShellRunTime = 2147483647

        MaxProcessesPerShell = 2147483647

        MaxMemoryPerShellMB = 2147483647

        MaxShellsPerUser = 2147483647

And the test result from my PC to the server.....

winrm identify -r:http://10.217.147.221:5985 -auth:basic -u:powershellhost -p:****** -encoding:utf-8

IdentifyResponse

    ProtocolVersion = http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd

    ProductVendor = Microsoft Corporation

    ProductVersion = OS: 6.3.9600 SP: 0.0 Stack: 3.0

    SecurityProfiles

        SecurityProfileName = http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/basic, http://schemas.dmtf.org/wbem/wsman/1/wsman/secprofile/http/spnego-kerberos

I'm busy comparing the fres, working server to the one that I need to do, but haven't found anything yet.....

EDIT: I built a new server, it worked.  Patched to current patch level, it stopped working, so I suspect there may be a MS patch involved somewhere....

0 Kudos
Highlighted
VMware Employee
VMware Employee

WinRm configuration looks fine.

Only property that look suspicious is TrustedHosts . I would expect to see there either "*" or vRO host  dns/IP

Try comparing PowerShell versions on PS host machine (before & after the patch)

Determine installed PowerShell version - Stack Overflow

0 Kudos
Highlighted
Contributor
Contributor

I did have '*' in TrustedHosts, but took it out to match the working server.

Versions are indeed different.... 5.1.14409.1005 once patched, up from 4.0 before....so definitely something to investigate further!  What version are others using?

I have also discovered that any powershell action, add host, verify or invoke script is starting powershell on the host.  When I 'end task' powershell, VRO is getting the signal back and the status gets the tick.  I think that although powershell starts, it's not actually doing anything...for example, if I run a script to open a number of powershell sessions, I see them popping up in the machine that works, but they don't in the server that doesn't.

0 Kudos
Highlighted
VMware Employee
VMware Employee

Powershell  5.1 was released recently this year (January).

I am aware of customers successfully using  vRO  PowerShell plugin up to version 5.0.

Microsoft were doing great job keeping it backward compatible and till now have not have issues with new releases of PowerShell so I would expect vRO plugin will work also with PS 5.1 but we have not verified the plugin against 5.1 version of PowerShell. So that is definitely something worth checking I will also try to test it in my lab early next week.

 

0 Kudos
Highlighted
VMware Employee
VMware Employee

Check also vRO server.log file for error messages related to PowerShell plugin

If you don't mind sharing your server.log file from vRO server I could take a look also.

0 Kudos
Highlighted
Contributor
Contributor

We have the same issue and I can confirm that vRO PowerShell plugin no longer works with PowerShell 5.1.

Works fine with 5.0 but not 5.1. Symptoms are hanging workflows in vRO. Have had a PSHost defined in vRO working fine.

This server was upgraded to PS 5.1, now all PsHost workflows just hang when accessing the server.

vRO - 7.1.0.4262825

PSPlugin - 1.0.9

PowerShell - 5.1.14409.1005

Jan

0 Kudos
Highlighted
Contributor
Contributor

Thanks for your feedback everyone.  I had suspected the powershell version, but since Wannacry I haven't had the opportunity to investigate further.

Has anyone tried VRO 7.3 with powershell 5.1?  I will try that next and will add the results here for future reference

0 Kudos
Highlighted
VMware Employee
VMware Employee

We just got an open PR/SR about errors when adding PowerShell 5.1 host using plug-in version 1.0.11, which is the latest available, and the one that is bundled in vRO 7.3. So it seems likely there is indeed an issue with PowerShell 5.1 that will require a fix/new version of the plug-in in case it cannot be fixed via configuration.

Highlighted
Expert
Expert

I can also confirm that it is broken when using WinRM 5.1 with vRO 7.3.  WinRM 4.0 and 5.0 on either Windows 2008 R2 or Windows 2012 R2 works fine with any version of vRO that I have tried. 

We are on 5.1 on most of our Windows hosts, so I was banging my head for a couple of days (on top of that, I'm totally new to vRO) on this before trying a downlevel version.  So I guess no Windows 2016 (which is supposed to by supported with 7.3 based on the matrix).

FWIW, this is the error that is returned from the Windows host when 5.1 is installed (pulled from the relevant fields in the /var/log/vmware/vco/app-server/server.log file on the vRA appliance:

[BrokerOutputHandler] broker_serialize : The term 'broker_serialize' is not recognized as the name

[BrokerOutputHandler] of a cmdlet, function, script file, or operable program. Check the spelling of

[BrokerOutputHandler] the name, or if a path was included, verify that the path is correct and try

[BrokerOutputHandler] again.

[BrokerOutputHandler] At line:1 char:1

[BrokerOutputHandler] + broker_serialize '$host'

[BrokerOutputHandler] + ~~~~~~~~~~~~~~~~

[BrokerOutputHandler]     + CategoryInfo          : ObjectNotFound: (broker_serialize:String) [], Co

[BrokerOutputHandler]    mmandNotFoundException

[BrokerOutputHandler]     + FullyQualifiedErrorId : CommandNotFoundException

[BrokerOutputHandler]

Please consider marking as "helpful", if you find this post useful. Thanks!... IT Guy since 12/2000... Virtual since 10/2006... VCAP-DCA #2222
0 Kudos
Highlighted
VMware Employee
VMware Employee

Just published technical preview version of the plugin (1.0.12) that add's support for PowerShell 5.1 running on Windows Server 2012.

It can be found here : Technical preview version of VMware vCenter Powershell Plug-in 1.0.x

This should resolve your issue.

Hope it helps!

Highlighted
Contributor
Contributor

I'm working with vRO 7.3, but I was having major problems with basic auth.

I had to actually change over to kerberos and it has been working perfectly since. I'm not sure if that helps, but here is the configuration that I did.

Notes:

winrm set winrm/config/service/auth @{Basic="true"}

winrm set winrm/config/service @{AllowUnencrypted="true"}

set-executionpolicy bypass

port 5985 for powershell

Update:

I also had to use a domain user for this since its kerberos.

0 Kudos