Peering & Content Basics
This page will cover the basics of how DeployR creates WIMs for its content items and leverages BranchCache to enable peering of the content
Overview
DeployR uses 2Pint-developed technology to implement BranchCache downloads. It works in Windows PE and the full Windows OS when the server provides BranchCache content information (CI data).
DeployR content downloads use BranchCache when the server provides CI data.
Uploaded content is converted to WIM files for efficient deployment and peer sharing.
Enable BranchCache on the DeployR server before deploying content.
DeployR clients only serve content to peers from the full Windows OS. Windows PE peer serving is planned for a future release.
Prerequisite
Enable BranchCache on the DeployR server:
Install-WindowsFeature BranchCacheContent as WIMs (vs Zip or Uncompressed)
Why did 2Pint decide to use the WIM format for DeployR Content?
Windows Imaging Format (WIM) offers several advantages over ZIP archives or uncompressed files, particularly in enterprise scenarios involving DeployR, the 2Pint Software OSD Tool, for software deployments. These benefits stem from WIM's native integration with Windows, its file-based structure (which supports single-instancing for deduplication). Below is an outline the key benefits of WIM over other formats.
Superior Integration with BranchCache for Network Efficiency BranchCache identifies and caches identical content blocks across files, enabling peers to share data and minimize downloads from distribution points. WIM excels here due to its compression compatibility and single-instancing (storing duplicate files only once within the archive), which creates more identifiable common blocks than ZIP or uncompressed formats.
Deduplication Efficiency
High: Single-instancing and LZX compression yield excellent block matching, reducing redundant data transfers by up to 50-70% in tests with driver packages.
Moderate: DEFLATE compression works but lacks single-instancing, leading to poorer block reuse across files.
Poor: No compression means larger files with no inherent block optimization, increasing WAN usage.
P2P (Peer-to-Peer) Performance
Optimized: Better hash-based chunking aligns with BranchCache's content identification, speeding up OSD (OS Deployment) in remote sites.
Adequate: Supports BranchCache but with lower efficiency for large, similar payloads.
Minimal: Full file transfers without caching benefits, causing high latency in branch offices.
Example Impact
In DeployR OSD for drivers, WIM reduces download sizes via BranchCache more effectively than ZIP.
ZIP is viable but requires full extraction, negating some P2P gains during deployment.
No savings; ideal for tiny payloads only.
This makes WIM ideal for deploying large applications (e.g., 10-30 GB installs) in bandwidth-constrained environments, as seen in real-world DeployR setups.
Reduced Disk Space and Client Cache Usage in Deployments WIM files can be mounted directly without full extraction, allowing installations to read files on-the-fly. This contrasts with ZIP (which requires unpacking to a temp folder) and uncompressed files (which consume full space immediately).
Cache/Storage Savings
Significant: No extraction needed.
Moderate: Compresses well but extraction doubles space needs temporarily
None: Full size from the start, bloating client caches.
Deployment Speed
Faster: Mounting takes seconds (e.g., 20s for 13 GB), enabling quick installs without I/O overhead from small-file copies.
Slower: Extraction adds time and disk thrashing for large apps.
Fastest access but slowest transfer due to size.
Example Impact
In DeployR, WIM avoids expanding content, saving time and disk space.
Useful for simple archiving but inefficient for repeated large deploys.
Only suitable for small, non-repetitive files
For software deployments with very large build & capture WIMs that might include large applications like Autodesk or LabVIEW, WIM's mount-only approach accelerates task sequences OSD build time.
.GENCI BranchCache hash file
When a task sequence first retrieves a content item, the DeployR server creates its BranchCache hash file. The file is stored beside the content item and has the same name with a .genci extension. DeployR regenerates the file whenever the content changes.
To confirm that the file exists:
Run a deployment that retrieves the content item.
In the DeployR dashboard, open the content item.
Copy its Relative path. The content URL uses the same path.
Combine the relative path with the configured DeployR content location. This example uses
D:\DeployRContentItems. The default location is underProgramData.
Open the resulting folder in File Explorer. Confirm that it contains the
.gencifile.
7-Zip can inspect a WIM file. Do not modify the WIM file directly.
Verify peer downloads during deployment
When the task sequence requests content, it first shows Calculating. During this phase, it checks for peers and reads the hash.
Afterward, the content download starts. The peer-to-peer percentage appears during the transfer.
Review the log after the download completes:
Disable P2P Option
Why Disable P2P?
Disable peer-to-peer downloads when the DeployR server has a fast, dedicated connection to every target device.
Labs using Hyper-V with fast connections to all test machines.
OSD build rooms with a dedicated, appropriately sized DeployR server.
How to Disable P2P?
Set the Peering task sequence variable to false.
PowerShell Script:
No-caching option
Use BranchCache without caching
Set the Peering task sequence variable to NoCache. DeployR uses BranchCache for the download but does not retain the content in the BranchCache cache.
Use this setting for very large applications when cache storage is not worthwhile. Set it before the application install. Restore the previous value afterward.
Peering variable values
True (default)
Enables peer-to-peer downloads and BranchCache caching.
false
Disables peer-to-peer downloads.
NoCache
Uses BranchCache without storing content in the BranchCache cache.
Last updated