I like a fresh lab. I do not like building one for the umpteenth time, especially when the build takes longer than the thing I actually wanted to test.
build-lab is the final piece in a three-script set, and the one that ties the other two together. One command, an ISO, and roughly half an hour later you have a Windows Server 2025 domain controller. Log on once and the domain populates itself with a directory that looks lived in, nested groups and GPOs and an Enterprise CA included. No GUI, no answer file to hand-edit, no clicking Next.
This is an orchestrator. It calls New-VMwareWorkstationVM to build and start the VM, pushes the new-AdDomain payload into the guest over vmrun, and kicks off the promotion. Still PowerShell 5.1, still nothing outside what Microsoft and VMware already ship.
One thing is deliberately manual. Directory population runs from a scheduled task that fires at your first Administrator logon, so you do have to log into the console once. I could automate it by storing a domain Administrator password under a startup-triggered task. That's the one compromise I decided not to make, even in a lab, and I'm still not certain it was the right call.
The interesting problem was verification. A successful AD promotion reboots Windows immediately, which tears down the vmrun guest-operations channel mid-call. A blocking call hung on that reboot and never came back. So the guest script gets launched fire-and-forget, which means there is no exit code to read. Just silence.
Instead, build-lab confirms success by polling for ntds.dit in the guest, and pulls the guest's deployment logs back to the host either way, because the run you need logs from is the one that failed.
https://github.com/0x44616e69656c/build-lab
What's the step in your lab build that you've rebuilt by hand so many times you've stopped noticing it?
#PowerShell #ActiveDirectory #WindowsServer #Automation #HomeLab #VMware #InfoSec
🐘
