-
Notifications
You must be signed in to change notification settings - Fork 1
Overview
This page names the moving parts and says what each one is responsible for, so that when a run misbehaves you know which component to look at. For the order things happen in, see How It Works.
The CLI does all the work. It resolves a manifest URL, downloads and parses the manifest,
orders the items, downloads each one, verifies MSI and EXE signatures, dispatches to the right
installer, writes the log, writes the registry status, and optionally POSTs a run summary.
Every behaviour documented in this wiki is CLI behaviour unless a page says otherwise. It
lives at C:\Program Files\BootstrapMate\managedbootstrapinstall.exe, which the MSI adds to
the system PATH. It requires administrator rights and takes a global single-instance mutex,
so a second invocation waits for the first (up to 30 minutes) rather than running alongside
it. Its flags are listed in Command Line Reference.
An optional WinUI 3 desktop app installed alongside the CLI, with three tabs: Prefs, which edits the per-user settings and greys out anything a policy has already set; Run, which launches the CLI elevated and streams its output by tailing the newest log file; and Logs, which browses and filters past run logs. It is an operator's convenience, not part of the provisioning path — it shells out to the CLI rather than executing anything itself, and it is not involved in an unattended run.
A library used by both the CLI and the GUI. It holds the settings model and precedence chain
(ConfigManager), the reader for policy-managed values under
HKLM\SOFTWARE\Policies\BootstrapMate (ManagementDetector), and the Authenticode wrapper
that gates MSI and EXE installers (SignatureVerifier). Note that despite its name,
ManagementDetector detects managed settings, not MDM enrollment or ESP state — nothing in
the product detects those.
The MSI installs the binaries, adds the install directory to PATH, writes install metadata
and a default ManifestUrl under HKLM\SOFTWARE\BootstrapMate, and registers a scheduled
task named BootstrapMate Self-Heal. The task runs daily at 03:00 as SYSTEM with
--force --silent --no-dialog. The MSI also triggers that task once during installation, at
InstallFinalize — it starts the task rather than the executable directly, because a deferred
custom action calling the executable would deadlock against the Windows Installer mutex the
MSI still holds. Uninstalling removes the task.
There is no Windows Service. Nothing is installed as a service and no service is ever started. The two ways a run happens are the MSI's install-time trigger and the daily task — plus whatever you invoke by hand or through your MDM.
Two files in the repository look like configuration and are not.
Directory.Build.props is stale relative to the project it is supposed to affect, and
appsettings.json is never read by any code — its working directory, service name and retry
values are documentation of an older design. Configure BootstrapMate through the registry or
the command line, described in Preferences.
A JSON or YAML document at an HTTPS URL, listing what to install. It has two root keys,
setupassistant and userland, each an array of items; each item names a download, a local
filename and a type. That is the entire schema the parser reads. There is no versioning,
dependency, hash, timeout or reboot support in the manifest format — the full surface is in
Manifest Reference, and Manifests covers hosting and
fetching. Where the macOS build uses stage and adds a preflight stage, this build calls
the field a phase and has only the two; see
Stages for the macOS
shape.
BootstrapMate stops when the manifest is done. It does not manage software over time, check for updates, or re-evaluate anything except by running the same manifest again on the next daily task. The point of the run is to get the ongoing config-management client onto the device and started — Cimian on Windows, Munki on macOS. See Handoff to Cimian.