Open coffeegist opened 2 years ago
Attempting to repro this. What version of VMware Fusion?
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
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
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.
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.
OK, I'll try to summarize where I think things are at:
c:\Windows\Temp
. 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.
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)
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.
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.
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.
Hey, I can confirm that I also have the same issue.
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.
vagrant reload dc --provision
and received the same issue that VMware Tools is not installed. vagrant reload dc --provision
and the provisioning seems to go smoothly at the current moment.
@OlafHaalstra @coffeegist @tuedenn @n0leptr
Are any of you able to reproduce this issue reliably? I totally believe it exists, I just need someone to help me test the fix if anyone is willing to help
@OlafHaalstra @coffeegist @tuedenn @n0leptr
Are any of you able to reproduce this issue reliably? I totally believe it exists, I just need someone to help me test the fix if anyone is willing to help
Unfortunately, I think it's a coin flip where more often than not the provision routine is successful.
If the fix is pushed to the repo on some branch, I'll be happy to test tonight. I wonder if a recent VMWare or Vagrant update fixed the issue by happy accident. I have run the script a few times in the past month and never encountered this.
@OlafHaalstra @coffeegist @tuedenn @n0leptr
Are any of you able to reproduce this issue reliably? I totally believe it exists, I just need someone to help me test the fix if anyone is willing to help
Unfortunately, I think it's a coin flip where more often than not the provision routine is successful.
If the fix is pushed to the repo on some branch, I'll be happy to test tonight. I wonder if a recent VMWare or Vagrant update fixed the issue by happy accident. I have run the script a few times in the past month and never encountered this.
I have the same experience. Let me reconnect as soon as it happens to me again. Is there any change you made already? Or are you never able to reproduce the issue locally?.
Hi - I'm having the same issue when building the lab first time. On the 2016 boxen. hanging on enabling and configuring shared folders, then eventually fails with the 'vmware tools are not running' error. Will attempt to work around but wanted to share this continues to occur.
I'm working on a fix for this at the moment
@OlafHaalstra @coffeegist @tuedenn @n0leptr
Are any of you able to reproduce this issue reliably? I totally believe it exists, I just need someone to help me test the fix if anyone is willing to help
this happened to me today when i was provisioning dc/2016. all i did was log in to the DC run vmware tools setup - it prompted me to clean up old processes and remnants from a failed install, which i did. then i ran the vagrant reload dc --provision and (minus velociraptor) it seemed to come up
Any update on a fix or workaround?
Just chiming in here, I am deploying the lab for the first time and experienced this with dc. Got stuck at enabling shared folders and eventually timed out with tools not running.
I logged in and saw that vmware tools was not installed, but vmware wouldn't let me install it as the option is grayed out.
Host is Win10 with VMware Workstation 17.0.0, vagrant 2.3.3.
I am also having this issue on both the DC and Win10 machines. I did notice on login that I can't mount the vmware-shared-folders from DC or Win10 to install vmware tools for some reason. Didn't try on the other machine but isn't that how vmware tools is moved to and installed on the windows machines? Prior to this, on both machines I had the error below pertaining to "secondary network adapters". just before the "Configuring share folders step" that it gets stuck on. I got this notification that vagrant will stop overwriting an ethernet setting in the VMX and it may need to be manually changed? See image below. It happened on every affected machine. Could a networking issue be occurring that's preventing the install of VMware tools?
EDIT: I located the vmware-tools msi installer file and attempted to run it on DC and this is what happened. I'm afraid that undoing the changes or simply installing it as this user won't fix the problem on it's own and that it needs to be executed as system for things to work properly.
EDIT AGAIN:
I downloaded the sysinternals suite to get psexec.exe and gain a root shell to run as root.
https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
Add it to your path or add the directory it's in to path.. or just execute the psexec.exe
psexec -i -s VMware tools64.msi
to get a shell as system
The file is located in
C:\Windows\Temp{1FF5D624-5515-4343-837A-E54C101573E6}~setup\VMware Tools64.msi
I would just CD there because the curly braces and everything tend to mess up inputting the path normally.
This will finish the install as system as confirmed by my ability to copy & paste that path above from the VM. Rinse and repeat and then probably just run
vagrant reload dc --provision
like above to work around the issue?
I think the above comment referencing this command worked because, whatever the hold up is (like the installer needs) the reload re-ran the installer as NT-SYSTEM AFTER it occurred.
Seems Win10 sorted this out on it's own but I believe networking is presenting issues to connecting to domain controller now but I think that's another issue
Any update on a fix or workaround?
Any update on a fix or workaround?
@NoraGithub this project is unfortunately no longer being maintained. I remember speaking about this issue in Slack, and from what I remember it's not easily reproducible. In the past, I would get around it by reprovisioning the offending box or destroying and starting over.
I would really not recommend running it on VMWare. I was using the project as the starting point for a school project to get up a quick AD environment for pentesting demo's. I tried almost all of the install methods but on VMWare Workstation Pro with Vagrant had the most issues by far.I believe all the cloud installation methods with Terraform all worked perfectly fine on the first attempt. When I was doing it, it already wasn't being supported but looking back through the issues to troubleshoot each of the numerous issues, the VMWare version always had the most unresolved issues. If you can't afford or just don't like using Cloud, I'd recommend Hyper-V for your local hypervisor platform. Pretty much everyone can use it and IMHO it's better supported and more robust. I've never lost a VM to corruption or anything on Hyper-V but almost every other week, either me or someone I know will have a corrupted VMX or worse. Last week I inadvertently gave my computer a memory leak in trying to repair a corrupted .vmx file for one of my images. Also, the Vagrant/VMWare tool you need to get this project working right often didn't work as intended when installed latest version from Chocolate. It's just too many things to go wrong to use VMWare.
On Sat, Mar 11, 2023 at 3:20 AM Nora @.***> wrote:
Any update on a fix or workaround?
— Reply to this email directly, view it on GitHub https://github.com/clong/DetectionLab/issues/720#issuecomment-1464869060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AP3TYOFP3U3QYBIBIM36IZTW3Q7VVANCNFSM5F3WNNJA . You are receiving this because you commented.Message ID: @.***>
Hey,
Personally I had this bug because I left a tab open on the VMWare window of an old machine that I had previously provisionned.
Regards.
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:
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: