invoke-vmscript not working user specific

[bdmpastx]

We have an interesting issue we are trying to figure out. We had a working automation script that uses invoke-vmscript to execute commands on the target VM. Then a recent security change was pushed by corporate that required digital signing of all powershell scripts. We have signed them all and they run. However when we use this command for our old existing account used for automation, it fails with the error

Invoke-VMScript : 3/29/2021 4:14:10 AM Invoke-VMScript An error occurred while sending the request.

At line:1 char:23
+ ... eESISTask = Invoke-VMScript -VM $vmn -ScriptText $script -GuestUs ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Invoke-VMScript], ViError
+ FullyQualifiedErrorId : Client20_VmGuestServiceImpl_DownloadFileFromGuest_DownloadError,VMware.VimAutomation.ViCore.Cmdlets.Commands.InvokeVmScript

However when we log in with a completely new user and execute the script, it works fine. It only seems to be an issue for old users. Thoughts?

@LucD 

[LucD]

How are the certificates used for the script signing pushed?
With a GPO?
I assume you also changed the ExecutionPolicy for the users?
Can you run a PS script locally when logged in as one of those existing users?

[bdmpastx]

I resolved this issue by removing the account profile and folders. Then logged back in with the troubled account to rebuild the profile in windows. Once I did this, it resolved the issue. So there is something in the profile folders that was causing the cmdlet to break. I am not sure what permission, certificate or something else was causing the issue. If i had the in-depth inner workings of the cmdlet, I am sure I could figure out where it was broken. The -verbose and -debug options of the command did not give any information to help figure it out.

[LucD]

It would have been interesting to test if those old accounts could run a PS script inside the Guest OS.

Directly inside the Guest OS at a PS prompt

[bdmpastx]

Are you talking about PSRemoting?

Scenario

Jump with 2 users sending a script to the target VM.

User1 = old user account created before a recent GPO push.
User2 = new created user after the GPO push

User1 worked before the GPO push. After the GPO push, it required signed powershell scripting. So we installed the certificate and signed all of our powershell scripts. Yet this command failed.

Made another account called User2, tried the same script and it works. No other changes. We did accept the certificates on both accounts and use A option on always allow.

Sample script:

Connect-CiServer
Invoke-VMScript -ScriptText 'hostname' -VM 'VMNameHere' -GuestUser "administrator" -GuestPassword "Password1"

It is possible that corp security pushed other security options down in the GPO that we are not aware of. We only saw the code signing certificate issue so we obtained it and signed. Then the script crashed on the error with the invoke-vmscript cmdlet with the User1 account.

[bdmpastx]

Also note that the jump accounts and the VM accounts are separate and different. So I do not think it matters in regards to the question you posted @LucD 

[LucD]

No, I mean actually logon to the VM, and then run any PS script from there.
Just to check if that works, and what error PS might show

[bdmpastx]

Yeah that works without issue. certificates and GPO do not get to these. These are workload VMs not on the same domains where the GPOs get pushed. Only the jump got the GPO pushed.

[LucD]

You could try my Invoke-VMScriptPlus with the Verbose option.
My function tends to be a bit more 'verbose' than the Invoke-VMScript cmdlet.
Perhaps that clarifies where and which error actually happens.

[bdmpastx]

We actually did try that and the test-invoke one you posted. No real information as to what was going on. Same errors showed up.

[bdmpastx]

When Invoke-vmscript is called, does it save the temp script somewhere on the user profile to transfer to the host/VM? I am just trying to figure out the inner workings on how this is working. I have a open case with Microsoft and VMware trying to determine the root cause. This keeps coming back and deleting the user profile is not the best thing to do every time we need to run the scripts.

[LucD]

Not that I know off.
But you check that by running something like ProcMon from the SysInternals Suite (when on a Windows box).