Golden images and VDI clones

DPLens can be installed into a golden image.

Every clone notices at its first start that the working state was created on a different machine, and discards that state before anything can be replayed or delivered from it. Without that, every clone would inherit the image's collection positions and its queued events, and would deliver another machine's data under its own name.

The mechanism is the machine identifier that sysprep /generalize regenerates: it is recorded when DPLens is installed, and compared at every start.

What to put in the image

Install with the configuration and, if wanted, the console:

msiexec /i dplens-1.0.912.msi /qn CONFIG_FILE=C:\build\agent.yaml            # or a dp-deploy transform: TRANSFORMS=dplens.mst

Do not bake into the image:

• Secrets and the console password. Seal them on each machine after cloning — with a deployment MSI applied at first boot by your provisioning tool, or by hand with dplens.exe --set-secret and --set-admin-password. Do not assume a value sealed into the image is unavailable on the clones — a clone can carry usable material with it, which is exactly why secrets do not belong in an image. Installing a deployment MSI into the image seals its secrets into the image for the same reason; install the product MSI into the image and apply the deployment MSI on the clones.
• A deployment key. Never stage deploy.key in an image, and never leave one behind: the installer deletes the key it used, but a key staged without an install, or a key file copied into the image by hand, is handed to every machine built from it — and with it every secret in the package. Provision the key on each clone from your platform's secret service at first boot; see Intune, Configuration Manager, RMM and cloud images.
• A machine-GUID licence key — it is bound to the image's GUID and every clone starts unlicensed (the console's Licence card says so). A domain key can be baked: it licenses every joined host and keeps working on the clones. The same applies to the key list inside a deployment MSI: a list of machine keys binds to the machines they were issued for, so an image's list should hold a domain key.

Then run sysprep /generalize /oobe /shutdown as usual. Stop the dplens service first if you want the image's own checkpoints not to grow; it does not matter for correctness, they are discarded on the clone.

What the clone does at first start

The service reads state\schema.json, sees a machine GUID that differs from its own, and:

1. deletes state\checkpoints (so no event the image already delivered is replayed from the clone), state\cache (the image's undelivered spool), state\fim (the image's file-integrity baselines — the clone re-baselines its own files) and state\metrics (the image's counters), and the persisted state\agent-id (a clone must not report as the image; a fresh id is generated);
2. keeps the config, the licence key file, the secret store, the console credential, the audit log and the service identity;
3. writes an audit record naming the old and new identifier and, for each set it deleted, how many files and bytes went — so the reset is fully accounted for rather than silent;
4. records its own identifier and starts normally.

A normal restart on the same machine touches nothing.

A state folder written by a version of DPLens that predates clone detection carries no identifier. The first start adopts the machine's own and discards nothing, so an upgrade keeps live collection positions. Detection depends on that identifier being readable; where it cannot be read, DPLens records the fact and surfaces it in the console.

Verifying a clone

On a freshly cloned machine:

Get-Service dplens
Get-Content C:\ProgramData\DPLens\state\audit\audit.jsonl | Select-String state-reset-clone

The audit record is the proof that the reset happened, and lists exactly what was discarded. Settings and audit → Security also shows the machine identity as having been reset.

Limits

• The reset is a delete, not a quarantine. The audit record is the complete account of what went; nothing is kept aside to recover.
• Detection keys on the machine identifier. A virtual machine copied without sysprep /generalize keeps that identifier and is not recognised as a clone — but such a copy is a duplicate machine in every other respect too, including its computer account.
• Do not rely on secrets surviving a clone. Re-seed them afterwards.