Bug: Win10 provisioning hangs on shared folders - VMWare Tools not installed

[coffeegist]

• Operating System Version: MacOS Big Sur 11.6
• Deploying via (VirtualBox/VMWare/AWS/Azure/ESXi): VMWare
• Vagrant Version (if applicable): 2.2.18

Please verify that you are building from an updated Master branch before filing an issue. √

Description of the issue:

While provisioning Win10, it always gets stuck on this stage:

==> win10: Fixed port collision for 5985 => 55985. Now on port 2200.
==> win10: Fixed port collision for 5986 => 55986. Now on port 2201.
==> win10: Fixed port collision for 22 => 2222. Now on port 2202.
==> win10: Starting the VMware VM...
==> win10: Waiting for the VM to receive an address...
==> win10: Forwarding ports...
    win10: -- 5985 => 2200
    win10: -- 5986 => 2201
    win10: -- 22 => 2202
==> win10: Waiting for machine to boot. This may take a few minutes...
    win10: WinRM address: 127.0.0.1:2200
    win10: WinRM username: vagrant
    win10: WinRM execution_time_limit: PT2H
    win10: WinRM transport: negotiate
==> win10: Machine booted and ready!
==> win10: Setting hostname...
==> win10: Configuring network adapters within the VM...
==> win10: Configuring secondary network adapters through VMware
==> win10: on Windows is not yet supported. You will need to manually
==> win10: configure the network adapter.
==> win10: Enabling and configuring shared folders...

Upon investigation, it seems the issue is VMWare Tools not being installed. I can log in as vagrant, load the tools installer iso, and start the installation as an administrator and it seems to work fine from there on out.

The DC does not seem to have this issue. Let me know if there's any more information I can provide.

Box versions:

vagrant box update
==> logger: Box 'bento/ubuntu-18.04' not installed, can't check for updates.
==> wef: Checking for updates to 'detectionlab/win2016'
    wef: Latest installed version: 1.8
    wef: Version constraints:
    wef: Provider: vmware_desktop
==> wef: Updating 'detectionlab/win2016' with provider 'vmware_desktop' from version
==> wef: '1.8' to '1.9'...
==> wef: Loading metadata for box 'https://vagrantcloud.com/detectionlab/win2016'
==> wef: Adding box 'detectionlab/win2016' (v1.9) for provider: vmware_desktop
    wef: Downloading: https://vagrantcloud.com/detectionlab/boxes/win2016/versions/1.9/providers/vmware_desktop.box
    wef: Calculating and comparing box checksum...
==> wef: Successfully added box 'detectionlab/win2016' (v1.9) for 'vmware_desktop'!
==> win10: Checking for updates to 'detectionlab/win10'
    win10: Latest installed version: 1.8
    win10: Version constraints:
    win10: Provider: vmware_desktop
==> win10: Box 'detectionlab/win10' (v1.8) is running the latest version.

[clong]

Attempting to repro this. What version of VMware Fusion?

[0xv1n]

VMware 16.2 on Windows:

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["enableSharedFolders", "Z:\\DetectionLab\\Vagrant\\.vagrant\\machines\\dc\\vmware_desktop\\a48b65fc-a6f3-4d60-a6e4-771f1a85d6ce\\WindowsServer2016.vmx", {:notify=>[:stdout, :stderr]}]

Stdout: Error: The VMware Tools are not running in the virtual machine: Z:\DetectionLab\Vagrant\.vagrant\machines\dc\vmware_desktop\a48b65fc-a6f3-4d60-a6e4-771f1a85d6ce\WindowsServer2016.vmx

[coffeegist]

Hey @clong sorry for the delay, I’ve been away this weekend but will update as soon as I can. I know it was the most up to date version of VMWare Fusion (maybe 12.1.2 or something). Will confirm soon

[clong]

Hi folks, @n0leptr helped me get some insight into what's happening here in Slack. I'm not sure why it only seems to be happening in newer versions of Fusion/Workstation, but the workaround for now is to manually login to Windows so that VMware tools kicks off its configuration:

It appears VMware Tools doesn't fully install until that happens.

EDIT: This is only the case for Windows 10. It doesn't appear to be installed on 2016 at all.

[clong]

It's definitely intermittent on Win10, at least with VMware Workstation

==> win10: Machine booted and ready!
==> win10: Setting hostname...
==> win10: Waiting for machine to reboot...
==> win10: Configuring network adapters within the VM...
==> win10: Configuring secondary network adapters through VMware
==> win10: on Windows is not yet supported. You will need to manually
==> win10: configure the network adapter.
==> win10: Enabling and configuring shared folders...
    win10: -- C:/Users/build/DetectionLab/Vagrant: /vagrant
==> win10: Running provisioner: shell...
    win10: Running: scripts/fix-second-network.ps1 as C:\tmp\vagrant-shell.ps1
    win10: [14:55] Running fix-second-network.ps1...
    win10: [14:55] No VirtIO adapters, moving on...
    win10: [14:55] VMware Tools not found, no need to continue. Exiting.
    ```

[clong]

OK, I'll try to summarize where I think things are at:

1. The Win2016 box does not appear to have VMware tools installed at all. However, it's clear the installer ran because I see the install logs in c:\Windows\Temp.
2. The Win10 box has them installed, but due to the fact that the OS is booting post-sysprep, I think it has to modify/reinstall them. This introduces an unknown delay between the time the host is booted and when shared folders can be enabled.

What's odd to me is that I don't recall seeing this issue previously. Not sure if I somehow got lucky with my boxes or if the newest version of VMware tools is causing issues.

[clong]

OK, 1 isn't true either because I was just able to successfully provision DC without any issues and VMtools was present, which means this is problem is definitely intermittent (yay)

[clong]

Ah, new theory!

The machine boots up and does a login and reboot when it attempts to set the hostname. During that time, VMware tries to configure itself. If it's able to do it in time, it will work. If not, the host will reboot before VMware installs and vmware will fail to be present from that point forward.

[clong]

As an attempted workaround, I could try disabling synced folders, calling a powershell script inline to ensure vmware tools is installed correctly and then re-enabling it once that's complete. I'll give that a shot.

[clong]

Workaround doesn't work, pops up a dialog box about a previous failed installation of VMware Tools by SYSTEM. Only solution here is to somehow delay the reboot during the hostname change.

[d0gg0d]

Hey, I can confirm that I also have the same issue.

• Operating System Version: Windows 10 Home 19042.1288
• Deploying via (VirtualBox/VMWare/AWS/Azure/ESXi): VMWare Workstation 16.2
• Vagrant Version (if applicable): 2.2.18

Command: ["enableSharedFolders", "A:\\DetectionLab\\Vagrant\\.vagrant\\machines\\dc\\vmware_desktop\\70ea408c-9530-414f-8b90-a0f6d43de460\\WindowsServer2016.vmx", {:notify=>[:stdout, :stderr]}]

Stdout: Error: The VMware Tools are not running in the virtual machine: A:\DetectionLab\Vagrant\.vagrant\machines\dc\vmware_desktop\70ea408c-9530-414f-8b90-a0f6d43de460\WindowsServer2016.vmx

EDIT: Was able to successfully move past this issue.

1. Tried to install VMware Tools on the DC, but the VMware Tools Installation initially failed saying that there was a previous installation of it.
2. Ran vagrant reload dc --provision and received the same issue that VMware Tools is not installed.
3. Went into the system again and tried to install VMware Tools, but this time it was successful.
4. Ran vagrant reload dc --provision and the provisioning seems to go smoothly at the current moment.

• I'm not sure what exactly fixed it lol.