v1.5.0 — media pre-flight and deploy gate

The wizard gains a Media page between Host check and Topology: every external asset the deploy needs (the three eval ISOs, the extracted ConfigMgr media, the ADK and WinPE offline layouts, the VC++ redistributable pair, the version-pinned ODBC MSI) is checked against LabSourcesRoot, one row each. Direct-link assets download straight into the correct folder, Authenticode-verified before a file is kept or a bootstrapper is executed; sign-in-gated ISOs open the vendor download page in the default browser; every row can open its expected folder in Explorer. The Review page lists any missing required media and keeps Deploy disabled until a re-check passes. The check ships as the exported Test-LabMedia cmdlet, with resolution rules mirroring Install-HomeLab exactly. Also includes 1.4.1: the Phase 08 prerequisite-folder fix for #1. See CHANGELOG.md.

v1.4.1 — Phase 08 prerequisite download folder

[1.4.1] - 2026-08-14

Bug-fix release. Fixes #1,
reported by @ehindola.

Fixed

• Phase 08 failed deterministically when no offline prerequisite cache
  was staged. Install-CMSite only created C:\Install\CM-PreReqs as a
  side effect of pushing an offline cache, inside if ($CMPreReqsPath).
  With no cache staged that block is skipped entirely -- but the generated
  unattend INI still points PrerequisitePath at that folder, and CM setup
  does not create its own download folder. Setup aborted in about 30
  seconds with WARNING: Download folder C:\Install\CM-PreReqs does not exist and Failed to download product updates (0x80070003)
  (ERROR_PATH_NOT_FOUND). The folder is now ensured unconditionally
  before the INI is written, on both the cached and download paths.

  This branch was never exercised in testing: every verified end-to-end run
  had C:\LabSources\SoftwarePackages\CM-Prereqs staged, so
  Install-HomeLab's auto-discovery always found a cache and the folder
  always got created incidentally.

• A hard setup failure was reported as "in progress" and then hidden for
  12 minutes. Resolve-CMSetupLogStatus did not recognise CM 2509's own
  terminal banner, Failed Configuration Manager Server Setup -- the word
  order is reversed from the Configuration Manager Setup failed phrase it
  did match, with Server inserted. Setup's failure therefore scored as
  InProgress, the engine logged the benign "normal 2509 async handoff"
  message, waited out the full Wait-CMReady timeout, and threw
  SMS_EXECUTIVE / CM provider did not come ready within 12m -- pointing at
  the wrong phase entirely. The banner and
  Setup failed to download prerequisite components are now matched, so
  this class of failure surfaces immediately with the real log context.

  Success detection is deliberately unchanged: a healthy install logs
  InProgress at setup.exe exit and is recovered by Wait-CMReady
  (re-confirmed against a clean 2026-08-12 run), and a regression test now
  pins that behaviour so the new patterns cannot flip it.

v1.4.0

[1.4.0] - 2026-08-02

Rebrand only. No engine behaviour changes, no schema changes, and no
change to any exported cmdlet -- this is a minor bump because the
public API is untouched.

Changed

• Product renamed to ConfigMgr Lab Builder (was "MECM HomeLab").
  Microsoft dropped "Endpoint" from the product name; the current name
  is Microsoft Configuration Manager and the product team's approved
  short name is ConfigMgr. "MECM" and "MCM" are neither current nor
  approved, so every occurrence in the README, docs, GUI, help blocks,
  and inline comments now reads ConfigMgr.
• Repository renamed mecm-homelab -> configmgr-lab-builder.
  GitHub redirects the old URL, so existing clones and links keep
  working; git remote set-url is optional but tidier.
• Service-account descriptions now read ConfigMgr Client Push,
  ConfigMgr Network Access Account, and ConfigMgr OSD Domain Join
  in config.psd1, every topology template, and
  New-LabServiceAccounts. This is the only rebrand change that
  reaches deployed state: it applies to accounts created from now on.
  Labs built before 1.4.0 keep the old AD descriptions until rebuilt,
  which is cosmetic -- nothing keys off the description string.
• Module manifest Description, Tags, ProjectUri, and
  ReleaseNotes refreshed. ReleaseNotes had been stale at v1.0.0.1
  since the 1.0 line.

