Managed EDR

A partner managing Huntress Managed Microsoft Defender exclusions ran into significant usability issues while trying to add 2 endpoints to roughly 12 existing exclusions in a single org. In its current form, this workflow is highly manual and does not scale well for real-world administration. -- Current pain points: Managed Exclusions are currently scoped only at the account, organization, or endpoint level; there is no way to target exclusions by machine type, tag, or group. The partner wants to apply exclusions to a subset of systems within an org, such as a logical grouping like FSLogix hosts, without having to manage each endpoint individually. Editing exclusions appears to be effectively one-at-a-time for this workflow, making repetitive changes across many exclusions slow and frustrating. After each edit, the UI resets filters, forcing the admin to re-find their place and repeat the same navigation over and over. The partner explicitly described this as one of the worst UX experiences they have had in a long time, which suggests this is more than a minor inconvenience and is likely to create friction for larger or more mature environments. -- Public API support for Managed Exclusions Expose Managed Exclusions management through the Huntress API so partners can automate: Listing exclusions Creating exclusions Updating exclusion scope Bulk assigning endpoints Removing endpoints from exclusions This would allow partners to automate repetitive changes that are currently manual in the UI.

Add a Huntress-initiated "Repair Defender" action that can be invoked. Behind the scenes, this could orchestrate the existing recommended sequences, (e.g., validate Defender services, attempt lightweight reset, then optional deeper OS/Defender repair path), provide status back to the portal and log what was executed. Configuration could include safeguards (e.g., only when Defender is primary/only AV, confirmation prompts for destructive steps, etc.) There is excellent documentation for resetting and repairing MS Defender (Reset Platform, uninstall/re-install on Server, resetting policies, etc.) but it is all manual or script-driven today. There is no simple Huntress platform "Repair Defender" action in the UI. Frontline technicians must copy scripts, run OS-level repair commands and interpret output which can be error-prone and time-consuming.

One of the key components of Windows Defender is the Attack Surface Reduction (ASR) Rules. In my opinion, the ASR rules is what makes Defender such a powerful platform. It would be great if we could include the ability to turn on, manage, and add exclusions for the ASR rules in huntress. Other competitor platforms can do this and it works quite well. These rules exponentially expand the effectiveness of Defender.

Provide a dedicated AV Inventory/Health reporting capability that can be: * Filtered and exported at Account and Organization scope. * Show per-endpoint AV Product, Security Center Status, service status, health (Protected/Unhealthy/Umanaged/etc.) and last scan/update. *Optionally summarized by organization (counts of endpoints per AV product and health state) to support QBRs and cleanup work.

Be able to force enable defender when defender is disabled.

With Managed Antivirus Would be very helpful if there was a way from the client side to force an update of policy settings 'now'. I'm specifically thinking of this for the exceptions. Oftentimes I'm testing new exclusions for performance or other issues using the EICAR file or something similar and having to wait 30 minutes for the new exclusions to kick in really slows us down. Doesn't have to be fancy, even if restarting the huntress agent did the trick that would be great.... have the agent just check in for new AV policies on each restart and we're good!

In environments where third‑party AV (e.g., Symantec) is intentionally the primary protection on certain servers (such as domain controllers), the “Hosts not being properly protected” escalation creates recurring, non‑actionable noise. Today, the only portal action available is Remove, which clears the current hit but does not persist. When the next health check runs and Defender real‑time protection is still disabled by design, the escalation reopens. Request: Add a persistent, per‑host suppression / “expected configuration” option for this escalation. Desired behavior: Scoped to individual hosts Scoped to this escalation only Requires an admin note for auditability Does not affect other escalations or detections Value: This keeps the escalation effective for workstations and genuinely misconfigured systems, while eliminating repeated noise for servers with intentional third‑party AV configurations. It improves signal‑to‑noise and aligns with real‑world data center security models without reducing protection.

Currently, if an EDR Escalation generates a ticket in Halo PSA, updates to the escalation are not reflected in the ticket. Once the initial escalation is resolved, the ticket closes. If new hosts are added to the escalation, notification is only sent via email and the ticket system has no visibility into the unprotected/escalated hosts. This leaves endpoints unprotected due to lack of visibility.

https://docs.microsoft.com/en-NZ/microsoft-365/security/defender-business/?view=o365-worldwide

Currently, there is no immediate notification when an antivirus action occurs on an endpoint. Huntress only reflects the activity after the file has already been quarantined, and the only way to see that action is by manually reviewing the agent’s AV results. This creates a visibility gap. As an MSP, we should not have to manually check each endpoint to determine whether a quarantine or remediation action has taken place.