Pool machines and non-persistent desktops

A pooled virtual desktop starts from a clean copy of its golden image every time. Without help, that breaks an RMM: every reset machine enrols again with a new key, a clone captured with the master's agent enrols as the master, and a desktop switched off overnight looks like an offline device. Tenvara treats pool machines as devices like any other while they run, keeps each one on its own record across resets, and never calls a machine offline when it was switched off on purpose.

This guide is for Remote Desktop Services (RDS) pooled desktops and session hosts. Set up the deployment and its golden image first: see Virtual desktops: finding and adopting deployments and Golden images.

Prepare the agent in the image#

The agent in a golden image has to forget the machine it was installed on before the image is captured. Prepare the agent does that.

From a golden image build#

On the image's Build tab, keep Prepare the agent for cloning ticked. Every build then prepares the agent on the image for you just before it is captured, with a token for that collection.

By hand#

1. Open the image on Infrastructure > Virtual desktops, the Images tab.
2. Click More > Prepare the agent.
3. Under The clones, choose how they behave: As each clone shows, Start from the clean image at every restart or Keep their changes.
4. Optionally set a Persistent disk for the agent's key (a drive every clone keeps across a reset, such as D:) and the Image version.
5. Confirm. The master's agent prepares itself and stops ("Its agent prepares itself and stops. Shut the master down and capture the image next.").
6. Shut the master down and capture the image straight away.

Preparing removes everything that makes the agent this machine (its key, enrolment, caches and logs) and keeps the install's own settings. It leaves an image install token for that one collection where the agent's first start picks it up. The token is listed and can be revoked with the customer's other enrolment tokens.

Note: If the prepared master is started again before the capture (for a late update, say), its agent recognises it is the image's master and does not enrol, so the token stays for the clones.

What happens when a clone starts#

Each clone's first start enrols with the image install token as itself, matched by its computer account, name and collection:

• A new machine enrols as a new device.
• A machine that was reset finds its own record again. It takes its new key without a key change approval and keeps its id, history, tags, policies and notes; its activity says "re-attached".
• A clone can never enrol as another machine, and a token for one collection is refused on another customer's or another collection's machine.

The first minute#

A non-persistent machine has lost everything put on it since its last start, so Tenvara puts it back straight away:

1. Its policies, monitoring and scripts are pushed at once.
2. Apps deployed to it that the image does not hold are installed in that minute.
3. Automation rules with the trigger A pool machine starts from its image run now: put a start script, a drive mapping or a message there. See Building a rule.
4. Its hardening baselines are checked and put back.

Anything the image version already has (its apps, scripts and baselines) is skipped. The device's activity says what happened, for example "BEA-VD-004 started from the golden image Office desktops v3. Its policies, monitoring and scripts were pushed at once. 1 app is being installed. 2 apps, scripts and policies are already in the image and are skipped."

Patching through the image#

Updates installed on a non-persistent machine are gone at its next start, so by default it is patched through its golden image: it gets no scheduled installs or restarts of its own, its patch status is its image's ("Patched through its golden image"), and the image's drift alert is the one to act on rather than one alert per machine. Build and roll out a new image version to patch the pool. The patch policy editor says how many pool machines it leaves to their images.

If you really want each machine patched as well, turn on Patch non-persistent pool machines one by one in Settings > Infrastructure, the Virtual desktops section.

Machines switched off on purpose#

A pooled desktop the broker switched off, or a session host taken out of service and switched off, is not a problem. While it is off on purpose:

• it is left out of the device lists and counts (gone, not offline), out of offline alerts and "A device goes offline" automations, and out of patch, compliance and agent health percentages;
• its device page shows the state (Off, In maintenance or Removed) in place of Online or Offline, with the reason in words ("Off: managed by" and what switched it off) and since when.

A machine that is off when it should be on (a session host the broker still sends new connections to) is different: it shows Off unexpectedly in red and raises "Pool machine off unexpectedly", in place of the usual offline alert.

To see the switched-off machines in a device list, tick Include powered-off pool machines beside the filters: they come back greyed with their state in the Status column. The Virtual desktops view of the device list shows only pool machines, with a Pool column that links to the deployment.

A machine removed from its collection stays in the lists for Archive a removed pool machine after (24 hours by default), then is archived: out of every list and count, with its history kept. A machine recreated with the same identity comes back to the same record.

The Machines section#

Each deployment's page has a Machines section: every machine in its collections with its Pool, Power (on, off by the controller, in maintenance, removed or not known), In use (and who is on it now), Kind (Non-persistent or Persistent), Image and Agent last seen, with counts at the top.

Counting pool machines for billing#

A pool of 40 desktops with 25 on at the busiest time should not be billed or licensed as 40. Count pool machines as, in the Virtual desktops section of Settings > Infrastructure (per customer), decides how pool machines count towards the device numbers you charge per device and towards your licence:

• The most powered on at once in the month (the default)
• The average of each day's peak in the month, rounded up
• Every machine in the pool

Machines that are not in a pool always count as themselves. The Machines section says which rule applies, with Change. See Billable units for how device counts reach the invoice.