Preparing the master target¶
A vDisk is streamed read-only to many target devices: whatever you capture becomes the shared baseline for all of them. The master target should therefore be in a clean, stable, representative state when the image is taken. The points below explain how to prepare it — and why PVS Forge enforces some of this automatically.
Give the master target only the Default Domain Policy¶
Keep the master target on the Default Domain Policy alone, without additional server-hardening GPOs (for example RDS hardening policies). Placing it in its own OU helps keep extra policies away.
Why: the image captures the machine's configured state. Extra GPOs bake machine- or role-specific settings into the vDisk that then apply to every streamed target, and some hardening settings can interfere with imaging itself. A minimal, well-known policy set produces a predictable, clean image.
Keep the master target free of active sessions¶
PVS Forge logs off disconnected RDP sessions before imaging automatically. Active console or RDP sessions are only logged off when Force logoff is enabled in Settings — otherwise the job stops with a message.
Why: an open session leaves per-user state behind — profile data, temporary files, loaded registry hives, and open file handles or locks. That would be captured into the vDisk or prevent files from being read consistently. Imaging a machine with no active sessions (RDP, console) yields a clean baseline that represents a fresh boot, not someone's working session.
Reboot and pending reboots¶
PVS Forge can reboot the master target before imaging (optional). If a reboot is pending, it reboots regardless — even when the optional reboot is turned off — and waits for the machine to come back.
Why: a pending reboot means Windows has servicing operations only half applied (updates, component changes) that finish on the next restart. Imaging in that state captures an inconsistent, half-updated system that may never finish servicing — and then repeats that broken state on every streamed target. Forcing the reboot brings the machine to a stable, consistent state before sealing.
PVS Forge verifies that the reboot actually happened: it records the machine's boot time before issuing the restart and only continues once the boot time has changed. If the master target gets stuck shutting down (a service refuses to stop), the run is aborted with a clear message instead of imaging a machine that is about to go down — complete the reboot manually and start the run again.
Disable known updates before imaging¶
During sealing, PVS Forge disables the well-known auto-update mechanisms — Windows Update and its helper services, and the updaters for Edge, OneDrive, and Teams where present.
Why:
- The image is taken from a snapshot. Anything that updates after the snapshot is not in the vDisk — and an update running during imaging makes the captured state inconsistent.
- On a streamed vDisk, updates achieve nothing permanent anyway: the disk is read-only and every change is discarded at the next reboot.
The real risk: updates crippling live targets
The bigger problem is when updates run. An update can be triggered at any time — so a target that runs fine in the morning can suddenly slow to a crawl later as updates download or install in the background. At its worst, an update storm during boot or at user logon loads the system so heavily that it becomes practically unusable and users get a black screen when signing in.
Because a streamed vDisk resets on every reboot, the same download-and-install happens again on the next boot — so the scenario repeats every day when, for example, targets are rebooted nightly. Freezing updates in the vDisk avoids this entirely and keeps every streamed target fast and predictable.
Do the same for your own auto-updating applications¶
PVS Forge handles the common Microsoft updaters, but any third-party application with its own updater — antivirus / EDR, browsers, line-of-business clients — has exactly the same problem: it tries to update on every streamed target (wasting write cache and causing drift) and can update mid-imaging.
Disable the auto-update of such applications as part of imaging, using a custom sealing script.
Re-enable everything after imaging¶
Once the image is taken, PVS Forge unseals the master target: the update services it disabled are switched back on.
Why: only the streamed copy should have updates frozen — the master target itself must stay serviceable so the next vDisk version you build is current. Unsealing returns it to a normal, update-capable state between imaging runs. If your sealing script disabled extra applications, re-enable them the same way (or rely on the master target's normal servicing).