Another bump for this. Even if it requires editing the config file through a dialog in the console in a similar way to how SentinelOne handles non-GUI config changes to local policy that would be a huge improvement over needing to make individual changes per-endpoint or kludge together a solution with RMM scripts or config file pushes.

Yes x 1000.

I've been telling this to DNSF for over a year now. You have an agent running on the device with local admin privs connected to a centrally managed console. Use it.

If I hear one more time that I need to manually edit some json file or add some reg key to turn on/off/etc some feature or functionality, I'm going to scream. It's one thing if it is some obscure beta thing they are testing, but nothing in production should ever not be controllable, both individually and through inheritance, by the portal config.

Also: Let us control debug logging via portal-config! Debug logs have value - but there is a strong argument that they should not be on by default simply due to the amount generated (as is, every DNS request is logged), as well as the fact that on a multi-user system (RDS or hot-desking), they leak info that really shouldn't be visible to other users.

Anything where you've historically only provided the control plane via local registry edits or cli arguments at install (so 'edns fix', tray icon hiding, ARP hiding' - this should all be portal driven config flowing down from top to bottom.