Closes the "how do sites actually deploy GE-Enforce" gap (esp. OOBE-ppkg sites
without a PXE/WinPE step). Site-neutral + imaging-path independent.
- plugins/geenforce/client/Install-GEEnforce.ps1: a bootstrap that writes the
PC's identity (C:\Enrollment\pc-type.txt is what determines the PC type; plus
machine-number/cmm version/cmm id/site-config as needed), sets the shopdb
BaseUrl + token in HKLM:\SOFTWARE\GE\ShopDB, deploys the client kit, optionally
copies the engine from -EngineSource, and registers the SYSTEM scheduled task
(at logon + every N min). Idempotent; fails loud (installer, not the fail-safe
runtime). Engine is REFERENCED not vendored - it belongs to the GE-Enforce
framework; the script warns if absent but still labels the PC.
- docs/GE-ENFORCE-DEPLOY.md: the deploy contract - the three things a PC needs
(client, identity, credential), the identity table (what determines PC type,
no auto-detection - the provisioner supplies it; shopdb cannot set it at
imaging), and how to invoke per path (PXE step, OOBE ppkg via
ProvisioningCommands, Intune, manual), the engine boundary, and verification.
- Cross-linked from docs/GE-ENFORCE.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Verified claim-by-claim against the engine/dispatcher/preinstall runner/manifests.
Corrections (3 were ship-blocking):
- Timeline (ship-blocking): identity files (pc-type/machine-number/cmm version/
site-config) are written in WinPE at the PXE menu BEFORE the image boots, not
during a post-imaging 'enrollment' step; preinstall already reads them. Added a
step [0]; enrollment is now only Intune + Azure DSC credential provisioning.
- _CmmVersion (ship-blocking): a CMM bay with NO resolved version gets ALL
PC-DMIS versions (legacy install-all), not none.
- machine-number 9999 (ship-blocking): the enforcement engine does not
special-case 9999; it is a placeholder that won't match real bay gates (the
9999-skip is status-write-back only).
- Preinstall runner implements only MSI/EXE + Registry/File detection, not the
full matrix (that is runtime-only).
- Runtime processes up to three scopes: common, type, then optional type-subtype.
- pc-subtype.txt is legacy (no longer written at imaging since 2026-05-04).
- The collector ComputerType mapping lives at Settings > Collector PC Types, not
the geenforce scope (scope computertypeid is a local reference field).
- FileVersion is a raw string compare; 4-part is convention, not engine-enforced.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
docs/GE-ENFORCE.md - operator-facing guide grounded in the real engine +
manifests (Fable-verified analysis): how GE-Enforce works (preinstall vs runtime
phases, the enforce loop, manifest scopes/entries, self-heal detection, gates,
enrollment), WHEN it installs/takes over in the imaging timeline (preinstall at
imaging -> GE-Enforce laid down -> enrollment provisions creds -> runtime
enforcement from first logon), how the shopdb plugin manages it (Manifests
authoring + contextual targeting + simulate + publish/rollback + Export to Share
Milestone 1, Enforcement Reports), day-to-day IT tasks, and a reference index.
Complements GE-ENFORCE-CLIENT.md (client contract) and the proposal (plan).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
