Closed OlafHaalstra closed 2 years ago
I see that the issue is already described before in: https://github.com/clong/DetectionLab/issues/289 and https://github.com/clong/DetectionLab/issues/447 and https://github.com/clong/DetectionLab/issues/720 (slightly different error, stating the VMWare Tools are not running).
The proposed earlier solution did not work:
This should be fixed with vmware_desktop Box v1.2 Destroy all existing VMs:
vagrant destroy -f
Update boxes:vagrant box update detectionlab/win10 && vagrant box update detectionlab/win2016
Remove old boxes (optional, but recommended):vagrant box prune
What did work for me is as soon as the script has reached:
==> win10: Enabling and configuring shared folders...
You reinstall the VMware tools manually, after that it will pick up automatically and continue the provisioning.
I had the same error. And what i have done to solve this is:
when it raises a err like: "Command: ["enableSharedFolders", ....", log on to DC machine (VMWare in my case), and install VMtools manually (VM -> Install VMWare tools)
try vagrant reload dc --provision
to reload DC machine, again!
Its worked! modern problems require modern solutions! :) I think UAC (when) is the main problems to cause this issue (correct me if im wrong)
Hi folks, there's more context here (https://github.com/clong/DetectionLab/issues/720) but the long story short is there's a race condition when the hostname is getting set. When the VM boots for the first time, it also has to configure VMware tools to re-configure itself (due to sysprep having run). If VMware tools setup completes before the hostname change, everything will work fine. If not, you'll run into this issue. I still haven't found a solid fix for this yet.
This might be solvable by disabling the Vagrant hostname setting and just using powershell to do it via Rename-Computer
Closing as this is now being tracked in #720
Let me start off with saying that DetectionLab is really awesome work and loving it ever since I discovered it!
Please verify that you are building from an updated Master branch before filing an issue. ✅
Description of the issue:
While bringing any box up (logger, dc, wef or win10) the following error is presented:
I can verify that the machine is in fact up and running:
This also happened a few times when bringing up the machines after completely removing them. After a few runs of
vagrant reload [host] --provision
eventually it completed the sequence without this error. Some things are working: given that the logs are coming into Splunk with no problem (did not test all functionality).However some things seem to be a bit flaky, e.g. pinging hosts from the DC (also can't reach the c$ share of win10.windomain.local, neither works via IP):
Any idea what might go wrong here? Everything destroying all VMs and or repeatedly reprovisioning them doesn't sound like the correct solution