Prepare Sophos Endpoint in VDI gold images
A normally installed Endpoint must not simply be cloned as a VDI template. This creates duplicate identities, incorrect policy assignments and unreliable Health data. Sophos therefore provides a dedicated installation and activation mode for Windows gold images.
Current Windows client and server versions from Windows 10 and Server 2016 are supported with the required minimum Thin Installer and Core Agent versions. Check the current Supported Systems page before building.
Limitations
Do not prepare a gold image with Server Lockdown, Update Cache or BitLocker Device Encryption. These functions conflict with the image lifecycle or create state that cannot be transferred cleanly to clones.
Disable Tamper Protection in a controlled way during preparation and enable it again before completion. Keep the master administratively protected and do not use it as a normal user endpoint.
Persistent or non-persistent
Persistent desktops keep their identity after deployment. Non-persistent desktops are recreated regularly and require --nonpersistent so Sophos Fusion (formerly Sophos Central) treats them accordingly.
This choice also affects Sophos Fusion cleanup. A Removal of Inactive Devices rule can permanently remove stale non-persistent clones. The master created with --goldimage is not covered by these rules.
Prepare the master
Fully patch the clean source system and install all production applications. Then install Sophos in gold-image mode, for example:
SophosSetup.exe --quiet --goldimage --products=endpoint --devicegroup="VDI\Persistent"
Add the appropriate option for non-persistent desktops. Set group, proxy, relay and other installer parameters deliberately as with a normal automated rollout.
The default gold-image preparation timeout is 120 seconds and can be adjusted from 0 to 900 seconds. A higher value is not general troubleshooting; use it only for genuinely slower preparation.
Notification Mode
With SophosSetup.exe --goldimage --notificationmode, the master initially registers with Sophos Fusion and communicates until the next restart. Communication then remains disabled until GoldImageCli.exe activate or Activate and Update is run on the unchanged master. A deployed clone is activated with GoldImageCli.exe clone instead.
GoldImageCli prevents clone while the computer name is unchanged and prevents activate after it has changed. For VMware Horizon instant clones, configure C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe with the clone parameter as the post-synchronization script.
Automate and log the exact workflow in the image pipeline. Release a snapshot only when Sophos state clearly shows the intended mode.
Clone only from the master
Always create new desktops directly from the prepared gold image. Never use an already started clone as a new template, or runtime state and identity data are duplicated again.
After a clone first starts, verify new identity, group, Agent Mode, policies and update. Successful sign-in alone does not prove correct independent registration.
For non-persistent pools, use a bounded reusable set of computer names sized roughly to the maximum number of simultaneous instances. If names are created without limits, Sophos Fusion can accumulate many device and user objects even when automatic VDI cleanup is enabled.
Lifecycle in Sophos Fusion
Non-persistent clones create many short-lived objects. Under Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices, create a targeted VDI group rule. Permanently remove VDI desktops deletes matching clones without later restoration.
Enable this only for clearly bounded non-persistent groups. An overly broad global rule could remove normal offline laptops. Restoring deleted devices does not restore Update Caches or Message Relays.
Upgrade the gold image
Test agent or OS updates on a copy of the master first, then create a new approved image. An expired Fixed Term or LTS package must not remain in the master, or new clones start without current protection updates.
After every release, fully test at least one persistent and, where used, one non-persistent clone. Duplicate devices, wrong groups or repeated re-registration are stop criteria.
Software Packages control product feature updates, not ongoing Threat Protection content, which continues to update automatically. Without a fixed package, every newly started instance may immediately begin a product upgrade. Deliberately set the master’s update channel before release.
Safe acceptance and rollback
Check mode and prerequisites
Timeout Mode checks the computer name after 120 seconds by default; --goldimagetimeout=<seconds> accepts 0 to 900. Notification Mode is intended for VMware Horizon Instant Clone and avoids registration of intermediate machines. The current Sophos CLI requirements specify Thin Installer 1.20.627 or later, Core Agent 2024.2.0.527 or later, or Server Core Agent 2024.2.0.534 or later for this mode. Timeout Mode requires Thin Installer 1.14 and Core Agent or Server Core Agent 2022.1.0.78 or later.
Before installation, create a tested rollback snapshot, verify Sophos Fusion connectivity and the exact VDI group, and turn off Tamper Protection. Do not use a device with Server Lockdown, Update Cache, BitLocker, or Sophos Encryption components. For a non-persistent Horizon pool, a complete example is:
.\SophosSetup.exe --quiet --goldimage --notificationmode --nonpersistent --products=endpoint --devicegroup="VDI\NonPersistent"
Seal the image
Wait for installation to finish, confirm that the master appears in the intended group without local health errors, and turn Tamper Protection back on. In Notification Mode, the master communicates until its first restart and then deliberately remains offline. Use C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe activate only on the unchanged master, and C:\Program Files\Sophos\AutoUpdate\GoldImageCli.exe clone only on a finished clone whose name has changed. Horizon can run the executable with parameter clone as its post-synchronization script. Shut the validated master down and seal the snapshot while it is powered off; keep the previous approved image until clone acceptance succeeds.
Validate identity and lifecycle
Start at least two clones directly from the master. Confirm a unique computer name and separate Sophos Fusion object for each, the expected Endpoint or Server license, group and policies, a current Last active value, healthy status, and completed updates. Sophos cleans the inherited configuration only after detecting the changed name. Do not replace that process by deleting Sophos files, registry values, services, or the Sophos Fusion object. Sophos has also retired the earlier manual and scripted methods for preventing duplicate identities. From Core Agent 2022.1 and Central Installer 1.14 onward, use the installer-switch workflow described here instead. If the platform cannot provide naming and the clone action in this order, stop rollout and adapt the platform or image workflow; don’t fall back to an old cleanup script.
For non-persistent pools, --nonpersistent and Permanently remove VDI desktops must be used together. Permanent VDI removal cannot be restored, and MSP and Marketplace customers must use at least 31 inactive days. Sophos Fusion allows at most two Targeted rules, which cannot contain exclusions; the Global rule’s inactivity period must be longer than every Targeted rule’s period. An Admin or Super Admin role is required to create or change these rules. Sophos Fusion checks once every 24 hours at midnight in the data region. Test a targeted VDI-group rule before wider use; the --goldimage master isn’t included in deletion rules.
Roll back on failure
If identities are duplicated, registration fails, or policies are wrong, stop pool rollout, discard the affected clones, and return to the last approved powered-off template. Deleting a Sophos Fusion object doesn’t repair its local identity. Update the master only in a controlled maintenance cycle, validate it again, and release a new snapshot only after the clone test passes.
Troubleshooting
For duplicate-device Alerts, verify --goldimage was used and cloning occurred directly from the master. Deleting Sophos Fusion objects later cannot reliably repair a normal image.
If clones do not appear or remain unprotected, check network access, proxy or relay and installer logs. For the wrong lifecycle, check --nonpersistent and the Removal rule target.
With Citrix App Layering, prepare Sophos in its own App Layer rather than the OS Layer. The pipeline needs Sophos-documented UniRSD exclusions for Endpoint Defense; without them services may fail after assembly despite active Tamper Protection. Document layer names, test accounts and release time because Sophos Fusion may already see device and user events. Keep the exact Citrix registry procedure tied to the current Sophos KBA.
Sophos supports Endpoint on many virtualisation platforms when the guest OS is supported. This does not replace the hypervisor vendor’s matrix. For example, Microsoft does not support third-party antivirus on Azure Stack HCI version 1 hosts; installing Sophos there leaves the Microsoft support path.
Related articles
Automate Sophos Endpoint rollout on Windows explains CLI options. Manage Sophos Fusion Endpoint devices and groups covers cleanup and restoration.