I Built My First Active Directory Lab From Scratch — Here’s Everything That Went Wrong (and What It…

There's a piece of advice that shows up in nearly every cybersecurity book: before you attack Active Directory, build one yourself. It sounds simple. It is not simple. And that gap — between "sounds simple" and "actually works" — is where the real learning happens.

I recently set out to build a small home lab: one Windows Server domain controller, one Windows 11 client, joined into a single Active Directory domain, fully isolated from my real network. No shortcuts, no pre-built lab-in-a-box scripts. I wanted to hit every wall myself, because the walls are usually where the understanding lives.

Here's the honest account of how it went — including the two hours I spent staring at a black screen wondering if I'd broken something.

Why Bother Building This Manually

It would have been faster to spin up a pre-configured lab environment. But there's a difference between running someone else's Active Directory and understanding why it works. Domain controllers, DNS integration, SYSVOL replication, Kerberos trust — these aren't things you can shortcut your way to understanding. You have to build the thing, break the thing, and fix the thing.

So: VirtualBox, two VMs, one domain. Windows Server 2022 as the domain controller, Windows 11 as the client. Both isolated on a private internal network so nothing I did would ever touch my actual home Wi-Fi.

The First Wall: A Screen That Refused to Boot

The first VM sat on a black screen. Then it showed "No bootable medium found." Then it looped back to the same disk-selection screen during Windows Setup, again and again, like a video stuck on rewind.

The instinct here is to panic and assume the ISO is corrupted, or the VM is cursed. It wasn't either. It came down to a setting I hadn't thought twice about: UEFI vs. legacy BIOS. VirtualBox's boot behavior changes significantly depending on which firmware mode is active, and my first attempts had it configured in a way that made the "press any key to boot from CD" prompt effectively invisible — it wasn't broken, I just couldn't see it happening. Switching Windows Server to legacy BIOS mode fixed it immediately.

The Real Villain: A Thirty-Minute Freeze

The domain controller eventually installed and promoted successfully. Then came the client machine — Windows 11 this time, which (unlike Server 2022) requires UEFI, Secure Boot, and TPM 2.0 to install at all. Fair enough, I enabled all three.

And then it sat on "Applying computer settings" for over thirty minutes.

This is the point where most people either give up or start smashing the reset button. I did neither — I went looking for evidence instead. VirtualBox keeps detailed logs of exactly what's happening under the hood, and buried in there was the actual explanation:

CPUM: No hardware-virtualization capability detected
NEM: Snail execution mode is active!

CPUM: No hardware-virtualization capability detected
NEM: Snail execution mode is active!

My CPU absolutely supports hardware virtualization. But Windows' own Hyper-V feature was quietly claiming exclusive access to it — probably enabled by something else on my system — which forced VirtualBox to fall back to pure software emulation. Imagine trying to run a modern video game entirely on a CPU with no graphics card. That's roughly the performance gap we're talking about.

One command fixed it, run as administrator on the host machine:

bcdedit /set hypervisorlaunchtype off

bcdedit /set hypervisorlaunchtype off

A restart later, and the same install that had crawled for thirty minutes finished in a few. Same hardware. Same VM. Completely different experience — because the actual bottleneck had nothing to do with what I could see on screen.

Why This Actually Matters

Here's the thing about troubleshooting like this: it's not really about VirtualBox, or Hyper-V, or even Active Directory specifically. It's about developing the instinct to look for root cause instead of surface symptoms. A black screen isn't "broken" — it's a system telling you something, if you know where to look. A slow install isn't just slow — it's a resource conflict with an explanation, if you check the logs instead of guessing.

The Payoff

Once both machines were up and communicating, the actual Active Directory setup was almost anticlimactic by comparison:

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "lab.local"

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools
Install-ADDSForest -DomainName "lab.local"

Two commands, a password prompt, and a domain existed. Joining the client took a few clicks in System Properties. Verifying it worked meant checking Active Directory Users and Computers on the server and confirming the client showed up as a recognized computer object — which it did.

I now have a working, fully isolated lab.local domain: a domain controller with DNS and SYSVOL running correctly (SYSVOL just needed a few extra minutes to catch up after a rocky reboot), and a Windows 11 client that trusts it completely.