Managed deployment on macOS

Push the macOS observer to a fleet through your MDM or RMM, with each Mac attributed to the person using it.

Push the macOS observer to a fleet with no employee interaction. There is no password prompt, no browser sign-in, and no per-machine key. You push one .pkg and one configuration profile, and each Mac joins this workspace attributed to the person using it.

Import or sync your roster first. Owner attribution matches each Mac against the people in this workspace. If the roster is empty, or the address a Mac reports is not on it, that Mac enrolls unattributed. It still captures, but its cost and activity are assigned to nobody until an admin picks an owner by hand. A 300-Mac rollout onto an empty roster produces 300 unattributed devices.

Before you start

Step 1: Generate an enrollment token

Create one in the Enrollment tokens block on the Devices settings page. One token covers the whole fleet.

Step 2: Get the macOS package

Download Proxon-<version>.pkg from Install. That page serves the build for this environment, so take the .pkg from there rather than reusing a download link from another environment.

Step 3: Deliver the token to each Mac

Deliver it through the configuration profile, or through a file your RMM writes. The next section covers both.

What you deploy:

Proxon-<version>.pkg, pushed by MDM or RMM. It installs Proxon.app, the browser-policy support files, and the CA-trust helper.
proxon.mobileconfig, MDM only. It pre-approves the system extension, the privacy permissions, and the browser extension, and it carries the enrollment token.
/Library/Application Support/Proxon/enrollment.json, written by an RMM script instead of the profile's token payload, when you have no MDM profile channel.

You need the enrollment token exactly once, in exactly one of the last two places. Everything else is fixed content.

Deliver the enrollment token

There are three paths. Pick whichever your tooling supports. The key names are identical in all of them, and the MDM profile wins if you somehow use more than one.

Path A: MDM managed preferences (preferred)

Copy proxon.mobileconfig.template to proxon.mobileconfig and, in the Proxon managed-settings payload, replace the literal @@PROXON_ENROLLMENT_TOKEN@@ with your token. The template itself is never uploadable. The copy is what you sign and upload. The payload sets these keys in the com.proxon.observer domain, and they are the whole vocabulary, since the app ignores anything else.

Key	Detail
`enrollment_token`	Required. Your shared, workspace-wide enrollment token, starting with `prx_ent_`. One token covers the whole fleet.
`user_email`	Optional. Attribute this Mac to a specific person. See Owner attribution below for the per-MDM variable that makes one profile cover the fleet.

xml

<key>com.proxon.observer</key>
<dict>
    <key>Forced</key>
    <array>
        <dict>
            <key>mcx_preference_settings</key>
            <dict>
                <key>enrollment_token</key>
                <string>prx_ent_ab12_REPLACEME</string>
                <key>user_email</key>
                <string>$EMAIL</string>
            </dict>
        </dict>
    </array>
</dict>

A profile is used rather than a plain preference file because macOS marks values delivered by a profile as forced, and Proxon ignores anything unforced. Without that, any process running as the employee could write a user_email into the same domain and quietly attribute the Mac to a colleague.

Path B: enrollment.json written by an RMM script

If your tool can push software and run scripts but cannot push an Apple configuration profile, which is the common case with NinjaOne, write the file directly. Run this as root before or after the .pkg, since the app reads it at first launch, not at install time. Omit any optional key you are not setting rather than leaving it empty.

bash

#!/bin/bash
set -euo pipefail

install -d -o root -g wheel -m 755 "/Library/Application Support/Proxon"

cat > "/Library/Application Support/Proxon/enrollment.json" <<'JSON'
{
  "enrollment_token": "prx_ent_ab12_REPLACEME",
  "user_email": "ada@acme.example"
}
JSON

chown root:wheel "/Library/Application Support/Proxon/enrollment.json"
chmod 644        "/Library/Application Support/Proxon/enrollment.json"

Use 0644, not 0600. Root writes this file, but the Proxon app that reads it runs as the employee. The token inside is a shared workspace secret that is bounded by use count, rate-limited, and revocable from the Enrollment tokens block. It is not a per-user credential. The per-device credential it mints lives in the macOS Keychain, not here.

Path C: environment variables to the installer

If your RMM runs installer from a script, pass the same values as PROXON_ENROLLMENT_TOKEN and PROXON_USER_EMAIL and let the package's postinstall write the file for you. With no token set, the installer writes nothing and the Mac behaves exactly like a self-serve install.

bash

#!/bin/bash
set -euo pipefail

export PROXON_ENROLLMENT_TOKEN="prx_ent_ab12_REPLACEME"
export PROXON_USER_EMAIL="ada@acme.example"      # optional

/usr/sbin/installer -pkg /path/to/Proxon-1.2.3.pkg -target /

