Skip to main content

Pre-install XFA with any other system

XFA is not tied to a particular management system. Anything that can install a package and either pass an MSI property or run a command as the signed-in user can deploy it. Pre-installation is an Enterprise feature.

Windows

Pass the enrollment token as an MSI property:

msiexec /i XFA.msi /qn ENROLLMENT_TOKEN=<your-enrollment-token>

ENROLLMENT_TOKEN is a public property, so it works from any tool that runs msiexec, and it does not change the installer's signature. Add EMAIL=person@example.com only when installing on a single device: it sets one address, so in a fleet deployment every device would enrol as that person. Across a fleet, XFA reads the address per device from Active Directory. Install for the signed-in user; XFA is a per-user application.

The install fails if enrollment fails. Through msiexec that is a generic installer error, not XFA's own code: the reason (2 for a rejected token, 3 when XFA could not be reached) is in %TEMP%\xfa\xfa-enrollment.log. Install first and enroll separately (below) to get the code back directly.

macOS

Install XFA.pkg for the signed-in user, and supply the token in one of two ways:

  • a configuration profile with the preference domain com.xfa.desktop and the key EnrollmentToken; or
  • the file /Library/Application Support/XFA/enrollment-token, containing only the token. XFA reads it only when it is owned by root and not writable by anyone else (mode 644), which is what a policy running as root writes anyway. This file decides which organization the Mac joins, so one that fails those checks is ignored.

XFA reads whichever is present when it starts, and enrolls the signed-in user. The profile takes precedence.

If enrollment fails, the reason is written to /tmp/xfa/xfa-enrollment.log on the Mac.

Install first, enroll separately

If your tool installs packages and runs commands as separate steps, enroll with:

xfa enroll --token <your-enrollment-token>

Run it as the signed-in user, because credentials are stored in that user's keychain or Credential Manager. Add --email <address> when the account's own address is not the right one.

Running it again is safe and costs no request: XFA recognises the token and checks the affiliation locally.

xfa is at %LOCALAPPDATA%\XFA\xfa-backend.exe on Windows and /Applications/XFA.app/Contents/MacOS/xfa on macOS.

Wait for XFA on Windows

XFA is a windowed application, so no command prompt appears on the user's screen while it works. As a result a shell does not wait for it, never receives its exit code, and has no console to read. Start it and wait:

$run = Start-Process "$env:LOCALAPPDATA\XFA\xfa-backend.exe" -Wait -PassThru `
  -ArgumentList 'enroll', '--token', '<your-enrollment-token>'
$run.ExitCode

Running it directly instead returns at once with no output and no exit code, which reads as success whatever happened. Anything that branches on the result (a deployment step, a detection rule, a compliance check) has to wait for the process.

The reason for a failure is written to %TEMP%\xfa\xfa-enrollment.log, with the command and the time on each run. The enrollment token is never written there.

Check the result

xfa enrollment-status

Exit code 0 means the device is enrolled, 10 means it is not. Add --organization-id <id> to ask about one organization. It reads the local device credentials, so it needs no network and no administrator rights, which makes it usable as a detection or compliance check.

On Windows, run it the same way as above. A detection rule that does not wait for the process reads whatever exit code came before it, and reports compliance it never measured.