Deploying macOS Roaming Client using Jamf Pro
This is intended to give an overview of the deployment process as it aligns with DNSFilter. For detailed support and instructions, contact Jamf. (Steps are based on using Jamf Pro 11.1.0)
Instructions
- Download the app package from the Roaming Clients tab under Deployments (you'll have two options)
- Branded DNSFilter macOS Roaming Client [DNSFilter%20Agent-Installer.pkg]
- WhiteLabel MSP macOS Roaming Client [DNS%20Agent-Installer.pkg]
- Upload the app package to Jamf Pro
-
Create a script that you will add to Jamf Pro that adds your site key
#!/bin/sh cd /tmp && echo "Your SITE KEY here" > dns_agent_site_key && sudo installer -dumplog -pkg DNSFilter%20Agent-Installer.pkg -target /
- Add the script to Jamf Pro
- If you have not done so already, create a Jamf Smart Group to target specific macOS devices for installation
- Create a Jamf Policy by adding the macOS Roaming Client package to the policy, and setting the scope to the Smart Group that you created for your macOS devices
The next time macOS endpoints in the Smart Group that are scoped to the policy check in with Jamf Pro and meet the trigger in the General payload, the policy will run and deploy the macOS Roaming Client to the endpoint.
-
Official comment
With the release of version 2.0.0 of the macOS Roaming Client (currently in Beta), the way to install the agent is updating, which could mean some adjustments to how to deploy with RMM tools.
One of our customers shared this adjustment that worked for them using Jamf to install the branded proxy version: let us know in the comments if this works for you too!
Create two payloads in Jamf:
DNS Proxy
App Bundle ID: com.dnsfilter.agent.macos.DNSProxy
Provider Bundle ID: This is the ID assigned to DNSFilter by Apple, not the extension identifier (in Jamf, the extension identifier is labeled App Bundle ID)
System ExtensionsPayload 1:
Display name: com.dnsfilter.agent.macos.DNSProxy
System extension types: Non-removable system extensions from UI
Team identifier: Y53…
Non-removable system extensions from UI
com.dnsfilter.agent.macos.DNSProxyPayload 2:
Display name: com.dnsfilter.agent.macos.DNSProxy
System extension types: Allowed system extensions
Team identifier: Y53…
Allowed System Extensions
com.dnsfilter.agent.macos.DNSProxy -
Hi, after the upgrade to macOS Sequoia (15.1) we are having the issue that we cannot install it silently via Jamf Deployment anymore.
We were using the same command as above, with the “-store” argument, and we removed that argument now as I understood from other posts here that this was causing the installation to fail on Sequoia.
Sadly now the installation is no longer silent and we get two consecutive prompts for admin credentials for making changes to the System Certificate Trust Settings (screenshot below).
This is obviously not ideal, considering that our users do not have admin rights on their macs, and would mean we have to update this manually on every computer to put the admin credentials for these prompts.
Is there something we are missing or is there a fix for this coming?
2 -
Hi Emanuel Stoi, this currently is a known issue with macOS Sequoia, where the system requires an admin prompt to associate the certificate during installation due to new security settings in Apple's environment. We are actively working on alternative methods to allow for silent deployment of the certificate using RMM/MDM tools, however updates will require manual credential input for installation until this is resolved.
Any changes that are made including this current obstacle, are posted in our changelog. We are actively investigating this issue and hope to reach a solution very soon.
We will be sure to highlight this in additional deployment instructions until it is resolved for clearer instruction!
0 -
Bailey Taylor Has there been a resolution for this? We are also running into the same issue where installation is failing. This is on the RC version 1.8.6 on any mac OS device on 15.1 and above.
2 -
Hi Shehzad Khan Thanks for reaching out! We’d love to help troubleshoot this issue. Just to clarify, when you say "the same issue where installation is failing," do you mean the installation requires end-user approval (and isn’t a fully silent install), or is the installation failing outright with errors on macOS Sequoia devices?
If it's the former, know that our engineering team is actively working on alternative methods to allow for silent deployment via RMM/MDM tools. Until a solution is in place, updates will require manual credential input for installation.
We’re tracking this closely, and any updates—including a resolution for this deployment challenge—will be posted in our changelog.
If it’s the latter, can you provide us some details on what that failure looks like (what is the error message, is it coming from Jamf, DNSFilter, or Apple, etc.), and if possible could you run the following command on a device where the failure occurs and share the results? This will help us pinpoint the issue:
cp /var/log/install.log ~/DesktopThis will copy the install log to your desktop, which can provide insight into what's happening. Let us know what you find, and we’ll do our best to assist!
0 -
Hi, we're also running into the approval problem when installing via Jamf but have a workaround.
I want to preface this by saying we shouldn't have to do this, and it can be an easy fix for a next release by changing the postinstall logic.
What we've done is:
- Download the installer pkg file
- Expand the pkg file into a directory using
pkgutil --expand - In the directory, locate the 2 certificates which require installation
- Deploy the certificates to devices using a Configuration Profile, which will take care of installing them and trusting them on the devices
- Back in the expanded pkg directory, find the
postinstallscript and comment out theinstallCertsmethod. - Flatten the expanded directory back into a pkg file using
pkgutil --flatten - Deploy the edited pkg via Jamf
This method will stop the process trying to install and trust the certificates, avoiding the prompt for admin elevation.
I know the pkg will be unsigned like this but you can still sign it yourself, however it's not an issue in my opinion as you know where the original came from before editing it.
We also found that the installation script wouldn't work by putting the pkg into a policy and setting it to install, we had to cache it and then copy out of the waiting room into the
/tmpdirectory to carry out the installation. This appears to be a problem because the installation scripts within the pkg are expecting thedns_agent_site_keyto be in the same directory path as the pkg file. This is what we did:#!/bin/bash #cd /tmp && echo "$4" > dns_agent_site_key && sudo installer -dumplog -pkg DNSFilter\ Agent-Installer.pkg -target / cp /Library/Application\ Support/JAMF/Waiting\ Room/DNSFilter\ Agent-Installer.pkg /private/tmp cd /private/tmp && echo "$4" > dns_agent_site_key && sudo installer -dumplog -pkg DNSFilter\ Agent-Installer.pkg -target /I hope this helps others looking to deploy via Jamf.
3 -
This is also affecting us and is becoming a real frustration. I'm assuming the change Apple made was limiting the functionality of installing certificate silently to only be allowed via a configuration profile (MDM) and not an admin account.
If that's the case, please just update the documentation saying it can no longer be done without configuration profiles and pre-loading of certificates.
1 -
Sean Kearney , thanks for the feedback. We see our Support team has already provided you an update about our engineer's progress, and our documentation will change when the release happens.
In the meantime, we hope the workarounds other customers posted above are helpful, and please add to the conversation if you've found other useful tips!
0
Please sign in to leave a comment.
Comments
8 comments