The token never appears in installer output or Proxon's logs. It does appear in whatever your RMM records about the script it ran, so restrict who can read that job, and rotate the token from the Enrollment tokens block if that changes.

What the profile pre-approves

Each payload removes one approval dialog the employee would otherwise have to click:

System extension: allow-lists Proxon's network-capture extension by Team ID (4JDW2S2CK4) and bundle id, so it loads without the System Extension Blocked prompt.
Privacy permissions (PPPC): pre-grants Input Monitoring (click and keystroke counts only), Accessibility (foreground window title), and Calendar (meeting counts only) to com.proxon.observer.
Browser extension: force-installs the Proxon extension on managed Chrome, Edge, and Firefox. Safari is separate, and is covered under Browsers below.
Proxon managed settings: the enrollment token and optional user_email from Path A.
Certificate: optional and empty by default. It is not how Proxon's traffic-inspection certificate gets trusted. That certificate is generated on each Mac at first run, and a small privileged helper the .pkg installs trusts it with no password prompt, but only on a Mac that is both MDM-enrolled and carrying Proxon managed configuration. Delete this payload unless you run your own PKI and want an extra root pre-trusted.

Sign the profile

macOS accepts an unsigned profile but flags it Unverified, and some MDMs refuse to upload one. First check the filled-in copy. The gate script ships beside the profile template and exits non-zero while the token is still the @@PROXON_ENROLLMENT_TOKEN@@ placeholder, so you cannot push a template to 300 Macs.

bash

./check-profile-ready.sh proxon.mobileconfig

Then sign it with your Developer ID Installer certificate, and upload proxon-signed.mobileconfig.

bash

security cms -S -N "Developer ID Installer: Your Org (4JDW2S2CK4)" -i proxon.mobileconfig -o proxon-signed.mobileconfig

Deploy with your MDM

Jamf Pro

Package. Upload the .pkg to your distribution point under Settings, Computer Management, Packages, then create a policy with a Packages payload that installs it, scoped to your Mac smart group.
Profile. Go to Computers, Configuration Profiles, New, Upload, and select proxon-signed.mobileconfig. Jamf reads every payload from the file, so you do not rebuild them in the Jamf UI.
Attribution. Jamf expands $EMAIL from the assigned user's record, so leaving user_email as $EMAIL attributes each Mac to its own user. A Mac with no assigned user gets an empty value and falls through to the directory record.
Order. Scope the profile to land before or with the package. The app reads managed configuration at first launch, so a profile that lands after the .pkg still works on the next launch, but that first launch will have shown the employee the ordinary onboarding screen.

Intune

App. Go to Apps, macOS, Add, then macOS app (PKG). Upload the .pkg, which Intune requires to carry a Developer ID Installer signature, which Proxon's does, and assign it as Required to your device group.
Profile. Go to Devices, macOS, Configuration profiles, Create profile, Templates, Custom. Upload proxon-signed.mobileconfig.
Attribution. Set user_email to {{userprincipalname}}. That is the Entra ID UPN, which is not always the person's email. If your UPNs differ from your mail addresses, leave user_email out and rely on the directory record, or set it from a script.

Intune's custom-profile upload is strict about payload schemas. If it rejects the file, split the profile and upload the payloads separately to find the one it objects to, and tell us which. See Known limits below.

Kandji

Upload the .pkg as a Custom App and proxon-signed.mobileconfig as a Custom Profile. Kandji expands $EMAIL, so the managed-settings payload works unmodified.

NinjaOne

NinjaOne is RMM-first, not an Apple MDM, and that decides what it can do here. It can push the .pkg and deliver the token. Run a Bash script like this, or write enrollment.json directly, as in Path B above.

bash

#!/bin/bash
set -euo pipefail
export PROXON_ENROLLMENT_TOKEN="prx_ent_ab12_REPLACEME"
# NinjaOne custom field, expanded by the agent before the script runs:
export PROXON_USER_EMAIL="$(/opt/NinjaRMMAgent/programdata/ninjarmm-cli get userEmail || true)"
/usr/sbin/installer -pkg "$1" -target /

Adjust the custom-field lookup to whatever your Ninja instance uses. The point is that PROXON_USER_EMAIL comes from a per-device field, so one script covers the fleet.

What NinjaOne alone cannot do is grant the system-extension allow-list and the privacy permissions, since those need a real Apple MDM and no script can grant them. A Mac has exactly one MDM of record, so if your Macs are enrolled with Jamf, Kandji, or Intune, push the profile from that MDM and use NinjaOne only for the .pkg and the token. If your Macs have no MDM at all, each employee still approves the system extension and the privacy permissions once, and the CA-trust helper declines by design, so they also see the certificate-trust password prompt once. Enrollment is the part NinjaOne can automate.

