🖥️ Another milestone down in the homelab-to-mini-datacenter project: Active Directory is alive, my desktop has sworn fealty to a domain, and Pi-hole is now laundering DNS requests through a genuine Windows Server like it’s got a briefcase and a corporate lanyard. Let’s get into it. 🎩
Previously on this series: I built the Proxmox cluster and rolled it out with Terraform — catch up here if you missed it.
🏰 A Domain Is Born: muench.home.arpa
Active Directory is now live, installed on HP1-dc01 and HP2-dc02 as a proper multi-DC setup (because one domain controller is just a single point of failure with a fancy name). The domain itself is called muench.home.arpa — a naming choice courtesy of ChatGPT, who correctly pointed out that .home.arpa is the one TLD reserved specifically for “this will never, ever be routed on the real internet, I promise.” No accidental collisions with someone’s actual public DNS zone. Nerdy, correct, and mildly bureaucratic-sounding. 10/10, would delegate naming decisions to an LLM again. 🤖
My desktop PC (an Asus NUC, doing its best impression of a corporate workstation) has been joined to the domain. One down, a couple more to go — I’ve still got two more PCs and a laptop waiting for their turn to become domain citizens. 💻➕
🕸️ The DNS Daisy Chain of Questionable Elegance
Here’s where it gets fun. The DNS resolution chain now looks like this:
FritzBox (router)
│ DNS server = DC01
▼
DC01 (Windows Server, AD-integrated DNS)
│ DNS server = Pi-hole VM
▼
Pi-hole
│ upstream DNS = FritzBox
▼
FritzBox → the actual internetYes, it loops back to the FritzBox at the end — that’s the point. Every client asks the domain controller, the domain controller forwards to Pi-hole, Pi-hole does its ad/tracker-blocking magic, and only then does anything hit the FritzBox for real resolution. Net effect: DNS-level ad blocking now happens transparently for every domain-joined machine, with zero per-client configuration, laundered through infrastructure that also happens to run Kerberos tickets. Enterprise-grade ad blocking. Nobody asked for this level of over-engineering, and yet here we are. 🙃
🗺️ The Z: Drive Saga Continues…
I also had a PowerShell script written up that idempotently creates a Group Policy Object mapping drive Z: to a Samba share, pointed at a dedicated NAS-ish Linux VM, for every domain user at logon. GPO created ✅, linked to the domain ✅, shows Enabled = True in every RSOP check I’ve thrown at it so far ✅.
Does Z: actually show up in Windows Explorer yet? No. Not yet. 😅
It’s the kind of bug that makes you question SYSVOL replication, secure channels, DNS, event logs, and eventually your own sanity, in that order. Consider this an open thread — when I finally catch the gremlin responsible, it’s getting its own dedicated post, because at this point it’s earned one.
📦 File Storage: Separate Samba VM, Not the Domain Controller
Small architecture decision worth calling out: I could have just used DC01 itself as the file server — AD and file services have shared a box since roughly the dawn of Windows NT. Instead I split file storage out onto its own dedicated Linux/Samba VM.
Why? Mostly flexibility — I’d rather be able to resize, snapshot, rebuild, or eventually cluster storage independently of “the box that also happens to run my entire domain’s authentication.” Coupling your file server’s lifecycle to your domain controller’s lifecycle is the kind of decision that seems fine right up until it very much isn’t. 🔥🗄️
🧰 The Desktop Workflow: VS Code as a Very Fancy SSH Client
Worth a mention since it explains a lot of the setup logic: all Linux-side management — git, Ansible, kubectl — lives on a dedicated Seed VM, not on my desktop. My actual workstation, dual monitors and all, runs essentially nothing locally for this: it’s just VS Code, remoted via SSH straight into the Seed VM, opening a folder and a terminal there. The Windows desktop is basically a very nice, very expensive terminal emulator with a Start menu at this point. 😄
✅ Status Check
- AD domain
muench.home.arpa— live on two DCs - Desktop joined to the domain — 1 of 4 client machines done
- DNS chain with Pi-hole ad-blocking through the domain — working
- GPO-based
Z:drive mapping — configured, not yet visible client-side (ongoing investigation) - Dedicated Samba VM for file storage — decided and running
- Remaining VM work — more to come in future posts
Next up in this series: standing up GitLab as the source-of-truth for this whole lab, plus the developer Seed VM setup in more detail — git, Terraform, Ansible, kubectl, all pre-baked so infrastructure work doesn’t depend on whatever laptop happens to be within reach. Stay tuned. 🚀
