Overview

Overview

This page names the moving parts and says what each 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: managedbootstrapinstall.exe

The CLI does all the work. It resolves a manifest URL, downloads and parses the manifest, runs the preflight, orders the items, downloads each one, checks its hash and signature, dispatches to the right installer, and writes the log, last-run.json and the registry status. It can also POST a run summary. Every behaviour 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. Its read-only switches (--version, --status, --last-run) work for any user; an install run needs administrator rights and takes a global single-instance lock, so a second run waits for the first. Its switches and exit codes are in Command Line Reference.

The app: Managed Bootstrap Install.exe

An optional WinUI 3 desktop app installed beside the CLI, with three tabs: Prefs, which shows the machine settings and edits them after Unlock relaunches it as administrator; Run, which starts the CLI elevated and streams the run's session log; and Logs, which browses past runs. It shells out to the CLI rather than installing anything itself, and an unattended run does not involve it. See Managed Bootstrap Install App.

The shared core: BootstrapMate.Core

A library both the CLI and the app use. It holds the settings model and precedence chain (ConfigManager), the reader for policy values under HKLM\SOFTWARE\Policies\BootstrapMate (ManagementDetector), the protected credential store (SecretStore), the Authenticode check (SignatureVerifier), the baseline throttle, the install ledger, the MSI product check, the last-run.json record and the data-directory ACL guard. Despite its name, ManagementDetector detects managed settings, not MDM enrollment or ESP state; nothing in the product detects those.

The MSI and the scheduled task

The MSI installs both binaries, adds the install directory to PATH, writes install metadata and a default ManifestUrl under HKLM\SOFTWARE\BootstrapMate, locks down C:\ProgramData\ManagedBootstrap and the credential key, and registers a scheduled task named BootstrapMate Self-Heal. The task runs daily at 03:00 as SYSTEM with --silent --no-dialog. The MSI starts that task once during installation rather than starting the CLI itself, because a deferred custom action that started the CLI would deadlock against the Windows Installer mutex the MSI still holds. Uninstalling removes the task. See Deployment.

There is no Windows Service. The ways a run happens are the MSI's install-time trigger, the daily task, and whatever you start by hand or through your MDM.

The manifest

A JSON or YAML document at an HTTPS URL, listing what to install. It has up to three root keys, preflight, setupassistant and userland, each an array of items; each item names a download, a local file name and a type, and can pin the download with a SHA-256 hash. The full surface is in Manifest Reference, and Manifests covers hosting and fetching.

Preflight and baseline

A preflight script's exit code chooses the run's mode: skip it, provision in full, or run a baseline that refreshes the setupassistant items on a machine already in use, skipping what is already installed and running at most once per BaselineMinIntervalHours. That is how one manifest both provisions new machines and keeps provisioned ones current through the daily task. See Preflight and Baseline.

The handoff target

BootstrapMate stops when the manifest is done. It does not manage software over time; the point of the run is to get the ongoing configuration-management client onto the device and started, which on Windows is normally Cimian. See Handoff to Cimian.

See also

• How It Works
• Preflight and Baseline
• Manifest Reference
• Preferences
• Deployment