Skip to Content
DeploymentMDM Sync & Change Management

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

MDMDefault check-in intervalWhat triggers re-evaluationForce-sync command
Jamf Pro15-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 commandFrom 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-inPolicy refresh runs at the check-in cadence; Settings catalog changes propagate at the next refreshCompany 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-inLibrary items are continuously enforced — missing files and modified plists are re-applied automaticallySelf Service app → Sync; from terminal consult Iru’s current CLI docs for the equivalent force-run flag (Confirm against vendor docs)
Generic / other MDMsVendor-specific (Workspace ONE, Mosyle, Hexnode typically 15–60 min — Confirm against vendor docs)Refer to vendor docsVendor-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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. Customer creates an API credential in their MDM, scoped to the operations Arrakis needs (and nothing else).
  2. Customer pastes the credential into the Arrakis platform under Settings → Integrations → MDM.
  3. 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.
  4. 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:

  1. Settings → System → API Roles and Clients → Add.
  2. Assign the role assembled above → Save.
  3. New client → bind to the role → Save.
  4. Record client_id and client_secret (secret displays once).
  5. 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).

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:

  1. Entra admin center → App registrations → New registration.
  2. Name the app arrakis-mdm-policy-writer; leave redirect URI blank.
  3. API permissions → Microsoft Graph → Application permissions.
  4. Search and add DeviceManagementConfiguration.ReadWrite.All.
  5. Grant admin consent for the tenant.
  6. Certificates & secrets → New client secret.
  7. Record client_id, tenant_id, and the secret value (displays once).
  8. 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-profiles
  • PATCH /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:

  1. Iru web app → Settings → Access → API Token → New token.
  2. Name the token arrakis-mdm-policy-writer.
  3. Permissions → check the (method, path) pairs above.
  4. Generate → record token (displays once).
  5. 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

MDMForce-sync endpointTypical latency
Jamf ProPOST /api/v2/mdm/commands (commandType BLANK_PUSH)Seconds to ~1 minute over APNs
Microsoft IntunePOST /deviceManagement/managedDevices/{id}/syncDeviceSeconds to minutes; “within 8 hours” worst case per Microsoft general guidance
IruPOST /api/v1/devices/{device_id}/action/blankpushSeconds 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.version resource attribute below the recommended minimumVersion → flagged as outdated client.
  • Missing OTel resource attributes (e.g., team.id not present) → flagged as missing policy.
  • Repeated 401 Unauthorized from 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 landed

Windows (Intune / Group Policy):

dsregcmd /status gpupdate /force # Or: Settings → Accounts → Access work or school → Sync

Jamf Pro device:

sudo jamf policy sudo jamf recon # update inventory

Iru:

  • Open Self Service → click Sync, or trigger from the Iru web console.

Cross-references

Last updated on