igaydajiev - I don't understand why we would see these errors only for specific types of commandlet calls. I have only tested get-cluster, get-vmhost, get-tag and get-tagassignment. The two tag commandlets fail with this delegated user error where the cluster and vmhost calls work just fine.
"The computer must be trusted for delegation and the current user account must be configured to allow delegation."
Usually this kind of error is related to so called multi-hop ("double-hop") issue. Not sure if you had the chance to review provided link but it boils down to that:
You open a connection to remote system (ps host) providing Kerberos token. Then from PS host you try to access another remote system (this is the second hop) for example shared network folder, AD server , or something else requiring authentication and you use same credentials then there should be specific configuration of the user and token used so that it is allowed to be used for authenticating against second remote system.
Usually this kind of error should not appear if you create new Credentials object (from username/password) directly in ps host and provide them to second remote system
I am not sure how exactly Get-Tag is implemented so can not say how provided credentials are used. That's why I suggested to test with older version of powerCLI and so we can confirm that change that triggered the issue is coming fro change in Get-Tag.
Have you tried invoking same power-shell script outside vRO
Import-Module vmware.VimAutomation.core Connect-VIServer -Server 'vcenter.company.loc' -User 'domain\account' -Password 'password' $TagList = Get-Tag
1. Using PS console itself.
2. If that succeed try invoking it in remote context (How to Run PowerShell Commands on Remote Computers ).
If without change in vRO/PowerCLI component but only in vCenter one leads to above error it could be change in authentication in vCenter.
It fails the same through the remote session as it does through vRO. However if I am on the console of the PS Host they all work just fine.
Ok I was able to fix the Remote Session problem utilizing the thread New-TagCategory : 5/2/2017 2:44:44 PM New-TagCategory The underlying connection was closed: An unexpected error occurred on a receive.. At line:1 char:1 + New-TagCategory -Name "Owner" -Cardinality Single -EntityType "Virtua ... uninstalling and reinstalling the PowerCLI. We updated to 6.5.2 with this also. Still having issues with the tag commandlets through vRO.
vRO PS plugin uses remote connection to PS HOST. Meaning that all commands are run in remote context.
If it fails when executed in remote PS console outside vRO it will fail also in vRO.
"Some context: as of VC 6.5 the data used by our tagging cmdlets is returned by a separate service and it seems that the connection we establish under the hood doesn't always succeed in certain deployment scenarios (like the one here). The cmdlets certainly work (as we're testing these against a predefined test bed), but as I said - as we're not covering all possible deployments, we may have missed catching a potential problem.."
I suppose this could be causing the problem we're seeing here.
Just got done trying some more tests and thought I'd share the outcome. I installed Fiddler on the PS Host and ran through the options to decrypt HTTPS traffic so I could see the text. After I did this it works until the server is rebooted. Once it is rebooted the Enter-PSSession and vRO ran PS scripts fail as before. If I run Fiddler again they work again until another reboot.
Is this a change in 6.5? And/or is '-Authentication Credssp' now a valid parameter on Connect-ViServer? it's throwing an error for me.
I'm using Invoke-Command with credssp in other parts of the scripts without issue.
These vRA -> vRO -> PowerShell Plugin -> ScriptHost -> PowerShell scripts worked fine when the PS connected to a 6.0 vCenter. It broke when the vCenter was upgraded to 6.5. That's pretty definitive as to what the problem is. I even built another fresh scripthost and pointed it to a legacy 6.0 vCenter and the very same script once again worked normally. And then to the 6.5 host and it broke.
As to what is and isn't working. Connect-ViServer is and continues to work normally and Get-VM and Get-Cluster and all the other cmdlets continue to work as expected with the exception of the tagging related cmdlets. Those throw the errors documented above.
Is it true (mentioned above) that the backend processes of tagging has changed in 6.5? This would lead us to believe that this is indeed a bug.
Personally, until someone can tell me that they got this scenario to work in their environment I consider this a bug. (vRO/PowerShell that does a Connect-ViServer, Get-VM, Get-Tag) I've worked around it with some functions that wrap the tagging calls in invoke-command -authentication credssp sessions. So at least my vRO environment is functional again. It's slower, but functional.
OK i get similar error purely from PowerShell, not vRO. You may have more luck in the POwerCLI gorups as this doesn't seem to be a vRO issue.
Would you be able to share a code sample for your work around? We are facing the same issue, and have opened a case with VMware. However they are still researching the issue.
I tried wrapping the Connect-VIServer and Get-Tag in a invoke command block and still get the error. The vCenter I am connecting to is not attached to active directory. So there is no credential sharing between vCenter and the Powershell host. I suspect this could be an issue.
I did the fileshare test listed in the link above. I created a simple script to dir a remote fileshare that is in the same domain as the Powershell host. It works from vRO when I wrap it in an Invoke-Command with CredSSP. So it would seem that CredSSP is setup correctly on my host.
Just a quick update. We worked around this issue by using a wrapper script and a temp file.
The wrapper script creates a temp powershell file, that calls the main script. The temp script is then executed using winrs. Here is an example.
$cmdLine = "d:\main.ps1 `'$a`' '`$b`'
$cmdLine | Out-File -filepath "d:\temp.ps1"
winrs -r:http://localhost:5985 -ad -u:domain\user -p:password powershell.exe "d:\temp.ps1"
Here are the quick and dirty functions I'm using as a workaround. There is no error checking.
vRO-StartSession : pass in a credential for the CredSsp connection to itself. it will return a session id that is used to pass to the other functions. mainly this is for speed so the connection to vCenter doesnt need to be constantly opened.
vRO-StopSession : pass in the session id from StartSession.
vRO-GetTag : get listing of tags with Category and Name. This will not return a valid Tag object
vRO-NewTagAssignment : pass in a VM name, tag category, tag name to assign a tag to a vm.
vRO-GetTagAssignment : pass in VM name to get listing of tags assigned to VM. This will not return a valid Tag object.
vRO-GetTaggedVMs : pass in category and name to get a listing of VMs that have that tag assigned. This will not return valid VM objects.
vRO-RemoveTagAssignment : pass in VM name and tag category/name to remove that tag from the VM.
Pretty much just open a session and keep that variable to pass to the other functions. Then close the session when done.
These are pretty specific to our needs, so some customizing may be needed. But it should be a good starting point.
vRO-Tagging.ps1.zip 943 bytes