MDM Sync & Change Management
When Arrakis updates the recommended OpenTelemetry environment or hook configuration for an agent, customer endpoints pick up the change on their MDM’s next sync cycle. This page documents per-MDM sync cadence, on-demand sync commands, and Arrakis-side change notifications, so IT teams know what to expect after any change.
Per-MDM sync cadence
| MDM | Default check-in interval | What triggers re-evaluation | Force-sync command |
|---|---|---|---|
| Jamf Pro | 15-minute recurring check-in (admin-configurable in Computer Management Framework Settings) | Profiles re-evaluate at every check-in; updated profiles are pushed to devices when the MDM server queues a profile-update command | From the device: sudo profiles renew -type=configuration or sudo jamf policy. From Jamf Pro: device record → “Send Blank Push”, then “Update Inventory” |
| Microsoft Intune | ~8 hours on macOS and Windows; also at user sign-in | Policy refresh runs at the check-in cadence; Settings catalog changes propagate at the next refresh | Company Portal → Sync (per-user); or Intune admin center → device → “Sync”; on Windows: Settings → Accounts → Access work or school → Sync |
| Iru (formerly Kandji) | ~15-minute agent check-in | Library items are continuously enforced — missing files and modified plists are re-applied automatically | Self Service app → Sync; from terminal consult Iru’s current CLI docs for the equivalent force-run flag (Confirm against vendor docs) |
| Generic / other MDMs | Vendor-specific (Workspace ONE, Mosyle, Hexnode typically 15–60 min — Confirm against vendor docs) | Refer to vendor docs | Vendor-specific |
Confirm exact intervals and CLI flags against your MDM’s current docs before relying on them — vendor defaults change.
Arrakis-side change management
When Arrakis updates the recommended endpoint policy:
- Tenant admins are notified in the Arrakis console under Settings → Integrations → Deployment → Changelog. Each entry names the affected tools (e.g., “Claude Code OTel collector endpoint rotated”) and the recommended action.
- Versioned drop-in fragments. Arrakis publishes new payloads as drop-in fragments named with sortable prefixes. Customers replace the fragment file rather than merging into a base — see Claude Code → Drop-in directory. The exact fragment file names are provisioned per-tenant; see the Arrakis platform under Settings → Integrations → Deployment.
- Republish required badge. For push-only MDM topologies (where the MDM server holds the canonical payload and devices receive it on push), Arrakis surfaces a “Republish required” badge on the changelog entry. The IT admin downloads the new fragment, updates the MDM payload, and re-distributes.
- Forward compatibility. Arrakis-recommended policy is designed to be additive where possible: new keys do not invalidate old payloads, and token rotation paths support a grace window so endpoints with stale config keep working until the next sync.
Live policy push
Arrakis can update the deployed MDM payload directly when a policy change needs to take effect — for example, blocking a newly-published Claude Skill, MCP server, or plugin before the next regular check-in cycle would otherwise pick it up. The customer authorizes this by issuing a least-privilege API credential to Arrakis, scoped to the specific profile-management operations Arrakis needs and nothing else. Live push is the only way to enforce policy changes faster than the next MDM check-in cycle.
How live push works
- Customer creates an API credential in their MDM, scoped to the operations Arrakis needs (and nothing else).
- Customer pastes the credential into the Arrakis platform under Settings → Integrations → MDM.
- When a policy change is published in Arrakis (e.g., a new MCP allowlist), Arrakis calls the customer’s MDM API to update the corresponding configuration profile or settings catalog policy.
- Devices receive the updated payload at their next MDM check-in. Optionally, customers can grant Arrakis a separate force-sync permission to trigger an immediate check-in for in-flight enforcement.
Per-MDM credential setup
Jamf Pro
Authentication. Jamf Pro API uses OAuth 2.0 client credentials. The customer creates an API Client (Jamf Pro 10.49.0+) with bound API Roles, then generates a Client Secret. Cite: https://developer.jamf.com/jamf-pro/docs/client-credentials .
Required role (least privilege). In the Jamf Pro UI: Settings → System → API Roles and Clients → New role. Assemble the following privileges (verbatim from Jamf):
- “Create macOS Configuration Profiles”
- “Read macOS Configuration Profiles”
- “Update macOS Configuration Profiles”
- “Delete macOS Configuration Profiles”
For Windows-only fleets, replace “macOS” with “Mobile Device” privileges.
The exact Jamf privilege strings above are well-known to Jamf admins but are not currently retrievable from a single public Jamf URL. Verify the strings in your Jamf Pro UI under Settings → User accounts and groups → New account → Privileges tab. Cite: https://developer.jamf.com/jamf-pro/reference and http://learn.jamf.com/r/en-US/jamf-pro-documentation-current/API_Roles_and_Clients .
Optional: force-sync (opt-in). To allow Arrakis to trigger immediate device check-in (recommended for in-flight enforcement), additionally grant: “View MDM command information in Jamf Pro API”. This unlocks POST /api/v2/mdm/commands with commandType: BLANK_PUSH. Cite: https://developer.jamf.com/jamf-pro/reference/post_v2-mdm-commands .
What this credential cannot do. With the role above, Arrakis cannot enroll devices, read FileVault or Recovery keys, run scripts (no Scripts privilege), read user passwords, manage other admin accounts, or alter Jamf settings. Privileges are additive and explicit; anything not granted is denied.
Issuance steps:
- Settings → System → API Roles and Clients → Add.
- Assign the role assembled above → Save.
- New client → bind to the role → Save.
- Record
client_idandclient_secret(secret displays once). - Paste into the Arrakis platform under Settings → Integrations → MDM → Jamf Pro.
Microsoft Intune
Authentication. Microsoft Entra app registration calling Microsoft Graph. The app requests Application permissions (daemon flow) and authenticates via OAuth 2.0 client credentials. Cite: https://learn.microsoft.com/en-us/intune/developer/configure-graph-api-access .
Required Graph application permissions (least privilege).
DeviceManagementConfiguration.ReadWrite.All— required to update assigned configuration profiles and settings catalog policies. Cite: https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-iosgeneraldeviceconfiguration-update .
Optional: force-sync (opt-in). Additionally grant DeviceManagementManagedDevices.PrivilegedOperations.All for POST /deviceManagement/managedDevices/{managedDeviceId}/syncDevice. Cite: https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-syncdevice .
Optional: scope tags. For finer control, combine the Entra app principal with an Intune RBAC role such as “Policy and Profile Manager” plus scope tags so Arrakis can only modify policies in a designated scope.
What this credential cannot do. With only the two permissions above, Arrakis cannot manage Intune scripts (DeviceManagementScripts.ReadWrite.All is required and not granted), apps (DeviceManagementApps.*), enrollment / APNs / ABM / ADE (DeviceManagementServiceConfig.*), RBAC (DeviceManagementRBAC.*), or read user mail/files/directory (User.*, Mail.*, Files.*).
Issuance steps:
- Entra admin center → App registrations → New registration.
- Name the app
arrakis-mdm-policy-writer; leave redirect URI blank. - API permissions → Microsoft Graph → Application permissions.
- Search and add
DeviceManagementConfiguration.ReadWrite.All. - Grant admin consent for the tenant.
- Certificates & secrets → New client secret.
- Record
client_id,tenant_id, and the secret value (displays once). - Paste into the Arrakis platform under Settings → Integrations → MDM → Microsoft Intune.
Iru
Authentication. Iru Endpoint Management API uses tenant-level bearer tokens. Tokens are minted in Settings → Access in the Iru web app and are displayed once. Rate limit: 10,000 requests/hour/tenant. Cite: https://support.kandji.io/api (Iru’s support docs, still hosted on the kandji.io domain at time of writing) and https://api-docs.kandji.io/ (Iru’s API docs, still hosted on the kandji.io domain at time of writing).
Required permissions (least privilege). Iru tokens use an explicit allowlist of (HTTP method, path) pairs. For policy lifecycle:
POST /api/v1/library/custom-profilesPATCH /api/v1/library/custom-profiles/{library_item_id}DELETE /api/v1/library/custom-profiles/{library_item_id}POST /api/v1/blueprints/{blueprint_id}/assign-library-item
Optional: force-sync (opt-in). Add: POST /api/v1/devices/{device_id}/action/blankpush (and/or dailycheckin, updateinventory).
What this token cannot do. With the path allowlist above, Arrakis cannot read device secrets (FileVault key, bypasscode, unlockpin, recoverypassword), delete devices, manage Custom Apps / Custom Scripts / In-House Apps, read audit logs, or manage ADE tokens or users.
Issuance steps:
- Iru web app → Settings → Access → API Token → New token.
- Name the token
arrakis-mdm-policy-writer. - Permissions → check the (method, path) pairs above.
- Generate → record token (displays once).
- Paste into the Arrakis platform under Settings → Integrations → MDM → Iru.
Other MDMs
The same pattern applies to Workspace ONE UEM (OAuth 2.0 client credentials plus role-based admin), Mosyle Business/Manager (access tokens), and Hexnode UEM (API key) — auth via API token or OAuth client, profile CRUD scoped to a group, and an explicit device-action endpoint to force check-in. Confirm the exact role and permission names against the vendor’s current documentation before issuing the credential.
Force-sync capability comparison
| MDM | Force-sync endpoint | Typical latency |
|---|---|---|
| Jamf Pro | POST /api/v2/mdm/commands (commandType BLANK_PUSH) | Seconds to ~1 minute over APNs |
| Microsoft Intune | POST /deviceManagement/managedDevices/{id}/syncDevice | Seconds to minutes; “within 8 hours” worst case per Microsoft general guidance |
| Iru | POST /api/v1/devices/{device_id}/action/blankpush | Seconds to minutes |
All MDM force-sync calls ultimately depend on Apple APNs or Google FCM reaching the device, so latency is bounded by network reachability, not the MDM API itself. None of the major vendors publishes a contractual command-delivery SLA in their public API docs.
Credential rotation
Arrakis rotates tenant-side credentials every 90 days. The Arrakis console surfaces a “rotation due” notice 14 days before the deadline. Rotation procedure: the customer creates the new credential in their MDM, pastes it into Arrakis, then revokes the old credential. The Arrakis platform supports a grace window so policy pushes do not fail mid-rotation.
Drift detection
Arrakis detects out-of-date endpoint config from telemetry the endpoints themselves emit:
app.versionresource attribute below the recommendedminimumVersion→ flagged as outdated client.- Missing OTel resource attributes (e.g.,
team.idnot present) → flagged as missing policy. - Repeated
401 Unauthorizedfrom an endpoint after a token rotation → flagged as stale token.
Pair this with your MDM’s “missing profile” or “policy non-compliant” report to scope remediation: the union of the two surfaces is what needs an MDM force-sync.
Force a sync from the device — cheat sheet
macOS (any MDM with managed configuration profiles):
sudo profiles renew -type=configuration
sudo profiles show -type=configuration # verify the new profile landedWindows (Intune / Group Policy):
dsregcmd /status
gpupdate /force
# Or: Settings → Accounts → Access work or school → SyncJamf Pro device:
sudo jamf policy
sudo jamf recon # update inventoryIru:
- Open Self Service → click Sync, or trigger from the Iru web console.