SummaryAn overview of the fundamental concepts and terminology needed to understand what Nomad will do for you.
What is Nomad?
Nomad removes the need for distributed servers and intelligently uses only available bandwidth for all content distribution, so the business is never impacted by Configuration Manager or Windows deployments.
Nomad uses Configuration Manager console extensions to enhance the Configuration Manager Admin console, so you can configure Nomad settings, pause and resume Nomad downloads, use Nomad pre-caching and create baseline configuration items. By integrating with your OSD strategies Nomad maximizes 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. Nomad also supports content distribution for Configuration Manager and Tachyon with the 1E Client.
A new Tachyon Platform component, called 1E Content Distribution, provides support for a number of Nomad features such as Single Site Download. Nomad clients send information back to Content Distribution related to the Nomad features and the performance of Nomad. Content Distribution is a replacement for ActiveEfficiency used in earlier versions of Nomad.
In addition, with the Tachyon Platform there is the new Nomad app replacing the Configuration Manager Nomad Dashboard. The Nomad app provides a high level view of the current status of content throughout the entire network.
The picture opposite shows the high-level relationship between the Nomad components listed in the Nomad components table below.
|1E Client 5.2|
The 1E Client, includes the Nomad module which supports content distribution for Configuration Manager and Tachyon. The 1E Client includes other features and modules which are optionally enabled and configured, including:
The 1E Client is installed on each Windows device as a service, and the 1E Client Deployment Assistant (CDA) can be used with Configuration Manager to deploy it.
The Nomad app provides visibility of content distribution activity and cache status for content distributed by both Nomad and Delivery Optimization.
The Nomad app is installed through Tachyon Platform 5.2 setup. After installation the Nomad app is available on the Tachyon Platform portal homepage and can be accessed using the Tachyon DNS Alias FQDN. For example:
|1E Content Distribution|
Content Distribution is a Tachyon Consumer providing control and visibility on content deployments and delivery and is installed through Tachyon Platform 5.2 setup.
Content Distribution offers visibility for the following via the Nomad app:
The Background Channel is a Tachyon Platform 5.2 component which provides a means for the Nomad module of the 1E Client to retrieve large data items from Tachyon without loading the Tachyon Switch:
|Configuration Manager console extensions|
The Nomad Configuration Manager console extensions are installed where its Console is installed. The extensions add the custom Task Sequence steps among other Configuration Manager console extensions.
The Nomad Configuration Manager console extensions provide the following capabilities in the Configuration Manager Admin console:
The additional Nomad attributes are configured through the Configuration Manager console using custom console extensions. These add properties pages to the standard package, task sequence and client settings dialog boxes and wizards.
Nomad OSD Tools are required for integrating Nomad with OSD task sequences in Configuration Manager. The tools are installed on the CM Site server(s) and SMSProvider server(s) and install the Nomad files that get injected into a boot image.
The Nomad Download Monitor tool is useful for administrators to view the status of downloads on local and remote Nomad client devices. The tool is required only for testing and troubleshooting on selected devices, and is not required or recommended for general deployment.
Sample PowerShell scripts for populating the Content Distribution database to support the following Nomad features:
Located in the zip's Scripts folder.
|1E Nomad Task Sequence steps|
Nomad can integrate with OSD to maximize the efficiency of distributing large OS content across the network. The three areas where Nomad integrates with OSD are:
To support the above, Nomad provides a number of Task Sequence steps that can be integrated directly into your OSD Task Sequences:
Nomad integrates with the Configuration Manager (CM) client content download process. When Nomad is installed, it registers with the Configuration Manager client as an Alternate Content Provider (ACP), which means the CM client will use Nomad as an alternative to BITS when it requires content if Nomad is enabled for the requested content object. Nomad can be enabled on individual packages (including Driver Packages, Operating System Images, Operating System Upgrade Packages and Boot Images) and Task Sequences.
For Applications and Software Updates, Nomad is enabled on each client for all Applications and Software Updates through Default Client Settings. When the CM client requires Nomad-enabled content, it passes a request to Nomad, which in turn downloads the content, places it in the CM client cache and passes back to the CM client for execution. The 1E Client (with Nomad client module enabled) must be installed on all CM client machines and on all Distribution Points (DP).
Nomad dynamically analyzes the overall WAN traffic to ensure that it only uses a percentage of the total. It is also aware of mobile devices and knows the difference between wireless and wired connections and is able to select the most efficient available connection to use.
Overall bandwidth usage throttling
Nomad respects business data on the network – it detects the true end-to-end available bandwidth and monitors this throughout the duration of the download. This is calculated using a sophisticated algorithm that looks beyond the receiving capabilities of each machine's network card. If bandwidth is available, the transfer speeds up; if it becomes restricted, the transfer slows down. As a result, overall WAN availability is maximized and the impact on the critical link between the branch networks and the central network is minimized.
To avoid placing a burden on office wireless bandwidth and to use the most efficient transfer system possible, Nomad can be configured to switch from a wireless to a wired network connection automatically when one becomes available. (Please refer to Design Considerations - Managing stable LAN connections)
Maximizing download speed for high-bandwidth links using Dynamic Block Sizes
The Dynamic Block Size (DBS) feature increases block size on high-bandwidth links to get maximum efficiency, and reduces it on low-bandwidth links to reduce the impact. 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.
DBS is enabled or disabled by configuring Bit 25 in the CompatibilityFlags registry. Setting Bit 25 disables DBS and clearing Bit 25 enables DBS.
In Nomad 7.0 onwards, the DBS feature is turned off by default for new installations, and not changed for upgrades.
Prior to v6.3 the default value of BlockSize registry setting was 32KB (0x8000). From v6.3 onwards the default is 128KB (0x20000).
The installer automatically sets 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 by 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.
An overview of the Nomad cache including different methods used by Nomad peers to access the cache on the elected master. 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.
Nomad peer-to-peer content transfer uses SMB by default, which requires File and Print services to be enabled in order for it to share the content. For better security Nomad can be configured to use HTTP or HTTPS for peer-to-peer content transfer, removing the requirement for file shares. When Nomad is configured to use HTTP/S, if Peer Backup Assistant is enabled it will also use HTTP/S.
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.
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.
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 app provides visibility of content distribution activity and cache status for content distributed by both Nomad and Delivery Optimization. This includes Configuration Manager content distributed with Nomad and Software Updates content distributed with either Nomad or Delivery Optimization.
1E Content Distribution is a Tachyon Consumer, providing control and visibility on content deployments and delivery in an organization.
Nomad supports IPv4 by default, and optionally supports IPv6, which is commonly required when clients connect to the corporate network using the DirectAccess.
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 uses an advanced FIPS compliant encryption algorithm. The United States Federal Information Processing Standard (FIPS) http://en.wikipedia.org/wiki/FIPS_140-2 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 any peer that has more content than the requester to respond to the FanOut request. It is not limited to peers that have an active connection to the master.
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.
Nomad SSD uses Content Distribution. When a Nomad client downloads a package, it registers this information with Content Distribution enabling a profile to be created on which Nomad clients hold particular packages.
The Peer Backup Assistant (PBA) feature enables files and settings data to be backed-up to a peer device so that they can be maintained when the device is being migrated to a new Operating System. Using PBA, you can avoid the cost of State Migration Point servers to hold the backup data, as peer devices can be used to provide this storage. 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 use local storage on peers to temporarily store user state data during an OS deployment, removing the need for Configuration Manager State Migration Points. By default, it uses network broadcasts to identify peers with available storage on the local subnet. Single Site Peer Backup Assistant (SSPBA) uses Single Site Download (SSD) features to enable Nomad to use storage available on PBA hosts in adjacent subnets. This enables you to:
- Designate appropriate devices to provide the Nomad PBA data store for all devices 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.
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 directly from the cloud.
The integration with WakeUp feature is not supported in the Tachyon 5.2 release. This feature is under consideration for re-design and may be available in future versions of Nomad.
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.
The Nomad Download Monitor tool (also known as NomadBranchGUI) is useful for administrators for troubleshooting downloads as they view the status of downloads on local and remote Nomad client devices.
Nomad supports the following Configuration Manager (CM) on Azure scenarios:
- Infrastructure as a Service (Iaas) - your host CM infrastructure servers are in Azure virtual machines
- Cloud based Distribution Points - CM distribution points are hosted in Microsoft Azure as a cloud service
- Cloud Management Gateway (CMG) - CM management points are hosted in the cloud.
The Nomad Baseline wizard is used to create a Configuration Manager (CM) Baseline from the Configuration Manager console for settings related to Nomad.
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.