Feature Requests

CyberSight user behavior analytics transformed visibility for Windows deployments—and we want to bring that same capability to macOS. Mac-heavy teams will now have the same depth of user-level visibility across their entire fleet, without gaps in coverage based on operating system. What This Means for You Visibility and user-level activity logs extended to macOS devices Consistent behavioral insight across mixed Windows and Mac environments Faster investigations and incident response without switching between tools

I would like the ability to have a configuration file similar to Windows Roaming Client that allows ability to: Change preferred IP for DNSFilter Ability to utilize DNSSEC Ability to utilize DoT Ability to exclude certain SSIDs (i.e., when connecting to a certain network that is running the relay server)

For schools running Chromebook fleets, meaningful visibility into user activity has been a gap—and CyberSight is how we plan to close it. We're working to bring the same user-level insight available on Windows to the DNSFilter ChromeOS extension, with education teams squarely in mind. What This Means for You Visibility and user-level activity logs extended to Chromebook deployments Deeper insight into student and teacher activity across your fleet Consistent behavioral visibility across mixed-OS environments No additional tools required—everything within DNSFilter

Summary Allow MSP administrators to control whether CyberSight is visible to client-level administrators within sub-organizations. Problem CyberSight provides visibility into user activity and application usage. Some MSP partners allow their clients to administer DNSFilter within their sub-organizations but do not want those client admins to access company-wide analytics that could expose sensitive user activity (e.g., CEO/CFO browsing or application usage). Currently, CyberSight data can only be controlled by enabling or disabling data collection for specific Roaming Clients. There is no option to hide the CyberSight dashboard or restrict access to its analytics for certain administrative roles. Requested Capability Allow MSP administrators to hide or disable the CyberSight dashboard for client-level admins. Provide MSP-level controls to determine which roles can view CyberSight analytics. Maintain CyberSight data collection while restricting visibility when needed. Optionally support role-based permissions (custom roles) to control access to analytics features. Customer Value Allows MSPs to provide dashboard access to clients without exposing sensitive user activity data. Supports privacy and internal policy requirements for organizations with executive or sensitive roles. Provides better role-based control for MSP-managed environments.

It would be ideal to be able to toggle an "auto uninstall" per client and set a policy to remotely delete agent that doesn't check in within 30, 60 or 90 days. Our RMM auto installs DNSFilter so it is an easy re-add if needed. But this would help us keep our counts up to date.

Hello guys, it would be amazing if we could schedule our own update window for the roaming agent update to prevent it rolling out in middle of a work day for our client. Thanks,

We'd like the ability to have domain access requests surfaced in the portal so that we can view them, respond to them via the portal so the user is notified via email on our decision, and a way to easily allow list an item right from that same screen should we decide to go that route.

Feature Request Summary: Respect system editor preferences in Relay Manager ( $EDITOR support) Problem: Relay Manager currently defaults to using nano when editing configuration files. On systems where nano is not installed (common in minimal or hardened environments), this results in a failure to edit the config. Who’s Affected: System administrators running Relay Manager on minimal Linux distributions or environments where default editors (like nano ) are not installed or not desired. Impact & Context: Breaks expected workflows on systems without nano installed Forces admins to install additional packages they may not want Goes against common Linux conventions where tools respect the $EDITOR environment variable Creates friction for users maintaining clean or hardened systems Desired Outcome: Relay Manager respects the $EDITOR environment variable when launching config edits If $EDITOR is not set, optionally fall back to detecting available editors or prompting the user to choose Avoid requiring or installing a specific editor like nano by default This would align Relay Manager with standard Linux tooling behavior and improve compatibility across a wider range of environments.

Some blocked applications generate large amounts of query log entries, creating noise in the logs that makes searching for other blocked sites (that we might want to allow) difficult.

Support for IPV6 on the Roaming Clients