Added

• README now carries two evidence screenshots from a real build:
  lab-hyperv-4vm-running.png (the 4-VM two-clients topology idling
  at 11 GB assigned across all four VMs, 0-3% CPU) under Hardware, and
  lab-console-site-status.png (all seven site systems reporting OK in
  the console) at the top of After deployment.

Changed (screenshots)

• All four GUI wizard screenshots recaptured against 1.4.0. Every
  one still showed the old MECM HomeLab branding, and
  gui-host-check.png was old enough to show a 2.0.0-alpha version
  string from before the repo renumbered to 1.0.0.
• main-dark.png removed rather than recaptured. It framed the
  same Welcome page as gui-welcome.png. gui-welcome.png is now the
  README hero, and the "1. Welcome" walkthrough step refers up to it
  instead of repeating the identical image 90 lines later.

Fixed

• GUI version badges in MainWindow.xaml and the Options "About"
  panel were hardcoded to v1.0.0 and never updated across the 1.1,
  1.2, and 1.3 releases. Both now read v1.4.0.
• Sidebar title clipped to "ConfigMgr Lab Build." The new name is
  longer than "MECM HomeLab" and overflowed the fixed 220px sidebar at
  20pt bold, silently truncating the product's own name in its own
  chrome. The title now wraps to two lines. Caught on the first
  post-rebrand screenshot pass.
• Write-LabDeploySummary GUI-logs line never rendered for anyone
  but the author. The path was the literal
  C:\projects\mecm-homelab\gui\Logs. Because it sat behind a
  Test-Path guard, any clone at a different path simply lost the line
  with no error to explain the absence -- and the folder rename in this
  release would have broken it for the author too. Replaced with
  Get-LabGuiLogPath, which derives <repo>\gui\Logs from the module's
  own location, the same way start-homelab-gui.ps1 derives its
  $script:LogDir. Nine tests in Tests/Unit/GuiLogPath.Tests.ps1
  cover the derivation, the three not-a-log-directory cases, and both
  branches of the summary line.

Unchanged (deliberately)

• Module name and public surface. The module is still HomeLab,
  and all seven exported cmdlets (Install-HomeLab, Remove-HomeLab,
  Start-HomeLab, Stop-HomeLab, Test-HomeLab, Connect-HomeLabVM,
  Enter-HomeLabSession) keep their names. Renaming them would be a
  breaking change and a major bump, not a minor one.
• Site code MCM. This is a ConfigMgr three-letter site code, not
  branding. It is baked into the database name CM_MCM, the WMI
  namespace ROOT\SMS\site_MCM, and the unattend INI. Changing it
  would break every existing lab for no naming benefit.

v1.3.1 — audit guidance and teardown idempotency

Bug-fix release. Module version 1.3.1.

Note: GitHub releases were last cut at v1.0.0.1. Versions 1.1 through 1.3.0 shipped in the repository without tagged releases — see CHANGELOG.md for the full record of what landed in between.

Audit told you to run a command that could not help

When cached base images were the only dirty findings, Audit-HomeLabArtifacts.ps1 advised running Remove-HomeLab and re-auditing. Remove-HomeLab -KeepBaseImages preserves those images by design, so repeating it could never clear the verdict — the documented fast-rebuild workflow looped.

The verdict now distinguishes that case and names the switch that applies:

VERDICT: host is DIRTY -- cached base images only.
  Kept the cache on purpose? Re-run this audit with -AllowBaseImageCache.
  Need a from-scratch host? Run Remove-HomeLab -RemoveBaseImageCache, then re-audit.

Mixed findings, or findings that include VMs, still produce the original hard DIRTY verdict.

Remove-HomeLab prompted with nothing to remove

The hosts-file step called ShouldProcess before checking whether any lab entries existed, so a repeat teardown on an already-clean hosts file prompted for confirmation and then reported success for work it had not done. It now looks before it asks. Hand-made entries that resolve a lab VM name are still detected and removed.

v1.0.0.1 — non-interactive deploy fix

Patch release fixing a deploy-blocking crash reported by users.

Fixed

