Contents
-
Introducing Nomad 7.0.200
-
Implementing Nomad
-
Working with Nomad
-
Core features
-
Download once to branch
-
Download resumption and consistency checking
-
Nomad Cache
-
Distributing software with Nomad and Configuration Manager
-
Downloading content for CM Software Updates from Microsoft Update
-
Deploying Office 365 updates
-
Windows 10 Express Installation Files and Delta Content for Updates
-
App-V support
-
Remote differential compression integration
-
Cloud Support
-
Download once to branch
-
Advanced features
-
ActiveEfficiency features
-
OS Deployment features
-
Nomad tools
-
Operational best practices
-
Frequently asked questions
-
Core features
-
Troubleshooting
-
Training
-
Reference
Remote differential compression integration
In our example, a package that has been previously downloaded has one of its files updated. Nomad compares the Configuration Manager RDC signature file (where each block in the file is given a number that identifies it according to its contents) for the new version of the file and the one before it. By identifying the changes, Nomad is able to download just the file blocks containing the differences.
RDC integration occurs on:
- Configuration Manager distribution point (DP)
- Nomad client master
- Nomad client peers
The only configuration required for RDC is:
- Enable Configuration Manager RDC on the DP
- Install Nomad using the SIGSFOLDER property on any DPs (or update the Nomad SigsFolder registry value)
RDC on distribution points
RDC signature files must be generated and copied to the default signature folder (C:\SMSSIG$
) by Configuration Manager. If you use a different location for the signature files, you must update its location in the in SigsFolder registry value. Signature files are generated for every package, including OSD images.
RDC on the elected client
The RDC file copy feature only works between the DP and the elected master. The package download process remains almost the same as in earlier versions of Nomad except for files that have an RDC value specified for them in the manifest file.
The Nomad master checks for the package version (n-1)
on the subnet. If the version (n-1)
is cached locally or available on another client on the same subnet, it uses RDC to copy delta blocks from the DP. Once the elected master starts to download the newest version of a package, it first fetches the manifest file and RDC data generated by the NomadBranch
service for that package on the DP. The RDC data contains the needs list (.needs.bin
) for all the files in the package that have changed between versions n-1
to n
. These .needs.bin
files are used to create the target files by copying blocks from the files cached locally and from the DP.
If the master becomes unavailable during this process, a re-election takes place and the new master re-downloads the needs list from the DP.
RDC on the peer
RDC file copy is done between the DP and the elected master only in a subnet. The remaining machines or peers in the subnet copies all the blocks of files modified in the package using normal P2P or local multicast.
Alternate source copy
Alternate source copy, often referred to as alt-copy, takes place when the elected master does not have the previous version of the package but another machine on the subnet has it. The elected master can still do RDC file copy by copying the required blocks using RDC_alt copy from the other machine on the subnet.
On Windows Server DPs without a primary or secondary site server, RDC must be installed using the Windows Server Manager.