Last updated on August 17th, 2026 at 11:36 am
Every lab I run — Intune, SCCM, Group Policy testing — starts the same way: a fresh Windows 11 Enterprise VM on my Proxmox box. I’ve built so many of these now that I’ve got the process down to about 20 minutes, and most of that is Windows installing itself. This post is the full walkthrough: creating the VM in Proxmox with the right settings (TPM and UEFI so Windows 11 doesn’t throw a fit), getting the VirtIO drivers sorted, joining it to my AD domain, and then turning the whole thing into a template so I never have to do it manually again.
If you’re building an AD lab or studying for MD-102, this is the client-side piece you’ll repeat constantly. Worth getting it right once.
Why Windows 11 Enterprise (and where to get it)
I use Windows 11 Enterprise for the lab, not Pro. Two reasons: it’s what you’ll manage in an actual workplace, and Microsoft gives away a 90-day evaluation ISO for free from the Evaluation Center. No licence gymnastics, no dodgy keys — just download it and rebuild when the eval runs out. Since we’re going to template this thing anyway, rebuilding is a two-minute clone job.
You need two ISOs uploaded to Proxmox before you start:
| ISO | Where from | Why |
|---|---|---|
| Windows 11 Enterprise (90-day eval) | Microsoft Evaluation Center | The OS itself |
| virtio-win (latest stable) | Fedora/Red Hat virtio-win repo | Storage + network drivers Windows doesn’t ship |
Upload both to your Proxmox ISO storage (local → ISO Images → Upload) and you’re set.
The VM settings that actually matter
Windows 11 has hardware requirements that trip people up in a VM: it wants UEFI Secure Boot and a TPM 2.0. Proxmox can emulate both — you just have to tick the right boxes when creating the VM.
Hit Create VM and Proxmox walks you through a series of tabs. Here’s what to do on each one:
General — node, VM ID, and a name. I match the VM name to the Windows machine name (LAB-WIN11-01) so I’m not playing guess-the-VM later.
OS — select your Windows 11 Enterprise ISO, then set Guest OS Type: Microsoft Windows and the version to 11. That’s not just cosmetic; it tells Proxmox to apply Windows-appropriate defaults. And because you’ve flagged it as a Windows guest, Proxmox offers to add a second drive for the VirtIO drivers right here on the same tab — tick it and point it at your virtio-win ISO. Both ISOs mounted before you’ve touched anything else. (You used to have to add that second CD drive manually in Hardware afterwards, and forgetting was a rite of passage.)
System, Disks, CPU, Memory — the settings in the table below.
Network — VirtIO model, and note the VLAN Tag field. If your lab sits on its own VLAN and you’ve got tagging configured on the bridge, put the tag in here. If you’re on a flat network, leave it alone.
Here’s my exact build sheet for the middle tabs:
| Setting | Value | Why |
|---|---|---|
| Machine | q35 | Modern chipset, needed for proper UEFI |
| BIOS | OVMF (UEFI) | Win11 requirement — add an EFI disk when prompted |
| TPM | v2.0 (add TPM state) | Win11 requirement — skip this and setup blocks you |
| SCSI Controller | VirtIO SCSI single | Best disk performance |
| Disk | 64GB, SCSI, on NVMe storage | Enable Discard if on SSD/NVMe |
| CPU | 2 cores, type host | Passes real CPU features through |
| RAM | 4–8GB, ballooning on | 4GB is fine for a domain-join test box |
| Network | VirtIO (paravirtualised) | Fast NIC — needs the driver, see below |
| VLAN Tag | Your lab VLAN, or blank | Only if you’ve got VLANs on the bridge |
Double-check before you boot that the virtio-win ISO really is attached as a second CD/DVD drive. You’ll need it mid-install, and it’s much less painful to confirm now than to discover it missing at the disk selection screen.
The install (and the “where’s my disk?” moment)
Boot the VM and mash a key when it says “Press any key to boot from CD” — miss it and you get dumped to a UEFI shell. Type exit, pick the DVD from the boot menu, and you’re back.
Then comes the bit that catches everyone the first time: Windows setup shows no disks. That’s not broken — Windows just doesn’t ship VirtIO storage drivers. Click Load Driver, browse to the second CD drive, and grab the driver from vioscsi\w11\amd64. Your disk appears, install continues like normal.
While you’re at it, the VirtIO network driver isn’t loaded either, so when Windows 11 demands a network connection at OOBE you’ve got a choice: load the NIC driver from the same ISO (NetKVM\w11\amd64), or do what I do for lab boxes — Shift+F10 for a command prompt and run the bypass so I can set up with a local account:
# At the OOBE screen: Shift+F10, then run this to allow local-account setup
oobe\bypassnroThe VM reboots and you get the “I don’t have internet” option. Local account, minimal fuss, done.
Post-install: guest tools, then fix your DNS
First thing after hitting the desktop: run virtio-win-guest-tools.exe from the virtio ISO. One installer gets you every remaining driver plus the QEMU guest agent — then flip QEMU Guest Agent to Enabled in the VM’s Options in Proxmox so the host can see the VM’s IP and shut it down cleanly.
Now the single most important step for the domain join, and the one that causes 90% of “can’t find the domain” errors: point the VM’s DNS at your domain controller. Not your router. Not 8.8.8.8. Your DC’s IP. Domain join is a DNS operation before it’s anything else — if the client can’t resolve the domain’s SRV records, the join fails with an error message that never once mentions DNS.
Joining the domain
You can do it through Settings like a normal person, or do it in PowerShell like someone who’s going to script this later anyway:
# Rename the machine first (reboot before joining)
Rename-Computer -NewName "LAB-WIN11-01" -Restart
# Join the domain and drop it straight into the right OU — prompts for creds, restarts when done
Add-Computer -DomainName "trevtech.lab" `
-OUPath "OU=Workstations,OU=Straya,DC=trevtech,DC=lab" `
-Credential (Get-Credential) -RestartLog in with a domain account after the reboot and you’re in. Quick verification from the DC side:
# On the DC — confirm the computer object landed in AD
Get-ADComputer -Filter 'Name -like "LAB-*"' | Select Name, DistinguishedNameBecause I passed -OUPath, the computer object lands directly in OU=Workstations,OU=Straya,DC=trevtech,DC=lab instead of the default Computers container. That matters more than it sounds: the default Computers container isn’t an OU, so you can’t link a GPO to it. If you join without -OUPath, move the object into your workstations OU now, not later — because the next step is proving Group Policy works.
The first GPO test
A domain-joined box that’s never pulled a GPO is unverified. I keep it dead simple: a test GPO linked to the workstations OU that sets a desktop wallpaper or a logon banner — something visible. On the client:
# Force a policy refresh, then confirm what applied
gpupdate /force
gpresult /rIf your GPO shows up under Applied Group Policy Objects, the whole chain works: DNS, the join, OU placement, policy processing. That’s the moment the VM is officially part of the lab.
Template it — never do this manually again
Here’s the payoff for doing it properly once. Before the domain join (or on a fresh clone built the same way), run sysprep to generalise the machine:
# Generalise and shut down — makes the VM safe to clone
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdownOnce it powers off, right-click the VM in Proxmox → Convert to Template. From then on, every new test client is: right-click → Clone (full clone), boot, quick OOBE, rename, join. Two minutes of my time instead of twenty. Sysprep matters here — cloning without it means duplicate SIDs and machine identities, and SCCM and Intune in particular will make you regret that.
My working order: build the golden VM → guest tools → Windows updates → sysprep → template. Domain joins only ever happen on clones, never on the template itself.
The gotchas
- No disk at install — it’s the VirtIO driver, every time. Load it from the second CD drive.
- “Domain could not be contacted” — DNS. It’s DNS. Point the client at the DC and try again.
- Missed the “press any key” boot prompt — you’re in the UEFI shell.
exit, pick the DVD, carry on. - Forgot the TPM — Windows 11 setup refuses to install. Shut down, add TPM state in Hardware, reboot.
- Cloned without sysprep — works fine right up until endpoint management tools see two machines with one identity. Generalise first.
- Domain-joined the template — now every clone is the same computer account. Template stays workgroup, always.
Is it worth it?
For anyone building an AD, Intune, or SCCM lab: yes, and it’s not close. The first build takes 20 minutes. Every one after that takes two. When you’re testing Group Policy or co-management enrolment, being able to throw away a client and spin a fresh one without thinking is the difference between actually testing things and babying one precious VM.
What’s next
The video walks through every click of this on my R730 — VM creation, the driver load, the join, the template convert.
What’s the first thing you push to a new test client — a GPO, an Intune profile, or an SCCM agent? Let me know in the comments.
— Trev | I broke it. Fixed it.
homelab proxmox active directory windows server enterprise IT powershell