• Non-interactive deploy crash. Install-HomeLab (and the lab-wide resolver in Get-LabCredential) tried to predict whether the host could prompt for a password using $Host.UI.RawUI. On non-interactive hosts (scriptblock / Start-Job / remoting / CI) RawUI is non-null yet the host cannot prompt, so Read-Host threw a cryptic "host program does not support user interaction" error mid-deploy. The prompt now runs only when stdin is not redirected, and is wrapped so a host that cannot prompt surfaces the actionable "lab password is required" message instead of a raw host exception.
• Default lab passwords restored in config.psd1. The published default password (AdminPass and the three service-account passwords) was missing, forcing a password prompt on a default deploy. Restored so a no-argument deploy runs without interaction, matching the documented "default passwords are published in source control" contract.

Upgrade

Pull the latest, or for an affected v1.0.0 install, either update config.psd1 with the default passwords or supply one at deploy time:

Install-HomeLab -LabPassword (ConvertTo-SecureString 'P@ssw0rd!' -AsPlainText -Force)
# or: $env:HOMELAB_PASSWORD = 'P@ssw0rd!'

Full Changelog: v1.0.0...v1.0.0.1

v1.0.0

MECM HomeLab is a native PowerShell + Hyper-V engine that builds a
fully-functional Microsoft Endpoint Configuration Manager 2509 home
lab from a fresh Windows host. One cmdlet (Install-HomeLab), no
external module dependencies.

Highlights

• One-cmdlet deploy. Install-HomeLab provisions three VMs (DC,
  CM site server, Windows 11 client) on an isolated Hyper-V vSwitch
  with NAT, joins them to a domain, installs SQL Server 2022 +
  ConfigMgr 2509, configures discovery / boundaries / SUP / NAA /
  client push, and lays down PostCM customization (collections,
  maintenance windows, boot image, OS image, OSD task sequence
  stub). Clean end-to-end in roughly an hour on a healthy host.
• PowerShell 7.6 LTS / .NET 10. Host orchestrator. No external
  module dependencies; vendored everything (MahApps, ControlzEx,
  Xaml.Behaviors).
• Bare-metal recovery model. Remove-HomeLab strips the lab
  back to base images; re-running Install-HomeLab rebuilds. The
  engine is the recovery story.
• Server 2025 + CM 2509 validated. Engine targets the latest
  Microsoft eval ISOs and CM 2509 site install (with the fixed
  cmdlet schema, ODBC 18.5.2.1 pin, and MSOLEDBSQL19 prereq).
• GUI wizard. WPF + MahApps front-end (gui/start-homelab-gui.ps1)
  for hosts that prefer a click-through topology / template /
  PostCM picker. The wizard composes the same Install-HomeLab
  call.
• Idempotent re-run. Running Install-HomeLab against an
  existing lab short-circuits each phase via "AlreadyExists" /
  "AlreadyInstalled" / "AlreadyPromoted" probes; a no-op re-run
  finishes in well under 10 minutes.

Topology

VM	Role	IP	OS
DC01	Domain controller, root CA	192.168.50.10	Windows Server 2025
CM01	SQL 2022 + ConfigMgr 2509 (site server / MP / DP)	192.168.50.20	Windows Server 2025
CLIENT01	Managed test client	192.168.50.100	Windows 11 Enterprise

Domain contoso.com, NetBIOS CONTOSO, site code MCM. All
configurable via templates/default.psd1.

Architecture

• modules/HomeLab/ -- the engine. Public surface: 7 cmdlets
  (Install-HomeLab, Remove-HomeLab, Start-HomeLab,
  Stop-HomeLab, Test-HomeLab, Connect-HomeLabVM,
  Enter-HomeLabSession).
• Private/ is organized by phase (01-Prereq through 11-PostCM)
  so each phase is independently auditable and re-entrant.
• Helpers/ provides session pooling, logging, file copy,
  unattend INI generation, and predicate-based readiness gates.
• gui/ is a self-contained WPF wizard that drives the engine.

Hardware floor

Resource	Minimum	Recommended
RAM	32 GB	64 GB
Disk	300 GB SSD/NVMe	500 GB+
CPU	4 cores	8+ cores

Known limitations

• CAS hierarchy topology is not implemented; only standalone
  primary sites.
• Client install is verified once per deploy; re-running the
  ADWS / SMS provider gates after a long idle window may need
  a session refresh.