Couple things that DNSFilter could do - that similar vendors do without complaint.

1) Provide a DNSFilter authored & maintained DRMM 'install component'; we rolled our own, and it works well enough - but folks like Huntress and AutoElevate publish & maintain their own component code.

2) Move away from excessively laborious customer level 'roaming client' 'site secret keys'. This would have been better implemented as an account level key (so we only have one key to manage globally) and then we feed the customer name (& optionally 'site name') via installer variables.

Oh, and of course - a sane 'dnsfilter side' delete-agent behavior would go a long way as well. Nothing like having to reduce security stance weeks ahead of an offboard b/c that's the only way to ensure we have your software removed so we don't look like messy chumps to those taking over the customer.

I know this is an old thread but incase anyone wanted the mac version

#!/bin/bash

echo "$DNSfilter" > dns_agent_site_key && sudo installer -dumplog -store -pkg DNS_Agent-Installer.pkg -target /

DNSFilter is the site variable so it pulls the right client

then just upload the pkg file to the component

It would be very useful to have an integration where we can temporarily disable DNSfilter a specific device and also the ability to whitelist and submit a URL for recatgorisation from within dRMM to reduce the need to go to DNSfilter.

msiexec /qn /i DNS_Agent_Setup.msi NKEY="%CS_PROFILE_NAME%" CS_PROFILE_NAME is the site variable, the value returned is very useful. Set the key here, if you have the permission level, and call to it when delivering the x86/x64 install.

The agent? That is quite easy to do. Use this code. You can change the %sitekey% variable to your own key or in Datto RMM create a runtime variable that prompts for the site key to use.

msiexec /qn /i DNS_Agent_Setup.msi NKEY="%sitekey%" TRAYICON="disabled"