This article applies to the use of the following
- VMware Virtual Desktop Infrastructure (VDI)
- Microsoft Windows Virtual Desktop (WVD)
- 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)
NOTE: These updates require Huntress Agent version 0.13.16
April 2022 NOTE: Updates were recently made to support the below scenarios. Previously, cloned images or virtual machines running Huntress with the same Huntress ID were counted as a single agent. Duplicate Huntress agent IDs are now recognized and are reassigned with new agent IDs so they can be cleanly monitored as separate machines.
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.
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 firstname.lastname@example.org so we can help to identify the cause and resolve the issue.
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).