Current status — v1 live acceptance complete The LabZ1 SQL/MECM/client baseline and its one-device required marker deployment are accepted. Idempotent probes and bounded reconciliation now exist for the complete five-stage workflow. The first exact-source run refreshed only a stale authenticated receipt; the immediate second run skipped all five stages with zero action. Once published, the
v1.0.0tag and GitHub release will be the authoritative publication identity.
setup-cm automates a repeatable, evidence-backed Microsoft Configuration Manager (MECM, formerly SCCM) primary-site deployment for an isolated lab.
It installs and validates a single Windows Server that hosts SQL Server, a MECM primary site, Management Point, and Distribution Point. The baseline also verifies that a dedicated test client can use the site.
Warning
This repository is for lab automation, not production MECM deployment. Do not use its default topology, example configuration, or unattended workflow against production infrastructure.
The current reference lab is LABZ1-CM01.test.gell.one, site LAB, database
CM_LAB, with RING0IVY24-01.test.gell.one as the only accepted client. The
older planned LABZ1-CMCLIENT01 identity is obsolete for current acceptance.
- Phase 0 Lab inventory and baseline acceptance is the authoritative server/client restart record.
- Phase 1 marker acceptance
proves the required marker is compliant exclusively on
RING0IVY24-01. - v1 hands-off acceptance records the exact source, native Windows/provider gates, bounded receipt refresh, zero-action second run, and evidence hashes.
- LabZ1 deployment target summarizes the current inventory and safe restart point.
Routine checks should still use read-only Health and provider/client probes. The accepted workflow tests exact Acquire, SQL, MECM, Marker, and Health state before applying and fails closed on unsupported or conflicting identity.
The release-candidate Marker stage also has an implemented, fixed authenticated
evidence channel: the exact client computer account publishes a strict
six-field record to a one-client hidden share on CM01 after verifying the local
marker hash. An authenticated C$ read remains authoritative when available;
otherwise the CM01 receipt provides the direct client proof. The live channel,
detector revision, target-file inheritance, and zero-action rerun behavior are
accepted on RING0IVY24-01.
A working MECM lab depends on licensed media, exact prerequisite versions, Windows and SQL configuration, and a sequence of setup steps that are difficult to reproduce or diagnose from a script transcript alone. setup-cm makes that process explicit:
- one reviewed YAML configuration declares the target and approved media;
- the stage engine supports testing, applying, and independently verifying a specific desired state;
- every run preserves structured evidence for successful and failed stages;
- source media, secrets, certificates, and product keys stay outside Git.
Read why this repository is designed this way for the boundaries and trade-offs behind those choices.
ProxmoxVEAutopilot / Autopilot Agent
└─ provisions the isolated, domain-joined Windows hosts
└─ setup-cm
Acquire → Sql → Mecm → Marker → Health
└─ run evidence in the configured evidence root
setup-cm owns Windows-side MECM configuration and validation. Virtual-machine lifecycle, operating-system deployment, networking, storage, and domain joining belong to the provisioning layer (for example, ProxmoxVEAutopilot).
The first-release baseline intentionally excludes production targets, distributed topologies, co-management, Patch My PC, reporting, and other optional integrations.
- An isolated, domain-joined lab with a Windows Server host and a separate test client.
- PowerShell 7.0 or later for module operation; PowerShell 7.4 or later when running the Pester 6 test suite.
- Git for Windows with
git.exeonPATH, used to verify the commit embedded in the reviewed source archive before extraction. - The
powershell-yamlmodule to read the YAML configuration. - mdBook to build the documentation site locally.
- Approved SQL Server, MECM, Windows ADK, Windows PE add-on, ODBC Driver 18, and VC++ x64/x86 media, checksums, and accepted licenses.
- Sufficient local disk space for the configured cache, SQL installation directory, MECM installation directory, and evidence.
The CI workflow uses Pester 6, which supports PowerShell Core 7.4 and later. Install the dependencies from PowerShell 7.4 or later when you want to run the unit tests:
Install-Module Pester -RequiredVersion 6.0.0 -Scope CurrentUser
Install-Module powershell-yaml -RequiredVersion 0.4.12 -Scope CurrentUserInstall mdBook using its linked official installation guide before running the documentation build command.
-
Copy
config/lab.example.yamltoconfig/lab.local.yaml. The local file is ignored by Git. -
Replace every placeholder with your isolated-lab details, approved source location, byte length, SHA-256 checksum, version, architecture, and license acknowledgement. See the configuration reference.
-
Import the module and check readiness:
Import-Module ./src/SetupCm/SetupCm.psd1 -Force Test-SetupCmPreflight -ConfigPath ./config/lab.local.yaml
-
Run the guided workflow. When marker acceptance is enabled, pin evidence to the full 40-character commit used to stage the source:
$sourceCommit = '<FULL_40_CHARACTER_GIT_COMMIT>' pwsh ./scripts/Invoke-SetupCm.ps1 ` -ConfigPath ./config/lab.local.yaml ` -Mode Guided ` -SourceCommit $sourceCommit
For unattended agent execution, stage the private configuration separately from the source archive, set both inputs, and run:
$env:SETUPCM_CONFIG = 'C:\ProgramData\SetupCm\config\lab.local.yaml'
$env:SETUPCM_SOURCE_COMMIT = '<FULL_40_CHARACTER_GIT_COMMIT>'
pwsh ./scripts/Invoke-SetupCm.ps1 -Mode UnattendedSee the runbook before operating the workflow.
| Stage | Purpose |
|---|---|
Acquire |
Obtains and verifies SQL Server and MECM installation media in the configured cache. |
Sql |
Installs ODBC Driver 18, SQL Server prerequisites, SQL Server, and SQL network configuration. |
Mecm |
Installs MECM prerequisites, ADK, Windows PE, and the primary site; it re-verifies ODBC Driver 18. |
Marker |
Reconciles the fixed lab-only marker application and its one-client authenticated evidence channel, then verifies the required one-device deployment. |
Health |
Rechecks SQL, MECM, Management Point, Distribution Point, and active-client state without repair. |
Every stage follows Test → bounded Apply when required → independent Verify →
sanitized evidence. Exact compliance produces Skipped and performs no Apply.
A conflict fails before mutation. Health is always read-only. Each selected
stage records stage-<stage>.json in a unique run directory beneath
evidenceRoot; component probes write their state artifacts alongside it.
Preserve that directory when investigating or resuming a failed run. Routine
LabZ1 validation selects Health only. The full five-stage workflow is also
accepted as a no-op from exact reviewed source and should be used only for a
full confirmation or a proven owned-component repair.
The full documentation is published as a GitBook-style site built with mdBook. It includes:
- Getting started — overview, prerequisites, and quick start.
- Configuration — field-by-field YAML reference.
- Operations — runbook, stages, evidence, and recovery.
- Architecture — design principles and module layout.
- Reference — commands, schema, and evidence format.
- Development — designs, plans, testing, and handoffs.
The source lives in docs/gitbook/ and is built automatically on every push to main.
For offline reading, the original markdown sources are still available:
- Why setup-cm exists — the problem, design choices, and non-goals.
- Operator runbook — prepare, run, recover, and validate a lab deployment.
- Configuration reference — how to safely complete
lab.local.yaml. - LabZ1 deployment target — the current reference-lab inventory and order.
- Future projects — optional capabilities kept outside the v1 boundary.
Invoke-Pester ./tests/Unit -Output Detailed -CI
./scripts/Test-MarkdownLinks.ps1
mdbook build ./docs/gitbook