Maximizing download speed for high-bandwidth links using Dynamic Block Sizes
In Nomad 7.0 the Dynamic Block Size feature is turned off by default for new installations and the default block size has been set to 128KB. For upgrades the DBS and BlockSize settings are retained from the previous version.
The Dynamic Block Size feature can be enabled or disabled by configuring Bit 25 in the CompatibilityFlags registry. Setting Bit 25 disables DBS and clearing Bit 25 enables DBS.
To solve the high-bandwidth efficiency issue while still retaining minimal impact on low-bandwidth links, Nomad 6.3 introduced a mechanism called Dynamic Block Size (DBS). Using DBS, Nomad is able to automatically decide the appropriate block size for a given link bandwidth and also adjust it as needed during the download if the link conditions change. As a result, Nomad is far more efficient and faster on all types of connection bandwidths while retaining its minimal impact on other link traffic.
To make DBS perform at its highest level, in Nomad 6.3 the default value of BlockSize registry setting was changed from 32KB (0x8000) to 128KB (0x20000).
The Nomad 6.3 installer automatically set this to 128KB for both fresh installs and upgrades from previous versions. The only exceptions to this are:
- It will use the specified value if the BLOCKSIZE property is used in the installation command line or in a MST transform, when doing a fresh install or upgrade
- It will retain the previous value of BLOCKSIZE if it was set to anything other than 32KB (the older default), when doing an upgrade.
Nomad ensures that software packages are only ever copied once per branch over the WAN – utilizing local computers as temporary file caches to distribute the software locally. This reduces the bandwidth required for delivering software updates and means that small offices or sites connected via poor network links can receive software updates more reliably. The Nomad clients with local copies of the package can themselves act as the master if the need arises. This significantly reduces the number of Configuration Manager servers required to manage a Configuration Manager hierarchy, thereby reducing initial and ongoing maintenance costs.
Nomad master elections
When a software package is deployed to the Nomad clients, an election is held per subnet in the branch to find an appropriate Nomad master, this Nomad master then downloads the software. The software is stored in the Nomad share which is then accessed by the other Nomad clients on the same subnet that require the software package.
Nomad is installed on each computer in the branch and on the distribution point. The computers on the branch network elect a local master. This acts as the single contact point for downloading packages from the distribution point and handles the local redistribution.
It is possible that a particular Nomad master may be affected in some way during the download. It could be turned off or disconnected from the network for example. If this is the case Nomad ensures that the download continues.
During download, elections continue to be held periodically to determine if the current Nomad master is still the most suitable candidate. If the local Nomad master is affected some way, for example if it is turned off during a download, the other Nomad clients on the branch network interact to elect a new master. The elections are weighted towards the most suitable candidate using a combination of rules.
Once a new master is elected, the download continues to this new master starting from the point at which the download is currently at in that client's cache. The other treat this new master in exactly the same way as the previous master. In fact, if the previous master is turned back on, it may receive the rest of its interrupted download from the new master instead.
To minimize repeated downloads of the same content from the Distribution Point Nomad supports download resumption and consistency checking.
Nomad downloads include checkpoint recovery, so if the connection to the distribution point is disrupted during a download, it is resumed when the connection is next available.
Download resumption starts from the point it had reached when the connection was lost. This means that no previous time spent downloading the package is wasted.
Nomad must be installed on all the Configuration Manager DPs. This not only lets central multicast work, but also enables package file checksums to be calculated centrally allowing efficient recovery from file transfer issues if one exists. The central creation of the checksums also minimizes the computational overhead.
Nomad uses manifest files to describe the download contents of Configuration Manager applications and packages. This enables it to provide file-level transfer and, when integrated with Configuration Manager remote differential compression (RDC), file delta downloads. The Nomad client automatically generates a manifest for each version of each package. The generation request occurs as the first Nomad client attempts to download the newest version of a package.
The Nomad cache is essential to Nomad's download once to branch feature. The cache enables Nomad to hold its downloaded content so that it can be distributed locally to other Nomad peers. The Nomad cache contains downloaded content (such as packages, applications, and software updates) which can vary in size from relative small patches to rather large OS image files.
The downloaded content in the Nomad cache consume disk space therefore management of the cache is critical. Because files may be re-used and distributed to other devices on the same subnet or site, the simple solution of deleting the files as soon as they have finished downloading and executing is not sufficient. Instead Nomad has a sophisticated cache cleaner utility that automatically but intelligently maintains control over the cache's disk usage.
The Nomad cache is configured as a share that enables peer-to-peer distribution of downloaded content. Nomad provides control over the accounts that have access to the share and also provides an advanced Nomad FanOut mechanism that can overcome the connection limit to shares on workstations to ensure that content is distributed efficiently and securely.
An overview of different methods used by Nomad peers to access the Nomad cache on the elected master.
Not only is Nomad aware of the file level differences between different versions of a package so that only changed files are downloaded, it is also aware of the differences within individual files. This is sometimes known as binary differential replication or binary deltas but is more commonly known as remote differential compression (RDC) 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.
The Nomad Dashboard is a collection of interactive tiles made available in the Configuration Manager console that provides you with a global view across your network of Nomad status and latest operation details.
By providing support for IPv6 environments, Nomad supports distribution to clients connected to the corporate network using the DirectAccess feature.
Nomad supports application virtualization (App-V) applications which are deployed as streamed content by Configuration Manager.
Nomad has always provided encryption for most of its communications and in Nomad 6.0 an advanced FIPS compliant encryption algorithm was made available. The United States Federal Information Processing Standard (FIPS) is a standard that defines security requirements for software used by the U.S. federal government. It stipulates that applications that encrypt any sensitive data should use only a certain set of approved encryption algorithms.
Pre-caching lets you pre-load the Nomad caches of particular machines directly from the Configuration Manager console. This enables downloads to be available on the branch prior to a deployment taking place, which can be very useful in large-scale deployment scenarios.
Windows imposes a limit on the number of concurrent connections on the Nomad share. The FanOut feature compensates for this limitation by enabling peers connected to the master to themselves allow connections to other peers requiring the download so that more peers can be updated at the same time.
Nomad's single-site download (SSD) feature ensures a download across the WAN only happens once per site. It does this by maintaining information about which subnets are neighbors of each other (accessible on LAN rather than WAN), so that when an elected master considers a download from a DP rather than a peer in its subnet, it can discover which other local subnets already has the package. These subnets are typically at a single customer site, specifically a single geographical location. The sequence below describes what happens during SSD.
The Peer Backup Assistant (PBA) feature enables files and settings data to be backed-up to a peer computer so that they can be maintained when the computer is being migrated to a new Operating System. Using PBA, you can avoid the cost of specifically provisioning state migration points or servers to hold the backup data, as peer computers can utilized to provide this feature. The risk of losing user data through the migration process is also greatly reduced in the process.
Peer Backup Assistant (PBA) enables Nomad clients to act as equivalents to Configuration Manager state migration points. It sits on top of Nomad's peer communication mechanism which is normally limited to the local subnet and prevents neighboring subnets on the same site from being used for potential Nomad PBA stores. Single-Site Peer Backup Assistant (SSPBA) uses the single-site download features to enable PBA data stores to reside not only on the local subnet but also on nearby subnets. This enables you to:
- Designate appropriate machines to provide the Nomad PBA data store for all machines on the site, not just the local subnet
- Avoid the issue where clients on particular subnets do not have sufficient disk space to offer the role of a Nomad PBA data store
Support for Software Updates
Configuration Manager introduced support for Office 365 agents in Current Branch 1602, and Nomad introduced support in version 6.1.100. This section describes how Office 365 deployments differ in terms of ACP requirements and goes on to describe how Nomad behaves during the download.
As Windows 10 cumulative updates get very big, very quickly (often in excess of 1GB a few months after any given Feature Upgrade), Microsoft started publishing express installation files for these updates in addition to the traditional full update files. Configuration Manager introduced support for Windows 10 Express Installation File updates in Current Branch 1802 hotfix KB4163547.
Express installation files are a much larger payload on the Distribution Point compared to traditional software update files, but the feature enables clients to download delta byte-ranges from these files, so each month the amount of data a client has to download is typically much smaller. Configuration Manager Current Branch can be configured to support express installation files (refer to https://docs.microsoft.com/en-us/configmgr/sum/deploy-use/manage-express-installation-files-for-windows-10-updates for more details).
With the release of Windows 10 1809, Microsoft replaced express update files with a new way of managing deltas within software updates. In Configuration Manager 1902 the Enable installation of Express installation files on clients option in Software Update Client Settings was replaced with Allow clients to download delta content when available.
Nomad supports the download of Express installation files and delta content for updates.
This feature enables Nomad to download content from Windows Update / Microsoft Update (WUMU). Starting in CB version 1806, software updates can be deployed to devices without first downloading and distributing content to Distribution Points, instead clients download updates direcly from the cloud.
Nomad integration with WakeUp enables Nomad to share content from its machines that are holding particular content, even if those machines are shut down. One reason why peers in the local subnet may not respond to the request even though they have content in their caches is that they are offline (shutdown, in hibernate or sleep mode). However, if WakeUp is integrated, the Nomad client would know which offline machine has the content and can wake it up when it queried ActiveEfficiency. The wake up list is maintained by ActiveEfficiency and is the same list that SSD uses. Separate lists of peers are returned for subnet and site. This feature requires Nomad SSD to be enabled, an ActiveEfficiency server and a NightWatchman infrastructure. The feature is enabled during installation of NightWatchman Management Center. Please refer to the Nomad Preparation for requirements.
Nomad can integrate with OSD strategies to maximize the efficiency of distributing large OS content across the network. It does this by providing a number of Task Sequence steps that can be integrated directly into your OSD Task Sequences.
Big Bang have integrated Nomad into their Universal Imaging Utility (UIU) product to search for driver content on peers. Check out the 1E blog Taking the worries out of managing drivers during Windows 10 upgrades for a quick overview, take a look at https://www.bigbangllc.com/The-UIU or reach out to https://www.bigbangllc.com/Support for further information.
Nomad SECure enables content to be compressed and signed, and also encrypted on the DP which clients can download. If you intend to use this feature, you must update all Nomad clients to 6.1 or later, or they will fail to download encrypted content. This is because clients older than 6.1 only supports the original unencrypted data format.
The Download Monitor tool (also known as NomadBranchGUI) is useful for administrators to troubleshooting downloads as they view the status of downloads on local and remote Nomad client computers.
Nomad supports the following Configuration Manager on Azure scenarios:
- IaaS (Infrastructure as a Service) scenario where you host your Configuration Manage infrastructure servers in Azure virtual machines
- cloud-based distribution points, where System Center Configuration Manager distribution points are hosted in Microsoft Azure as a cloud service
- Cloud Management Gateways, where Configuration Manager management points are hosted in the cloud.
The Nomad Baseline Wizard is used to create a Configuration Manager Baseline from the Configuration Manager console for settings related to Nomad.
If you want to make more efficient use of your network when distributing the same data to many devices, you may want to consider using multicast – it may already be used in your environment for multi-media tasks such as providing video content. Multicast is a complex technology that requires complete buy-in from both your system and network administrators.
Nomad integrates with Tachyon to enable pausing or resuming Nomad downloads throughout the estate. This feature provides a safety measure for situations when a faulty or harmful deployment is made by mistake. In such situations pausing Nomad downloads on all targeted devices can prevent or limit the potential damage. It can also be used to facilitate troubleshooting, making it possible to pause all Nomad downloads across the network and enable IT teams to eliminate content distribution from their assessment of network bandwidth usage.