Skip to content
TokenShift

MDM Rollout

Every MDM rollout has the same three steps:

  1. Install the binary — push a signed artifact (.pkg / .msi / .deb / tarball) from the PointFive installation page.
  2. Drop the enrollment manifest — at the system path so every user on the machine inherits the binding. Generate the manifest in the PointFive app.
  3. Verify — tokenshift doctor reports back.

Paths used below:

  • macOS / Linux system manifest: /etc/tokenshift/enrollment.json
  • Windows system manifest: %PROGRAMDATA%\tokenshift\enrollment.json

See Enrollment for what’s in the manifest and why the per-user path takes precedence when both exist.

Jamf

Section titled “Jamf”

Two policies, scoped to the same smart group:

  1. Install — push the signed TokenShift .pkg (get it from the PointFive installation page and host it in your Jamf distribution point, or stream it via a wrapper script + curl).
  2. Configure — push the enrollment manifest as a file to /etc/tokenshift/enrollment.json (mode 0644, owned by root).

Run tokenshift doctor as a self-service “verify” policy so users (and your support team) can confirm the binding without admin help.

JumpCloud

Section titled “JumpCloud”

JumpCloud Commands work well for both steps:

  1. Push a shell command that installs the binary user-owned — get install-mdm-template.sh (one cross-OS script for macOS + Linux) from the PointFive app (or your PointFive contact) and set TENANT_ID at the top to your tenant UUID before pushing (the script aborts while the YOUR-TENANT-UUID-HERE placeholder is unedited). It resolves the target user, installs to ~/.tokenshift/bin, and wires PATH via ~/.tokenshift/env — nothing under /usr/local/bin. A plain curl | tar -C /usr/local/bin leaves a root-owned binary that can’t self-update.
  2. Push the manifest contents via a second Command that writes /etc/tokenshift/enrollment.json with tee.

Verify with a third Command that runs tokenshift doctor and captures output.

Intune

Section titled “Intune”

Windows-side: package the .msi and assign it to a device group. Manifest goes to %PROGRAMDATA%\tokenshift\enrollment.json — push it via an Intune Win32 app that drops the file in a post-install script, or via a separate configuration profile.

macOS-side: same as Jamf — .pkg install + manifest drop. Intune for Mac runs scripts as root, so writing /etc/tokenshift/enrollment.json is straightforward.

Ansible

Section titled “Ansible”

A playbook does the same steps natively — no install-mdm-template.sh invocation needed: create the user-owned ~/.tokenshift/bin store, download and unpack the tarball into it, wire PATH via a /etc/profile.d drop-in, drop the enrollment manifest to /etc/tokenshift/enrollment.json, then run tokenshift doctor to verify. A ready-to-adapt playbook is available via the PointFive app or your PointFive contact.

Updating the manifest

Section titled “Updating the manifest”

The manifest is read once at session start and cached for the lifetime of the process. Pushing a new manifest takes effect on the next agent session (or the next tokenshift invocation). No restart required for already-running shells beyond the agent itself.

Removing

Section titled “Removing”
Terminal window
# remove the binary store and PATH wiring (run as the user)
rm -rf "$HOME/.tokenshift/bin"
rm -f "$HOME/.tokenshift/env" /usr/local/bin/tokenshift
sudo rm -f /etc/profile.d/tokenshift.sh   # if the Ansible playbook was used
# or msiexec /x …                         # Windows


# remove the system manifest
rm /etc/tokenshift/enrollment.json             # macOS / Linux
del %PROGRAMDATA%\tokenshift\enrollment.json   # Windows

tokenshift uninstall --purge removes hooks and per-user state but never touches the system-deployed manifest — that stays your MDM’s responsibility.

Next

Section titled “Next”