MDM integrations

Any endpoint-management platform can deploy agentdesktop if it satisfies the machine-level contract below. The Microsoft Intune runbook covers macOS and Windows in detail; this page maps the same work to Jamf Pro, Kandji, and Fleet.

These mappings assume your organization uses the signed endpoint installers from a reviewed agentdesktop release, verifies their checksums and platform signatures, and validates them on representative devices before assignment. Do not substitute an unsigned local development package for a production rollout.

Deployment contract

Keep the MDM payload small. It installs the application, writes the controller bootstrap and optional trust root, restarts the service only when configuration changes, and reports whether the service is healthy. Gateway settings and developer-tool policy still come from the agentdesktop controller.

The bootstrap and controller CA certificate are not secrets. Never distribute the device CA key, controller TLS key, gateway signing key, database URL, upstream provider credentials, or other secrets through an MDM payload.

Use these local checks to confirm that the package, service, and daemon API are present. Verify enrollment, controller connectivity, and remote configuration separately in the Agent Desktop UI and controller management UI during each rollout ring.

Platform comparison

Use separate pilot and rollout groups in every platform. Scope x64 and ARM64 packages so a device can match only one architecture-specific installer.

Workspace ONE UEM, JumpCloud, and Mosyle can likely satisfy the same contract, but these mappings have not been tested. Validate installer context, file permissions, restart behavior, architecture targeting, and detection semantics before publishing a copy-paste runbook.

Jamf Pro

Jamf Pro deploys agentdesktop to Macs through a package, computer policy, script payload, and extension attribute.

1. Upload the signed and notarized Agent Desktop PKG as a Jamf package.
2. Add the PKG to a computer policy scoped first to a static or smart pilot group.
3. Add an idempotent script payload that writes /etc/agentdesktop/config.yaml and the optional controller CA, fixes owner and mode, and restarts dev.agentdesktop.daemon only when content changes.
4. Add a scripted extension attribute that checks the package receipt, LaunchDaemon, and local status command. Update inventory after the policy runs.
5. Build a smart group from that extension-attribute value for local compliance reporting. Its result is only as current as the last inventory update.
6. Expand policy scope only after the Agent Desktop and controller UIs also show healthy enrollment and applied configuration for the pilot.

The PKG preserves a bootstrap file that arrives first, so package and bootstrap delivery can occur in either order. Adapt the macOS script from the Intune runbook; Jamf supplies the assignment and reporting mechanism.

Jamf Pro is Apple-focused. A mixed Jamf and Windows environment still needs Intune, Fleet, Workspace ONE, or another Windows-capable endpoint platform for the MSI.

Kandji

Kandji deploys agentdesktop through a Custom App and enforces its bootstrap through a separate Custom Script:

1. Create a Custom App with the signed PKG and assign it to a pilot Blueprint.
2. Select Audit and enforce and use an audit script to check the package version and local daemon health. A failed audit prompts Kandji to reinstall the Custom App.
3. Create a separate Custom Script for bootstrap configuration. Kandji custom scripts run as root and can run once, every check-in, daily, or from Self Service.
4. Use the script’s audit and remediation fields so an incorrect configuration hash triggers a rewrite and daemon restart, while a current file exits without changing the device.
5. Select Run every 15 min or Run daily when ongoing drift remediation is required. Install once per device does not continue checking after a successful run.
6. Monitor Remediated and Alert Custom Script states, plus Custom App status, before assigning the Library Items to later Blueprints.

Kandji supports PKG pre-install and post-install scripts, but keeping tenant bootstrap in a separate Custom Script lets operators rotate the controller URL or private CA without rebuilding the application item. See Kandji’s Custom Scripts overview for root execution, frequencies, remediation, and status behavior.

Pair Kandji with Intune, Fleet, Workspace ONE, or another Windows-capable platform when the fleet also includes Windows devices.

Fleet

Fleet deploys agentdesktop across macOS and Windows with custom packages, osquery policies, labels, and API or GitOps automation.

1. Add the macOS PKG and Windows MSI as custom packages in the target fleet.
2. Use package targets or labels to separate macOS Intel, macOS Apple silicon, Windows x64, and Windows ARM64.
3. Put bootstrap installation, ACL or mode enforcement, and service restart in each package’s post-install script. Treat any nonzero post-install result as destructive: Fleet marks installation failed and attempts to uninstall the software. Keep controller-dependent health checks in a separate policy so a transient network failure cannot trigger rollback.
4. Detect installation with an osquery policy that checks package metadata, expected version, configuration hash, and running service.
5. Attach the package to a policy automation for required installation, or expose it through Fleet’s software library for a controlled pilot.
6. Manage package definitions and policy automation through Fleet’s REST API or GitOps when those workflows are already part of platform operations.

Before uploading packages, enable scripts in fleetd with --enable-scripts; Fleet MDM enables them automatically on managed Macs. A self-hosted Fleet deployment also needs S3-compatible installer storage, and Fleet recommends at least five-minute load-balancer timeouts for package upload endpoints.

Fleet supports Agent Desktop’s relevant .pkg, .msi, .sh, and .ps1 artifacts, along with .exe, .deb, .rpm, .ipa, .tar.gz, and .py packages. Script-only packages are useful for manual bootstrap repair, but Fleet does not automatically install script-only packages; use policy automation to run a script when automatic remediation is required.

By default, software policy automation triggers on the first failure or a pass-to-fail transition and stops after three installation attempts. It does not continuously retrigger while a policy remains failed. Continuous fail-to-fail automation requires continuous_automations_enabled, a Fleet Premium feature, and must be guarded against retry loops.

Fleet can provide Apple MDM and Windows MDM. Apple Business automatic enrollment, automatic Windows enrollment, and software deployment are Fleet Premium capabilities. Fleet documents an Enterprise Mobility + Security E3 license for the administrator configuring Windows automatic enrollment and at least Microsoft Entra ID P1 for each enrolling user; Microsoft 365 E3 or E5 satisfies the user requirement.

Fleet labels do not apply during setup experience: when several packages represent the same software, Fleet installs the package added first. Avoid architecture-specific setup-experience installation unless the first package is valid for every target; otherwise install after enrollment when label targeting applies.

Fleet can target Linux hosts, but the agentdesktop repository does not yet include a production Linux package or systemd unit. Build and support that packaging layer before presenting Linux deployment as production-ready.