Skip to content

Offboarding and Archive Vault

Jump to bottom
Tyler Hatfield edited this page Nov 12, 2026 · 1 revision

Endpoint & Client Offboarding + Data Archive Vault

Vitrine RMM includes a purpose-built lifecycle and archival engine (backend/src/services/offboarding/index.ts) designed so MSPs never lose critical BitLocker recovery keys or LAPS local admin passwords months after offboarding an endpoint or client — while ensuring retired agents cleanly revert changes and remove themselves.

1. Endpoint Lifecycle States

Every managed endpoint transitions cleanly through three explicit lifecycle_state stages:

  1. active: Standard managed online/offline endpoint enrolled in fleet monitoring, patching, and policy enforcement.
  2. pending_offboard: Offboarding was requested while the endpoint was offline. Scheduled LAPS rotations are automatically skipped, and the cleanup + agent uninstall payload is queued for immediate execution the moment the agent checks in.
    • Force Archive: Admins can click Force Archive (POST /api/devices/:id/force-archive) at any time (e.g., lost/stolen/recycled hardware) to move it immediately into the Archive Vault.
    • Auto-Archive Policy: Each policy tier configures offboard_offline_auto_archive_days (default 14 days) so long-offline pending_offboard devices automatically transition to archived.
  3. archived (Data Archive Vault): Offboarding is complete (no longer pending). The endpoint is hidden from active alert noise and billing counts, while all last-known telemetry, hardware serials, AES-256-GCM escrowed BitLocker/LUKS/FileVault keys, and LAPS credential histories remain preserved until an MSP Super Admin explicitly executes a permanent purge (DELETE /api/devices/:id/archive-purge).

2. Clean Online Offboarding Sequence

When an online endpoint is offboarded (POST /api/devices/:id/offboard), Vitrine dispatches a clean teardown sequence before moving the record to archived:

  1. Reverts applied Vitrine policy overrides, scheduled tasks, and tray hooks.
  2. Applies the resolved Managed Local Admin (LAPS) Offboard Rule (see Section 3).
  3. Cleanly uninstalls the Vitrine companion scripts and MeshCentral agent service.
  4. Snapshots final LAPS & BitLocker recovery state into the Data Archive Vault and writes an immutable audit_logs entry.

3. Contextual Managed Local Admin (LAPS) Offboard Rules

Across all 4 policy tiers (Global -> Client -> Site -> Role), administrators can independently configure what happens to the managed local admin account (laps_account_name) for each of the three offboarding contexts:

Context Policy Field When Applied Available Actions
laps_offboard_explicit_device_action Single endpoint explicitly offboarded (explicit_device) keep_account_rotate_final (Default), keep_account_as_is, disable_account, remove_account
laps_offboard_client_archived_action Entire parent Client offboarded to Archive (client_archived) keep_account_rotate_final (Default), keep_account_as_is, disable_account, remove_account
laps_offboard_client_deleted_action Parent Client permanently deleted (client_deleted) remove_account (Default), disable_account, keep_account_rotate_final, keep_account_as_is

4. Client-Level Offboarding (Archive vs Permanent Delete)

Via POST /api/tenants/:id/offboard (or Settings / Fleet -> Offboard Client):

  • Default Safe Mode — Archive Entire Client (mode: 'archive_client'):
    • Marks the client lifecycle_state = 'archived' and preserves the entire client organization, sites, BitLocker keys, and LAPS histories in the Data Archive Vault.
    • Online endpoints cleanly offboard immediately; offline endpoints enter pending_offboard (or archive immediately if forceArchiveOfflineDevices is checked).
    • Clients can be restored to active status at any time via POST /api/tenants/:id/reactivate.
  • Permanent Client Deletion (mode: 'delete_client_permanently'):
    • Cleanly offboards online endpoints, registers Client & Device Tombstones (deleted_tenants_tombstones and deleted_tenant_device_tombstones), and permanently purges the client's vault records.

5. Wake Resurrection vs. Quiet Self-Offboarding

Whenever an endpoint wakes up, sends a heartbeat, or runs an installer (POST /api/agent/enroll, POST /api/health, or POST /api/devices/:id/simulate-checkin), handleAgentCheckInOrWake() enforces exact lifecycle safety:

  • Archived Endpoint + Active Parent Client -> Automatic Resurrection (resurrected_from_archive): Because an archived endpoint has already finished any prior offboarding, waking up or reinstalling under an active client automatically restores the existing device record (lifecycle_state = 'active', status = 'online'), preserving its historical audit trail and vault continuity!
  • Pending Offboard Endpoint -> Completes Offboard to Archive (queued_offboard_completed_to_archive): Executes the queued cleanup + LAPS action and transitions cleanly to archived.
  • Archived OR Permanently Deleted Parent Client -> Quiet Self-Offboarding (quiet_offboard_executed): Even if no device-specific offboard was queued, matching an archived client or the Deleted-Client Tombstone Registry immediately instructs the agent to quietly apply the configured LAPS rule and uninstall itself — never re-creating zombie records for departed clients.

Clone this wiki locally