Concurrent captures & deployments

Run more than one imaging job at a time, then choose a wave size your Forge can sustain.

What can run together?

Technician seats control how many access codes can be issued; they are not concurrent-job slots. One valid code is not locked to one active transfer.

How concurrency changes completion time

Once one job can saturate the bottleneck, simultaneous transfers divide that capacity. Two equal transfers take about twice as long per PC, four take about four times as long, and so on. The whole wave still benefits because verification, DISM apply, driver injection, and other PC-local phases run in parallel after each deploy finishes downloading.

shared transfer time per PC ≈ single-transfer time × simultaneous transfers
deploy time per PC ≈ shared download + local verify/apply/drivers/profile

Example: 30 GiB WIM on a full 1 GbE link

Using 110 MiB/s of measured payload throughput, the single download is about 4.7 minutes. This is a planning example, not a guaranteed ImageForge speed.

If a single PC reaches only 40 MiB/s while the Forge can sustain 110 MiB/s, the first two or three parallel jobs can increase total throughput before sharing begins. That is why a measured pilot is more useful than a theoretical port speed.

Practical starting points

These are conservative starting points, not software caps or certified hardware ratings. For most 1 GbE benches, starting two jobs a few minutes apart is a good operating pattern: the first PC can enter its local DISM phase while the next one downloads.

Limits and safeguards

• Direct-capture window: a direct-capture session must finish writing and call completion within six hours.
• HTTPS transfer stalls: deploy downloads and staged-capture uploads have no short overall deadline while data keeps moving. The boot client cancels one after two minutes with no bytes transferred; interrupted deploy downloads can resume with HTTP Range.
• Windows desktop SMB use: direct capture writes to a temporary SMB share. Microsoft's Windows desktop product terms allow up to 20 other devices to connect for file sharing. Use Windows Server for larger direct-capture waves and confirm the licensing that applies to your environment. Deploy downloads and staged-capture uploads use ImageForge HTTPS rather than that SMB share. See the Microsoft Windows desktop product terms.
• NAS-backed direct capture: every active capture first occupies the Forge's local data\capture-spool. Keep enough free space for the sum of source-used bytes across the wave, plus 2 GiB per capture. The preflight checks each new capture, but does not reserve that space against other active sessions.
• NAS finalization: capture hashing can overlap, but completed spool-to-NAS copies are serialized today. A second capture can therefore wait in finalization even after its DISM phase is done.
• Maintenance: do not move/adopt the image store, restore a backup, delete an image, or service a WIM during an imaging wave. Schedule those as maintenance work.

Find the limit of your Forge

1. Use the same representative WIM and comparable PCs on the production switch path. Record image size, Forge host edition, store type, link speed, and whether the job is capture or deploy.
2. Run one job. Record transfer time, transfer rate, local DISM/verification time, and end-to-end time from the ImageForge Operations view and audit history.
3. Repeat with 2, then 4, then 8 simultaneous jobs. Start each wave within one minute; otherwise it is a stagger test rather than a saturation test.
4. For each wave calculate aggregate rate: total bytes transferred / wave transfer time. Watch Windows network throughput, processor load, and disk throughput/latency on the Forge.
5. Choose the previous wave size when adding more jobs improves aggregate throughput by less than about 10%, causes errors, exhausts safe free space, or makes individual completion time miss the maintenance window.
6. Run one mixed capture/deploy wave as a separate test. Do not assume that a read-only deploy result predicts simultaneous write-heavy captures.

Record this test sheet

For higher-throughput Windows Server hardware, SMB Multichannel can use multiple suitable network paths and provide fault tolerance; storage and CPU must still keep up. Review Microsoft's SMB Multichannel guidance and SMB performance troubleshooting before changing security or network settings.