Huntress EDR (with Managed Defender) on 2-node VSAN Free Hyper-V cluster nodes: known issues or recommended exclusions?

[LeoJS]

Hi all,

We're planning to install the Huntress EDR agent on both nodes of a 2-node hyperconverged cluster. Before we touch production, I'd like to hear from anyone running Huntress, or a similar EDR, on StarWind nodes.

Environment

• 2 × Dell R640, Windows Server 2022 Datacenter, Hyper-V Failover Cluster
• StarWind VSAN Free, Windows-native service (not the CVM), managed through StarWindX PowerShell
• Build 8.0.0.20089, upgraded from 20084 in July
• One HA device, about 7 TB, all-flash, direct-connect 25GbE sync/iSCSI links between the nodes
• L1 write-back cache disabled on both nodes, per StarWind's recommendation after the incident described below
• A separate third server provides the cluster witness and Hyper-V Replica target
• Workload: a handful of server VMs (DCs, file, application) plus about 14 Windows 11 VDI VMs

Background
In July, StarWindService.exe crashed twice within about 7 hours on build 20084. The Event 1000 entries showed ntdll.dll, exception 0xc0000374. The second crash hit the sync source while a resync was still running, which left both nodes "not synchronized." We recovered with MarkAsSynchronized() from SyncHaDevice.ps1, thanks to help on this forum. We then upgraded to 20089 and disabled the cache, and it has been stable since. So I'm being very careful about anything that hooks into the StarWind service or the storage path.

What we plan to do

• Install the agent on one node per night: drain the node with Suspend-ClusterNode, install, verify, then resume. Do the second node only after 24 clean hours on the first.
• Exclude both nodes and the witness from Huntress's automatic host isolation. Isolation would cut the sync and iSCSI traffic.
• Add Microsoft Defender exclusions:
  • the StarWindService.exe process
  • C:\Program Files\StarWind Software\
  • the folder holding the .img and header files (S:\StarWind)
  • C:\ClusterStorage\
  • C:\Windows\Cluster\
• Confirm with Get-MpPreference that the exclusions persist after Huntress's managed Defender policy applies.

Questions

1. Has anyone run Huntress EDR on StarWind VSAN nodes? Any crashes, sync drops, iSCSI latency or failover problems?
2. Is there a current official StarWind antivirus/EDR exclusion list for Windows-native VSAN on Hyper-V? Is anything missing from mine above, such as the log folder or other StarWind processes?
3. Should StarWindService.exe also be excluded from EDR process monitoring and injection, not just from AV file scanning?
4. Is there any recommended StarWind-side setting to adjust, such as sync or heartbeat timeouts, when adding a security agent to the nodes?

Thanks in advance. I'll post back with results once both nodes are done.

[yaroslav (staff)]

You would need to add the .img and .swdsk files from the StarWind folders as exclusions to the antivirus/Windows Defender rules.
Another thing to mind is networking. StarWind operates through ports 3260 and 3261. 3260 is used for iSCSI traffic, and 3261 serves for StarWind Management Console connections. StarWind installer automatically opens these ports in the Windows Firewall during the initial installation. If a third-party firewall is used, ports 3260 and 3261 have to be opened manually.
If the antivirus software allows so, add the StarWind VSAN service (starwindservice.exe), C:\Windows\system32\config, с:\windows\cluster, to its exclusions as well.
Please find below the link to the exclusions by Microsoft: https://docs.microsoft.com/en-us/micros ... -worldwide

Is there any recommended StarWind-side setting to adjust, such as sync or heartbeat timeouts, when adding a security agent to the nodes?

I'd suggest not doing anything to the timeouts.

[LeoJS]

Excellent feedback, as always... thank you Yaroslav!

For those interested, here was the response from Huntress we just received as well:

Huntress supports Windows Server 2022 generally, including Managed AV coverage, and is commonly deployed on Windows server workloads. For your Hyper-V/StarWind VSAN cluster specifically, Huntress does not have evidence to treat the exact StarWind VSAN/iSCSI/CSV topology as certified or guaranteed to have no impact.

For the recommended configuration, install the Huntress agent on each node’s host OS, not as a clustered role or on a Cluster Shared Volume. Since the witness already runs Huntress, validate its exclusion and isolation settings first where practical. Then deploy to one cluster node at a time during a maintenance window while monitoring cluster and StarWind health.

For Defender exclusions, if Huntress Managed AV is in Audit mode, Huntress observes and reports without changing endpoint settings. Audit mode can still flag risky exclusions for review. If Managed AV is in Enforce mode, Huntress reconciles Defender settings to Huntress policy and may flag or remove risky or unapproved exclusions unless they are configured or explicitly allowed in Huntress. Microsoft management layers such as GPO, Intune, or MDE can take precedence over Huntress policy, so confirm the effective source of truth before deployment.

For Host Isolation, add the cluster nodes and witness as Host Isolation exclusions in the Huntress portal if automatic isolation would disrupt cluster heartbeat or StarWind sync. The documented path is Settings → Managed Response → Add Exclusion → Host Isolation. The tradeoff is that Huntress will not automatically isolate those hosts. Partners can still manually isolate hosts regardless of exclusions, so manual response planning should be agreed upon in advance.

For installation and updates, initial installation generally should not require a reboot if the host has no pending Windows reboot state. However, Huntress cannot make an absolute no-reboot promise for this topology. Huntress EDR includes driver-level components. Agent updates are designed to install in the background without reboots or user interruptions. In some cases, an update to the EDR driver component may need a reboot to finish, and EDR protection on that host may be degraded until the reboot occurs. Updates are automatic and cannot currently be pinned or deferred per server, so plan to check agent health after updates and reboot promptly if one is pending.

Because of the cluster sensitivity, validate the required exclusions and isolation settings first, and have Huntress Support review the exact StarWind topology before concluding that Huntress will have no storage, iSCSI, CSV, or network-filtering impact.[/list][/list]

[yaroslav (staff)]

Thanks for sharing!
P.S. Careful with the clustering.