Owner attribution

Proxon resolves the owner of each Mac in this order, stopping at the first hit:

user_email from managed configuration. This always wins, and it is what lets one fleet-wide profile attribute every Mac correctly.
The console user's directory record, meaning the logged-in user's email from Open Directory, including the local node and any directory the Mac is bound to, such as Platform SSO.
Unattributed, if neither produces a plausible email address.

A bare short username like ada is never promoted to an address, since attributing a Mac to the wrong person is worse than leaving it unassigned. You can assign an owner to any unattributed device from the Enrolled devices list at any time, and nothing needs re-installing. Either way the address has to be on your roster. One that is not is the same outcome as no address at all.

Set user_email to your MDM's per-device variable so one profile covers the whole fleet:

MDM	Value
Jamf Pro	`$EMAIL`
Kandji	`$EMAIL`
Intune	`{{userprincipalname}}`
NinjaOne	a custom field, expanded by your deployment script

If your MDM does not expand variables in a custom-settings payload, leave user_email out entirely and rely on the directory record.

Browsers

The extension is the same on every browser. Only the way it gets switched on differs. If you push the profile, Chrome, Edge, and Firefox are done. Without a profile, the .pkg sets up Firefox only. Chrome and Edge treat an extension policy as binding only when it arrives from a configuration profile, and there is no privileged script that gets around that. On a fleet with no MDM, install the signed profile by hand on each Mac, or let the employee add the extension once, which the Proxon app walks them through.

Safari cannot be managed by a configuration profile at all. It needs declarative device management, which means macOS 15 or later, a supervised Mac, and an MDM that supports declarations. If your fleet meets all three, push this declaration after the .pkg, since the extension only becomes manageable once Proxon.app is on the Mac. Most MDMs present it as a form, and the values are what matter.

json

{
  "Type": "com.apple.configuration.safari.extensions.settings",
  "Identifier": "generate-a-uuid-here",
  "Payload": {
    "ManagedExtensions": {
      "com.proxon.observer.SafariWebExtension (4JDW2S2CK4)": {
        "State": "AlwaysOn"
      }
    }
  }
}

com.proxon.observer.SafariWebExtension (4JDW2S2CK4) is the extension's bundle id followed by Proxon's Team ID, and Apple requires that exact spelling. AlwaysOn stops the employee turning it off. Use Allowed to leave that to them. If the fleet does not meet all three conditions, the employee ticks Proxon under Safari, Settings, Extensions, and the app links them straight to that pane.

Verify

On a target Mac, after the install and the profile have both landed, run these checks.

Is the profile installed?

bash

profiles list -type configuration | grep -i proxon

Did the managed settings arrive?

bash

defaults read com.proxon.observer 2>/dev/null

Or, if you used the file path:

bash

ls -l "/Library/Application Support/Proxon/enrollment.json"

Expect -rw-r--r-- owned by root wheel.

Is the CA-trust helper registered?

bash

launchctl print system/com.proxon.ca-trust-helper 2>&1 | head -5

Then confirm the device appears in the Enrolled devices list, with the owner you expect rather than Unattributed. Remember that enrollment happens at the app's first launch, not during the install.

Uninstall

bash

sudo "/Library/Application Support/Proxon/uninstall.sh"

This removes the browser policy entries, the login agent, the CA-trust helper and its LaunchDaemon, the system trust setting the helper wrote, and the managed enrollment config. It deliberately leaves Proxon.app in /Applications, so drag it to the Trash to finish. Remove the configuration profile from your MDM separately.

Known limits

The profile's payload schema has not yet been validated against a live MDM upload. If your MDM rejects a payload or silently ignores a key, that is a bug on our side, so send us the error text.
A Mac has one MDM of record. Proxon's profile has to come from whichever MDM already owns your Macs.
The .pkg cannot grant the system extension or the privacy permissions on its own. Only an MDM profile can, and without one, each employee approves those once.
The CA-trust helper needs both MDM enrollment and Proxon managed configuration. On any other Mac it declines, and the employee is asked for a password once.
Enrollment happens at the app's first launch, not during the install. A DEP or Setup Assistant install has no logged-in user to attribute the Mac to, so Proxon waits.
A Mac that already holds a Proxon credential never re-enrolls. Re-pushing the .pkg or the profile will not move an already-enrolled Mac to a different workspace.
Without a configuration profile, only Firefox can be set up automatically. Chrome and Edge accept an extension policy only from a profile, and Safari needs declarative device management on a supervised macOS 15 or later Mac.
Firefox's policy does not survive a Firefox self-update, because Mozilla keeps it inside the Firefox app bundle. Re-running the .pkg restores it, and the profile avoids the problem entirely.