Deploy with Jamf Pro
This deploys the client to macOS through Jamf Pro. Jamf Pro manages Apple platforms only, so if you also run Windows, pair this with Intune, Group Policy, or any other MDM for that half of the fleet. Read Plan your deployment first, and download the package and configuration profile from Devices → Deployment.
Order matters. Scope the configuration profile first, confirm it has landed on a test Mac, then scope the package. If the package arrives first, macOS shows the employee a blocked extension prompt. A profile that lands afterward still approves the extension, no restart needed, but by then the employee has already seen a scary dialog, so keep the order.
1. Upload the configuration profile
The profile from the dashboard already contains the system extension allowlist (which covers the Endpoint Security extension type), content filter, privacy preferences, and managed login item payloads, with your EnrollmentToken, OrgSlug, and API URLs filled in at download. You only edit it to add optional keys.
- Optional: open
merge-workforce-client.mobileconfigin a profile editor such as iMazing Profile Editor to add optional keys likeExpectedIdentityin thecom.merge.workforceclientpreference domain. Edit before uploading: Jamf Pro cannot edit signed uploaded profiles, may modify unsigned ones, and does not render the managed login items payload for editing at all - Computers → Configuration Profiles → Upload, and select
merge-workforce-client.mobileconfig - Scope to your test smart group for now
- Save
Set these values in the preference domain payload:
ExpectedIdentity is an optional hint and is not an identity source. Identity is resolved by Merge from a verified IdP sign-in, so nothing in this file can decide who the employee is. Jamf substitutes the assigned user here, and the client uses it only to raise a mismatch alert if a different employee is resolved on that Mac. The variable is case-sensitive ($EMAIL, not $email) and substitutes only on computers with an assigned user in inventory. Omit it entirely if your Jamf inventory has no reliable email.
Do not hardcode it
A literal email here makes every Mac in scope expect the same employee, so every correctly resolved identity raises a mismatch alert. Use a Jamf variable or leave the key out.
2. Verify the profile landed
On a test Mac:
You should see your token and slug. If you set ExpectedIdentity and it still reads $EMAIL, Jamf had no value to substitute, which is harmless: it only disables the mismatch alert.
3. Upload and deploy the package
- Upload
MergeWorkforceClient-<version>.pkgin Settings → Computer management → Packages. In Jamf Pro 11.4 and later, in-console upload requires a cloud distribution point; with an on-premises file share distribution point, place the package on the share manually - Computers → Policies → New
- General: name it
Merge Workforce desktop client, trigger Recurring check-in, execution frequency Once per computer - Packages: add the package, action Install
- Scope: your test smart group
- Save, then run Recurring check-in on a test Mac with
sudo jamf policy
4. Confirm enrollment
On the test Mac:
The daemon should be loaded and the system extension should show [activated enabled]. Then open Devices in the dashboard: the device appears within a minute, and shows the resolved employee once they complete the one-time sign-in.
5. Scope to the fleet
Create a smart group for the devices you want covered, for example all Macs on macOS 13 or later:
Change the scope on the configuration profile first, wait for it to propagate, then change the scope on the policy. Roll the profile and package out to a small canary smart group before your whole fleet.
Uninstall
Deploy the uninstaller package, or run it locally:
It removes the system extension, both launchd jobs, and the app bundle. Unscope the configuration profile as well, otherwise a later reinstall picks up stale settings.