Managed deployment guides

Outcome

The administrator documentation provides exact deployment settings for Microsoft Intune, Microsoft Configuration Manager, and Jamf Pro.

The native desktop repository owns the packages and publishes them at stable URLs through distribution.xfa.tech. This repository links to those artifacts instead of maintaining duplicates.

Decisions

XFA is deployed per user.
An MDM is optional. Self-installation through Awareness or Enforcement remains the normal low-friction path, while these guides cover hands-off rollout and existing managed fleets.
Deployment is the package plus the token as a variable, not a wrapper script. The artifact the customer stages is the artifact that runs, nothing is downloaded at install time, and any tool that can run msiexec or push a profile can deploy XFA. This is also how comparable agents are deployed, so the steps are already familiar.
Windows passes the token as the public MSI property ENROLLMENT_TOKEN. Intune therefore uses a line-of-business app: no Content Prep Tool, no detection rule, and no install-behaviour setting, because Intune reads all of that from the package. Intune allows exactly one command-line argument, so the token is the only property.
One MSI serves both architectures. XFA.msi runs on ARM64 under emulation and the updater replaces it with the native build. XFA-arm64.msi is documented only for administrators who want native immediately.
Configuration Manager uses a Windows Installer deployment type with the same property, installed for a signed-in user and deployed to a user collection.
macOS carries the token in a configuration profile (com.xfa.desktop, EnrollmentToken), read by the client at startup, with a token file as a second source. Jamf therefore deploys a package and a profile, with no script and nothing running as root that should run as the user.
A rejected token fails the Windows install, so the MDM reports a failure rather than a device that installed without joining the organization.
A fifth page covers any other system, because the premise is that the commands above are enough on their own.
No MDM provides the assigned user's email address. The client resolves it from the signed-in account and accepts --email as an override; this lives in the client so there is one implementation and one error message.
No wrapper scripts ship. The desktop packages read the token from an MSI property (Windows) or a configuration profile / token file (macOS), so any tool that installs a package and passes a property or pushes a profile can deploy XFA without a script to review.
Offboarding is xfa unenroll --organization-id <id>, run as the signed-in user, which removes one organization and keeps any other. The shared application is removed with a normal uninstall only once xfa enrollment-status reports that no affiliation remains.

Acceptance criteria

Each supported system has a standalone guide with exact settings.
The guides link the packages published by the native desktop repository; no scripts are published or required.
Windows architecture selection is explained, and the publisher identities administrators can pin are documented.
Windows detection distinguishes enrollment from installation. The default MSI detection reports installation only; xfa enrollment-status --organization-id <id> is documented for organization-specific detection but is not yet the default in the guides.
Jamf root execution, user ownership, keychain access, and automatic updates are explained; the Login trigger avoids the login-window case.
Email availability and overrides are described without claiming the MDM supplies a variable it does not provide.
Windows offboarding removes one organization with xfa unenroll --organization-id; conditional removal of the application via xfa enrollment-status is documented but not automated.
End-to-end enrollment against the live service is still outstanding in the desktop implementation.