Image Creation¶

Image creation is the heart of PVS Forge. It turns a prepared master target into a versioned vDisk, imported into PVS and synchronized to your whole farm — in a single, repeatable run. This page explains what happens in each phase.

The workflow at a glance¶

Prepare  →  Seal  →  Image  →  Unseal  →  Import  →  Sync  →  Notify

PVS Forge orchestrates this from the PVS server, driving the master target over WinRM and the PVS farm through the Citrix PVS snap-in.

1. Prepare¶

Reachability is verified first: ping, WinRM, and the store path.
The master target's network configuration is checked: if an adapter uses a static IP address, a notice appears in the notification center — a static address is captured unchanged into the vDisk and can cause errors when that vDisk boots on other machines. Switch the master target to DHCP before imaging. The run itself is not blocked. Once you have opened the suggested solution, the notice is acknowledged and does not appear again for this master target — unless its IP configuration changes.
An optional reboot is performed (unless disabled in Settings). If a reboot is pending, PVS Forge reboots anyway — even with the opt-out — and waits for the target to come back.

2. Seal¶

Sealing freezes the target into a clean, stable state before the image is taken:

Auto-update services are disabled (Windows Update and related, plus Edge, OneDrive and Teams updaters where present). This is critical — anything that updates after the snapshot would not be in the vDisk.
Event logs are cleared so the vDisk starts clean.
An optional custom sealing script can run here to perform your own preparation; its changes are captured in the vDisk.

The exact services and settings PVS Forge touches are listed in Sealing procedure in detail.

3. Image¶

PVS Forge captures a point-in-time snapshot of the running disk and writes it to a VHDX in the store. The VHDX contains only the used blocks, not the full disk size.

How long does it take?

Throughput is limited by disk I/O on the master target, not the network. As a rough guide, expect roughly 50 MB/s on 10 GbE. A vDisk with ~75 GB used takes on the order of 25–30 minutes.

4. Unseal¶

After imaging, the changes made during sealing are reverted: auto-update services are re-enabled so the master target stays serviceable for the next vDisk version. See What unsealing restores for the exact list.

5. Import into PVS¶

PVS Forge writes an import manifest and imports the VHDX into the target store, then applies the configured write cache settings.

Write cache type	Use
RAM + disk, async I/O	Default — best performance
RAM + disk, no async I/O	Diagnostics, e.g. when troubleshooting boot issues

The write cache size is configurable (a common default is 4096 MB; larger for VDAs with more RAM). Load balancing is set as part of the import and is coupled to Sync (see below).

6. Sync¶

When Sync is enabled (the default per master target), the imported vDisk is copied to every PVS server in the farm and set to load-balanced, so all servers can stream the new version. With the advanced replica check enabled (optional, see Settings), the synced copies are validated as the final step after the replication status turns green — the original written by the imager is not checked. This takes a few extra minutes per copy; a copy with proven corruption is deleted and reported instead of silently passing Citrix's size/date check.

No sync, no load balancing

If you disable Sync for a master target before starting, the vDisk is imported only on the PVS server PVS Forge runs on and pinned to that server — load balancing is not enabled. This is deliberate: a load-balanced vDisk that exists on only one server would let PVS route targets to servers without it, and those targets would fail to boot. Re-enable Sync to distribute the vDisk across the farm and have it load-balanced.

This coupling applies to stores on a local drive of the PVS servers. If the store points to a central file share (a UNC path such as \\nas01.example.com\store), there is one copy that every PVS server can reach — Sync is not applicable there, and the vDisk is always imported load-balanced.

Cancelling a job during Sync

If you cancel a job after the vDisk has been imported but before the distribution has finished, the vDisk exists in PVS but is not available on all servers. PVS Forge treats this as a failure: the job ends with the status Cancelled - vDisk NOT distributed and, if e-mail is configured, sends a failure notification with the job log attached — so it cannot go unnoticed that the new version must not go into production yet. Restart the job or distribute the vDisk manually before using it.

7. Notify¶

If configured, PVS Forge sends a notification (e-mail, Teams, or Slack) when the job finishes.

Sealing procedure in detail¶

Sealing is deliberately transparent: this section lists exactly what PVS Forge changes on the master target before the image is captured — and what it restores afterwards. Every step is also recorded in the seal/unseal log (see Logging), including the list of services that were actually touched on your machine.

Steps before imaging¶

The steps run in this order on the master target:

Machine account password changes are disabled (optional, on by default): PVS Forge sets DisablePasswordChange = 1 under HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. On non-persistent targets the OS-native password rotation would break the domain trust, so rotation is left to PVS instead. The previous value is written to the seal/unseal log. This setting is kept in the vDisk and deliberately not reverted during unsealing — see below. It can be turned off in Settings → vDisk & Imaging.

Prerequisite

"Automate computer account password updates" must be enabled on the PVS server so PVS manages the password rotation centrally.
An optional custom sealing script runs.

