-
Notifications
You must be signed in to change notification settings - Fork 1
Glossary
The terms used across this wiki, with the meaning they carry here. Several of them are borrowed from Munki and from InstallApplications and do not mean quite the same thing in BootstrapMate — those collisions are called out explicitly.
The document BootstrapMate downloads and executes: JSON or YAML, served over HTTPS, listing
what to install. It has two root keys, setupassistant and userland, each holding an array
of items.
This is not a Munki or Cimian manifest. A Munki manifest describes the desired software
state of a client and is re-evaluated on every check-in, with catalogs, pkginfo and an
installs array behind it. A BootstrapMate manifest is a one-shot ordered list of downloads
to run during provisioning; it has no desired-state semantics, no version comparison and no
uninstall concept. If an admin hands you "the manifest" and you are not sure which one they
mean, ask. The full schema is in Manifest Reference.
One unit of work inside a phase: one download plus one installation. An item names name,
url, file and type, and optionally arguments, condition and a few others. Items are
independent — one failing does not stop the others.
The Windows name for the two top-level groupings in the manifest: setupassistant and
userland. The macOS build calls the same concept a stage, following
InstallApplications, and adds a third one. Read "phase" here and "stage" there as the same
idea; see
Stages.
On Windows both phases run back to back in a single process, so the split is organisational — it comes from when the run is invoked, not from anything the tool detects at runtime. See How It Works.
An InstallApplications and macOS BootstrapMate stage: a single script that runs before
everything else and can abort the run — for example, when the device turns out to be
provisioned already. There is no preflight phase on Windows. Note also that Munki uses
"preflight" for something different again: its own hook script that runs before each
managedsoftwareupdate check.
The first phase. On macOS the name is literal — it runs while Setup Assistant is still on screen, before any user session exists. On Windows it is a label for the first array in the manifest, which in practice runs during the Enrollment Status Page because that is when the MSI triggers the run.
The second phase. On macOS it runs once a user session exists and can include user-context
items. On Windows it runs immediately after setupassistant in the same SYSTEM process, so
its items do not execute in a user's session. Anything genuinely user-context belongs in
the ongoing management tool instead.
What BootstrapMate leaves behind for the tool that manages the device from then on — Cimian on Windows, Munki on macOS. BootstrapMate's job is finished once that tool is installed and running; it does no ongoing management of its own. See Handoff to Cimian.
The Windows first-boot setup flow a device runs through before anyone signs in. During OOBE there is no user session and no user profile, and network access can be intermittent — which is why BootstrapMate's signature verification deliberately skips revocation checks.
The Autopilot screen that blocks a user from reaching the desktop while enrollment-time apps and policies install. Apps delivered as blocking ESP applications are the normal way to get BootstrapMate to run early. BootstrapMate does not detect the ESP — it has no idea whether it is running inside one. See Autopilot and the ESP.
Microsoft's Windows provisioning service: a device boots, identifies itself against a profile registered by hardware hash, and enrolls into Intune before first use, optionally showing the ESP while it does. Autopilot is the context BootstrapMate is usually deployed into, not a dependency of it — BootstrapMate is MDM-agnostic and runs anywhere you can invoke it elevated.
The .intunewin packaging format Intune uses for classic Windows installers. It carries an
install command, an uninstall command and a detection rule. BootstrapMate's build produces
.intunewin output alongside the MSI. See Deployment.
The PowerShell script an Intune Win32 app runs to decide whether the app is already installed:
exit 0 means present, exit 1 means install it. Getting this wrong makes Intune reinstall
endlessly. Note that a detection script written against
HKLM\SOFTWARE\BootstrapMate\LastRunVersion detects the MSI install, not a completed
bootstrap run — the completed-run value lives under HKLM\SOFTWARE\Cimian\BootstrapMate. The
detection scripts shipped in the repository's examples directory read the former and compare
it against a hard-coded version string. See
Troubleshooting and Gotchas.
Two GUIDs in every MSI. The ProductCode identifies one specific product version and
changes with each build — BootstrapMate does not declare one, so WiX generates a fresh
ProductCode per build. The UpgradeCode identifies the product family across versions and
must stay fixed for upgrades to be recognised; BootstrapMate's is
{87654321-4321-8765-CBA9-BA0987654321}. Detect on the UpgradeCode or on a registry value,
never on a ProductCode.
The Windows configuration-management client BootstrapMate normally hands off to: the ongoing
layer that keeps software installed and updated after provisioning ends. BootstrapMate has one
piece of specific knowledge about it — an MSI containing the marker CIMIAN_PKG_BUILD_INFO is
routed to sbin-installer rather than msiexec. See Handoff to Cimian.
The macOS configuration-management system Cimian is modelled on, and the handoff target of BootstrapMate for macOS. Its vocabulary — manifest, catalog, pkginfo, installs array, bootstrap mode — is where several words in this glossary come from. Munki does not run on Windows; it appears here because the two BootstrapMate wikis share terminology.