Team: Huntress Managed Endpoint Detection and Response (EDR)
Product: VDI, AVD, Citrix VDI, Deep freeze, Virtual Box, UWF
Environment: Windows, MacOS
Summary: Deploying Huntress Via VM
1VDI scenarios
2When cloning an image or virtual machine
3How VDI Agent deduplication works
4Important Notes on VDI environments
This article applies to the use of the following
- VMware Virtual Desktop Infrastructure (VDI)
- Microsoft Azure Virtual Desktop (AVD)
- Citrix VDI (formerly XenDesktop)
- The use of standard install images (Sysprep/WIM, Microsoft Deployment Toolkit, etc.)
- Faronics Deep Freeze
- Oracle Virtual Box
- Unified Write Filter (UWF)
If your desktops are not persistent you'll want to create a log-off script that uninstalls Huntress before destroying the machine (especially Citrix). This will avoid have duplicates appear in your account, so this step is very important for your billing to remain accurate!
Before you begin
We suggest that any org that you have VDI's in, have an Days until unresponsive set at 2, unresponsive limit of 7 days, with an unresponsive action of uninstall. You can do this by going to the Organization tab at the top of your dashboard. Then search for the org your VDI's are in and hit the pencil icon on the right.
Note: These settings will override the account settings for unresponsive agents.
VDI scenarios
Scenarios that require consolidating agents:
- A virtual machine with Huntress is restored to a previous state without the Huntress agent. Then Huntress is immediately reinstalled.
- A VDI environment where a VDI is created based on a parent image with Huntress and then retired/deleted after it’s no longer needed.
Scenarios that require identification of separate agents:
- A virtual machine with Huntress is cloned to create a new virtual machine with Huntress.
- A baseline image with Huntress is reused and deployed across multiple machines.
When cloning an image or virtual machine
1) Install the Huntress agent
2) Stop the agent Huntress Agent -- Either from the services manager or "sc stop HuntressAgent" from an administrative command prompt
3) Shut down the virtual machine
4) Clone the VM/Create the image
5) Allow the agent to register when the image or virtual machine VM is deployed
How it works
In virtual environments, Huntress uses the UUID, mac address(es), hostname, and/or boot time to help uniquely identify a host. When a VM is recomposed and these attributes remain the same, Huntress will re-use the existing agent ID when the agent registers in order to prevent the creation of duplicate hosts.
If the UUID, mac address(es), and/or hostname changes, Huntress will update the newer machines (calculated based on their boot time) with a new Huntress agent ID so that it is separated from the original agent.
Testing
We recommend testing a few clones before mass deploying. Reboot and revert the clones several times to verify the expected behavior.
If you continue to see unexpected behavior from what is described above, we ask that you contact support at support@huntress.com so we can help to identify the cause and resolve the issue.
Compatibility Notes
Huntress records the boot time of the endpoint each time it comes online. When an agent comes online with identical attributes to another agent but with an earlier boot time than what we have previously recorded, then Huntress will also consider this a new agent that has been cloned from an older image.
There are certain situations such as with Deep Freeze or UWF that should be considered. When an image is restored and the original boot time is preserved, this could potentially cause duplicate Huntress agent entries for the same host.
To avoid or resolve this, ensure that the frozen or reverted state was created from a shutdown image or configure the image to allow the boot time to be updated based on the restored time.
Updating of the Huntress Agent
The Huntress Agent checks for updates each time it starts. If your image has an older Huntress version, it will automatically update when the user logs in (the HuntressAgent.exe is a few megabytes in size).
Edge cases that may result in agents sharing Agent IDs (unable to disambiguate between hosts)
Some motherboard manufacturers may use the same host_unique_id which can prevent hosts from generating separate Agent IDs.
When an agent calls WMI to get the last_boot_time, the call returns a null status, which is interpreted as a time of 0:00:00:000:000. If multiple hosts in the same organization return this null value, they may be noted in our portal as the same host. Scheduling the hosts to reboot at different times (not all at once) should correct this issue.