Persistent Virtual Device Infrastructure (VDI) and Gold Image Cloned Devices

Persistent VDI enables your IT team to provision virtual desktops that retain their configuration, applications, and user data between sessions, unlike non-persistent VDI instances, which reset on every reboot. This applies to any other device, physical or virtual, that is cloned or provisioned from a common gold image and then runs as its own unique endpoint rather than resetting between sessions.

Because each of these devices keeps its identity over time, the Ivanti Neurons Agent can be installed and managed using either of the two methods below, depending on how much automation your environment requires.

Feature Workflow

Agent Deployment Options:

  • Persistent virtual desktops and other devices cloned from a gold image can have the agent installed as part of the base image build process and then registered manually for each cloned instance using the standard registration command with an enrollment key.

  • Alternatively, once the cloned image is running, the agent can be pushed to it remotely, the same way it would be pushed to any standard physical or virtual endpoint.

Ongoing Management:

  • Because persistent cloned images retain their agent identity and configuration across reboots, they do not require the sealing, unsealing, or base image registration steps used for non-persistent VDI.

  • Each persistent cloned image is treated as a unique, long-term endpoint in Ivanti Neurons once registered.

Method 1: Manage Manually

Use this method to control the base image build process directly, either by registering the agent immediately when each cloned instance boots or by pre-populating the image with engines in advance.

Pre-Install the Agent on the Base Image Without Registering or Pre-Populating Engines

To prepare the base image without registering the agent or downloading engines ahead of time, follow these steps:

  1. Run the agent installer on the base image without an associated .options file.
  2. When the Activation key or Cookie option appears, click Cancel.
    This installs the agent on the endpoint without registering it to the tenant, and there is no .options file present to trigger automatic registration.
  3. Once each instance is spun up from this base image, run the stagentctl register command (without the seal or unseal options used for non-persistent VDI) to register the agent using an enrollment key as follows:

    stagentctl register --enrollmentkey "%enrollmentkey%" --baseurl https://agentreg.ivanticloud.com

    In the above command, the %enrollmentkey% is a combination of tenantid_activationkey found in the associated .options file downloaded from the Agent Deployment page.
    This process registers the agent with the tenant and retrieves the engines linked to the policy associated with the enrollment key. Since this instance is persistent, the agent's identity and configuration set during this step will remain intact even after reboots. As a result, registration only needs to occur once per instance.

Pre-Install the Agent and Pre-Populate Engines Using the Offline Prep Tool

To avoid downloading engines over the network the first time each persistent cloned instance checks in, you can install the agent without registering it. Then, pre-populate the image with engines using the Ivanti Neurons Offline Prep Tool, available on the Ivanti Innovators Hub.

For more information and tool download, go to Ivanti Neurons Offline Installation and Configuration Guide for UWM Hybrid on the Ivanti Innovators Hub.

Method 2: Manage Remotely

Use this method to treat each persistent VDI instance or other gold image cloned device the same way you would treat any other managed endpoint, rather than building registration into the base image.

To manage a persistent VDI instance or other gold image cloned device remotely, follow these steps:

  1. Spin up or provision the device.

  2. From the Ivanti Neurons console, install the agent on the running instance using the standard Agent Push Install method, the same way you would push the agent to a standard physical or virtual device.

  3. After installation, the agent registers with the tenant and downloads the engines related to the assigned policy. Then, instance appears in Ivanti Neurons as a standard managed endpoint.

Since this approach does not require base image registration or sealing, each persistent instance is managed independently. The updates, policy changes, and engine installations are processed through regular agent check-in behavior instead of relying on base image inheritance.

Things to Note

  • Persistent VDI instances and other devices cloned from a gold image do not use the sealing, unsealing, or asBaseImage registration options used for non-persistent VDI, since each instance retains its own agent identity across reboots.

  • Agent recertification behaves normally on persistent VDI instances and other gold image cloned devices, since there is no shared base image security association to protect.

  • Choosing between Manage Manually and Manage Remotely depends on how much control you need over the base image build process versus how much you want each instance to be managed like a standard endpoint after deployment.