VMware Cloud Community
StephenChr
Contributor
Contributor

Invoke-VMScript - Firewall requirements?

The bottom line question I have is am I dealing with some kind of firewall rule that's blocking two-way communications?  I suspect not, but, trying to cover my bases here...

I've been trying to figure out how to get Invoke-VMScript to work.  I've turned on the VMWare Tools debugging, and I can see my commands make it INTO the VM (Very simple "Hello World" type of command, like "DIR C:\") but all I'm getting back is "An error occurred while sending the request" back.  It sits and spins its wheels for about a minute before it times out.  Looking at the logs that happen within the time frame of my commands, I'm not seeing any kind of error or any indication of any kind of fault.

What I can confirm is that if I typo the guest password, I'm getting authentication denied statements, which means that I am doing some kind of comms to the machine and I'm correctly being rejected.

My setup is like this

- ESX Hosts are in AWS
- The goal FAILS when I'm working from home, through to the office VPN, to AWS, to the VMs, as well it fails when I run the commands on a VM in the same cluster and network.
- I've also spun up a bare-bone Win2019 VM to do some testing on the AWS site, installed PowerCLI and still have the same problem

I'm aware that, from a networking standpoint, the Invoke-VMScript is not talking DIRECTLY to the VM, but the commands are being passed through to the VM via vSphere

- I use the connect-viserver command and authenticate as myself (Not the account WORKGROUP account in the VM)
- I can run get-vm and I can see a list of servers hosted in the cluster.
- I can mess up the credentials and I get a correct answer back with bad authentication when using Invoke-VMScript
- If I provide the correct credentials, I get this "An error occurred" message back
- With all of the above points
  - I've run the commands from my home machine, to the eventual end-point VM I'm testing with
  - I've run the commands as close to the metal as I can get (Another VM in the cluster

As mentioned, I've turned on the VMTools logging up to Debug, and I'm not seeing anything that indicates a problem on the destination VM.

As part of my trying to figure this out, my procedure is:

- On the target VM, I turn off the VMWare Tools service.
- I go into the Logs directory and delete what I can. (c:\Windows\Temp)
- I start the VMWare Tools service
- I take note that the log files are regenerated
- I wait for a minute or so, to get a "time buffer" between entries
- I look at the clock on the VM, run the Invoke-VMScript on my local machine, wait for it to fail, and look at the clock again on the VM
- I stop the VMWare Tools service and wait for the log files to get written out
- I look at the service log and search for my command (DIR C:\) and look at the time stamps

I've attached the vmsvc.log file.  The "interesting" stuff seems to start at 2022-08-19T19:04:43.268Z

Reply
0 Kudos
7 Replies
LucD
Leadership
Leadership

Could you try the same with my Invoke-VMScriptPlus function with the Verbose switch?
The function should give some feedback on what is happening at each step.


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
StephenChr
Contributor
Contributor

I get no answer no matter what the parameters I provide to the Plus script. Invalid parameters (As in keyboard-slap parameters) does spit back errors.

We don't store credentials on the server, so I provide the GuestUser and GuestPassword at the CLI when I go to transmit code.

Given that, I've tried the Plus script, I execute the script as:

.\Invoke-VMScriptPlus.ps1 -vm {host} -GuestUser Administrator -GuestPassword ThePassword -ScriptText 'dir c:\' -ScriptEnvironment bat -Server {vSphereHostIP} -Verbose

Reply
0 Kudos
LucD
Leadership
Leadership

That will not call the function.
Assuming you stored the function code in the file Invoke-VMScriptPlus.ps1, you will first have to dot-source that .ps1 file to make the function "known".
Then you can call the function

# Dot-source the .ps1 file (notice the blank between the 2 dots)
. .\Invoke-VMScriptPlus.ps1

# Now call the function
Invoke-VMScriptPlus -vm {host} -GuestUser Administrator -GuestPassword ThePassword -ScriptText 'dir c:\' -ScriptEnvironment bat -Server {vSphereHostIP} -Verbose

 


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
StephenChr
Contributor
Contributor

This got me somewhere.  Thanks for the tutorial on how to get this script "installed".

I made a small modification to tell me what exactly was being sent to the server:

VERBOSE: Copying Data to C:\Users\ADMINI~1\AppData\Local\Temp\Stephen_23540vmware202\Stephen_23540vmware249.cmd using the command
VERBOSE: Invoke-WebRequest -Uri https://{ESXHostIP}:443/guestFile?id=413&token=52b06d8f-798b-649c-fb17-b432636e18d1413 -Method Put -Body dir c:\

I get the error that it can't talk to the host.  So either the service isn't running on the ESX host to take these commands in, or I've got a firewall rule not setup right...

Reply
0 Kudos
LucD
Leadership
Leadership

That could be caused by the fact that the ESXi certificate does not contain the IP address, only the FQDN.
I added the NoIPinCert switch in the function just for that reason.
Try adding that switch on the call to Invoke-VMScriptPlus function


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos
StephenChr
Contributor
Contributor

Invoke-VMScriptPlus -vm $vm -GuestCredential $gc -ScriptText 'dir c:\' -Server $vsphereip -verbose -scripttype bat -NoIpInCert

Two relevant errors show up;

Reverse DNS lookup name does not exist.

Resolve-DnsName : {reverseIP of ESX Host}.in-addr.arpa : DNS name does not exist

As well as:

Invoke-WebRequest : Cannot bind parameter 'Uri'. Cannot convert value "https://:443/guestFile?id=413&token=526ddda4-9817-a3c3-58cd-8ef29d9e0933413" to type "System.Uri". Error: "Invalid URI: The hostname could not be parsed."

That said, even if I try to run an HTTPS invoke-webrequest against the ESX host, I get an unable to connect.  Seems more and more like a FW rule.

Reply
0 Kudos
LucD
Leadership
Leadership

Or the DNS resolution on the station where you run the code can't resolve the ESXi IP address


Blog: lucd.info  Twitter: @LucD22  Co-author PowerCLI Reference

Reply
0 Kudos