Skip to main content

MDM rollout overview

pavri-endpointd ships as a signed OS-native package and is rolled out via the customer's existing MDM. This page is the entry point; per-vendor runbooks live alongside:

Every runbook follows the same seven-step structure:

  1. Prerequisites — Pavri tenant + admin role; vendor admin role; signed package.
  2. Token mint — admin walks to /admin/endpoints → Add Endpoint → Mint enrollment token. Tokens are single-use per endpoint, 24h TTL.
  3. Substitution markers — every importable artifact in infra/mdm/<vendor>/ uses ${ENROLLMENT_TOKEN} and ${ORG_ID} substitution markers. Replace before import.
  4. Package signing — what the vendor expects (Developer ID for macOS / Authenticode for Windows / signed .deb or .rpm for Linux) and the current CAP-3 status (CAP-3.7 item 1 Windows-Intel and CAP-3.8 macOS ES are external-dependency gates).
  5. Staged rollout — observe (1 week, 5% fleet) → soft_enforce (1 week, 25%) → enforce (gradual to 100%). The rollout uses existing protection_profile + endpoint-attribute filtering; the MDM only delivers the binary.
  6. Rollback — how to roll back via the vendor and the dashboard-side observe-mode emergency flip.
  7. Post-install verification — Run the verification block in §7 of your vendor's runbook to confirm the daemon is loaded and the native-messaging manifests are healthy. Then confirm the endpoint shows up at the /admin/endpoints page.

Continue to your vendor's runbook for the concrete steps.

Linux note: Ubuntu .deb install/enroll/observe is live-verified. RPM packages have structural checks plus a scheduled/manual Fedora and RHEL-family live validation harness. Linux fleet rollout is configuration-management based rather than classic MDM.