Update services are stopped and disabled so nothing changes the system after the snapshot is taken. The exact services and settings:

Component	Service / setting	During sealing	During unsealing
Windows Update Medic	`WaaSMedicSvc`	stopped, start type Disabled	start type Manual
Windows Update	`wuauserv`	stopped, start type Disabled	start type Manual, started
Update Orchestrator	`UsoSvc`	stopped, start type Disabled	start type Manual, started
Windows Update policy	`NoAutoUpdate = 1` under `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU`	set	removed (`NoAutoUpdate` and `AUOptions` deleted)
Microsoft Edge updater (if installed)	`edgeupdate`, `edgeupdatem`	stopped, start type Disabled	start type Automatic
OneDrive updater (if installed)	`OneDriveUpdaterService`	stopped, start type Disabled	start type Automatic
Microsoft Teams (new Teams) (if installed)	`disableAutoUpdate` under `HKLM\SOFTWARE\Microsoft\Teams`	set to `1`	set back to `0`

WaaSMedicSvc is handled first because it monitors the other Windows Update services and would otherwise re-enable them.

Event logs are cleared: the Application, System and Security logs are emptied so the vDisk starts clean.

What unsealing restores¶

After the image has been written, PVS Forge reverts the update changes on the master target (see the "During unsealing" column above) so it stays serviceable for the next vDisk version:

The Windows Update services are set back to Manual — their Windows default (they are trigger-started on demand) — and started.
The Windows Update policy values are removed; the Edge and OneDrive updaters go back to Automatic, Teams auto-update is switched on again.
Unsealing also runs if the job is cancelled or fails after sealing, so the master target is never left with updates disabled.

The machine account password setting is the one exception: it is not reverted, because it must remain in the vDisk (and PVS keeps rotating the password centrally).

Why the vDisk keeps updates disabled¶

The image is captured while updates are disabled, so every target streamed from the vDisk boots with updates off. That is intentional: on non-persistent targets, updates would be downloaded and installed into the write cache — and lost on every reboot — wasting bandwidth, CPU and disk I/O on every single machine. Updates belong on the master target, which is unsealed after each run and therefore always ready for the next patch cycle.

Smart Parallel Imaging¶

You can select several master targets and image them at the same time. Each target runs the full workflow independently, with its own status, live-log lines and history entry. PVS Forge does not simply run all those jobs against the same server, though — it distributes the imaging work across your PVS farm.

How the work is distributed¶

When you select multiple master targets and click Start all, PVS Forge plans the whole batch before the first job starts:

It determines the expected data volume of every master target (the used space on its system disk) and computes a load per PVS server from it.
vDisks that will be synced across the farm are then created directly on the store of a remote PVS server — the largest ones are placed first, each on the server with the least accumulated load, so the total write load is spread as evenly as possible.
vDisks without Sync (on a local-drive store) always stay on the PVS server PVS Forge runs on, because that is where they are imported and pinned (see No sync, no load balancing).
vDisks on a store that points to a central file share are written to that share by the PVS Forge host and imported load-balanced — there is one copy for the whole farm, so neither Sync nor pinning applies.
If there are more vDisks than PVS servers, jobs stack up on a server. A stacked job does not start immediately: PVS Forge staggers it until the previous job on the same server has made good progress, so two images never compete for the same disks at full speed.

Why sync vDisks are created on a remote server¶

A vDisk with Sync enabled ends up on every PVS server anyway — so creating it directly on a remote server costs nothing extra, but it takes the write load of the imaging run off the PVS Forge host. Several vDisks are written to different servers' disks at the same time instead of competing for the same storage. That is the benefit: disk I/O — not the network — is the bottleneck of an imaging run, so the whole batch finishes considerably faster. After imaging, PVS Forge transfers the vDisk to its own host, imports it there and distributes it to the remaining servers as part of the normal Sync.

Start all vs. single start¶

The smart, size-aware distribution runs only for Start all (the batch start). A single job started with its row's Play button takes a lightweight immediate path instead — without measuring disk sizes first, so the job starts right away. Single jobs and batches still see each other: a Sync job goes to a free PVS server (free remote servers first, then the free local server); only when every PVS server is already imaging does the new job queue behind the running disk on the least-busy server and start staggered once that disk has reached the configured threshold. A job without Sync always runs on the local server.

While a batch is running, the other rows stay available: you can start free master targets individually with Play, or select several and start them as a second batch with Start all. Only rows that belong to a batch that is still running are locked — each row becomes available again as soon as its own job finishes (or is cancelled), even if the rest of its batch is still imaging. Cancel always stops everything that is currently running.

Following a single target in the live log¶

When several targets image in parallel, their messages share one live log, with each line tagged with its target. Use the log filter above the live log to show only the lines of one master target; select All to see the combined stream again.

Logging¶

Each run writes detailed seal/unseal logs on the master target, and the complete job log is preserved in Imaging History.