July 24, 2026 · Jason Ulbright

A one-command MECM lab, and why I stopped hydrating

I maintain mecm-homelab, a native PowerShell 7 + Hyper-V engine that builds a working ConfigMgr 2509 lab from a bare Windows host. One cmdlet, no external module dependencies, MIT licensed. This post is the pitch I would want if I were still building labs the old way.

The numbers first

Measured on my host (20 threads, 32 GB, NVMe), with transcripts to back them:

  • Bare host to healthy site: about 1 hour 10 minutes. That is from ISOs — the engine builds sysprepped base images, provisions VMs from differencing disks, promotes the DC, installs SQL 2022, runs CM 2509 setup, and configures the site through to a green health report.
  • Teardown and full rebuild from cache: 45 to 65 minutes depending on topology. The base images cache by ISO hash; a rebuild skips straight past image creation. The CM site install is the long pole and nothing caches that.
  • Re-run against a healthy lab: under ten minutes. Every phase probes existing state and short-circuits, so re-running after a config tweak converges instead of rebuilding.

What it replaces

The classic way to get a ConfigMgr lab is a hydration kit: MDT builds you an ISO, the ISO automates the OS and role installs, and everything around it is yours to do by hand — create the VMs, wire the network, boot things in the right order, wait, and clean up whatever is left when you want to start over. It works, and I used that approach for years. But the parts it leaves to you are exactly the parts you get wrong at 11 PM.

mecm-homelab owns the whole loop. Install-HomeLab creates the switch, writes the hosts entries the host needs to reach lab VMs by name, checks that your topology's startup memory actually fits the RAM you have free right now (not just the RAM the spec sheet says you have), provisions everything in parallel, and sequences the phases with readiness gates instead of hope.

Teardown you can prove

The feature I lean on most is the one I have never seen elsewhere: Remove-HomeLab plus an audit script that enumerates every artifact a lab run creates on the host — VMs (including strays from configs you renamed months ago, found by disk location), checkpoints, switches, cached images, orphaned VHDXs, leaked ISO mounts, hosts entries, temp files — and exits 0 only when the host is provably clean. A wrapper script chains teardown, audit, build, and health check under one transcript, and refuses to build unless the audit passes.

That exists because I once shipped a "successful" end-to-end test that had silently consumed a stale cached image from an earlier run. The audit gate makes that class of mistake impossible to repeat quietly — and building it surfaced a dozen real bugs in my own engine, which is its own story for another day.

What you get on day one

A three-VM lab by default (DC with root CA, site server with SQL 2022 and all roles co-located, Windows 11 client), with the operational details already handled: AD discovery on, boundaries and boundary group built, client push that actually works on Windows 11 (the engine opens the firewall paths push needs — default Win11 blocks them, even domain-joined), a test collection with a maintenance window, WSUS and a software update point, and opinionated driver choices — ODBC pinned to 18.5.2.1 because current CM breaks on newer, MSOLEDB left alone because CM setup installs its own.

Seven topology templates go from a 2-VM schema exercise up to a 9-VM CAS layout. The one I use daily is two-clients: the default lab plus a second Windows 11 client, so application testing gets a clean control machine instead of checkpoint rollbacks. There is also a WPF wizard for people who would rather click through it; it composes the same cmdlet call.

Who this is for

MECM admins who need a disposable, truthful replica of the product they run in production — for testing application packaging, validating a claim before repeating it in a runbook, rehearsing an upgrade, or just having a site you can break on purpose. The whole point is that the lab is cheap enough to destroy that you actually destroy it, and provable enough that "fresh build" means something.

Requirements: a Windows 10/11 Pro or Server host with 32 GB RAM and ~300 GB free, PowerShell 7.6, and the eval ISOs staged. The README walks through all of it.