Summary

An overview of Nomad features and enhancements.

On this page

Distributing software with Nomad and Configuration Manager

Nomad integrates tightly with Configuration Manager, acting as an alternate download provider on a per-package basis for software distribution, per-task sequence or per-site for applications and software updates. The Configuration Manager client requests the download of package data using Nomad where it acts purely as a download client with the execution of the program being handled by the  Configuration Manager client. The Nomad client must be installed on all  Configuration Manager client machines and on all distribution points (DP).

Full control over WAN link usage

Nomad dynamically analyzes the overall WAN traffic to ensure that it only uses a percentage of the total. It uses dynamic block sizes to allow it to take full speed advantage of high-bandwidth links while retaining its low impact on low-bandwidth links. 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.

Bandwidth throttling

Maximizing download speed for high-bandwidth links using Dynamic Block Sizes

Nomad version 6.3 introduces a new mechanism to speed up downloads for high-bandwidth links. Nomad was originally designed to run over low-bandwidth links and to minimize impact on bandwidth usage. To ensure this Nomad used a fixed block size of 32KB to avoid congestion on the link. However with today's high-bandwidth links, running with a far higher capacity than was previously thought imaginable, a fixed block size severely restricts copying efficiency.

To solve the high-bandwidth efficiency issue while still retaining minimal impact on low-bandwidth links, Nomad 6.3 introduces 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 has been changed from 32KB (0x8000) to 128KB (0x20000).

The Nomad 6.3 installer will 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

Download once to branch

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.
Download once per branch

Nomad master elections

When a software package is deployed to the branch PCs, 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 machine in the branch and on the distribution point. The machines 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.

Download resiliance

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 machines on the branch network interact to elect a new master. The elections are weighted towards the most suitable candidate using a combination of rules.

Weighted elections for resilience

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 machine's cache. The other machines 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.

Elected master resilience

See Election rules and master elections for more details about the election process.

Nomad cache

The cache mechanism 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. These packages consume disk space so management of the cache is critical. Because the 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 uses file system hardlinks between the Nomad and Configuration Manager client caches, ensuring that only a single copy of the content is retained. Hardlinks are used for all content types except Office 365 Updates, as this type of content is retained in the Office 365 Click To Run agent installation folder rather than the CCM cache folder.

Download resumption and consistency checking

To minimize repeated downloads of the same content from the Distribution Point Nomad supports download resumption and consistency checking.

Download resumption

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.

Managing intermittent internet connections

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.

Consistency checking

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.

Consistency checking

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 agent 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.

Cache management

The cache mechanism 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. These packages consume disk space so management of the cache is critical. Because the 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 uses file system hardlinks between the Nomad and Configuration Manager client caches, ensuring that only a single copy of the content is retained. Hardlinks are used for all content types except Office 365 Updates, as this type of content is retained in the Office 365 Click To Run agent installation folder rather than the CCM cache folder.

Remote differential compression integration

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.
 Efficient file updates

The Nomad Dashboard

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. 

For the dashboard to function fully, it requires that Nomad returns status messages into the ConfigMgr site database. By default, the Nomad client agent does not return any ConfigMgr status messages. Use of the dashboard Operations panels requires the  following messages are set in the agent registry StatusMsgEvents value:

  • SNO_EVT_REQUEST_STARTED (0x0000000020)
  • SNO_EVT_REQUEST_COMPLETED (0x0000000040)
  • SNO_EVT_ERROR (0x0000000004)
  • SNO_EVT_FINALSTATS (0x1000000000)

These combine to the following value:

  • StatusMsgEvents = 0x1000000064

Use of the Client Health panel also requires that the following is set in the ClientHealth registry:

  • HKEY_LOCAL_MACHINE\SOFTWARE\1E\ClientHealth SendStatusMessages = true

Both the StatusMsgEvents and SendStatusMessages settings can be implemented using the The Nomad Baseline Wizard.

IPv6 and DirectAccess support

By providing support for IPv6 environments, Nomad supports distribution to clients connected to the corporate network using the DirectAccess feature.

App-V support

Nomad supports application virtualization (App-V) applications which are deployed as streamed content by Configuration Manager 2012.

FIPS compliant communication encryption

Nomad has always provided encryption for most of its communications. Now, In Nomad version 6.0, an advanced FIPS compliant encryption algorithm has been 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.

Nomad Pre-caching

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.

Single-site download

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.

Peer Backup Assistant (PBA)

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.

Single Site Peer Backup Assistant (SSPBA)

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

Deploying Office 365 updates

Configuration Manager introduced support for Office 365 agents in Current Branch 1602. There are no additional steps to perform when you configure Office 365 update deployments and in the way you configure Software Updates and Applications in Configuration Manager to use Nomad. However, the format of the content requests passed to Nomad differ considerably from all other types of content. This section describes how Office 365 types of deployments differ in terms of ACP requirements and goes on to describe how Nomad behaves during the download.

Integrating with WakeUp

Nomad integration with WakeUp enables Nomad to share content from its machines that are holding particular content, even if those machines are shut down.

Peer copy over HTTP or HTTPS

Historically, Nomad content distribution required File and Print services to be enabled in order for it to share the content. From version 4, you could bypass these services and use the connectionless transfer protocol over the User Datagram Protocol (UDP) instead. However, this implementation was not scalable and fully secure. To overcome this limitation, peer-to-peer copy over HTTP is available from version 6.2 where each agent acts as an HTTP server and can serve content from its cache. The election process determines the master and instead of copying content from its file share, peers looking to download content make HTTP requests to the master.

Nomad FanOut

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.

OS deployment task sequences

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.

Client health

Client health is a background service that monitors Nomad clients to ensure that they are running as expected and where it encounters issues, it will attempt a self-heal or remediation. It is installed as a 1E Client Health service and like NomadBranch, its Startup Type attribute is Automatic (Delayed Start).  It reports its health checks to Configuration Manager in the form of status messages which can be viewed in the Nomad dashboard.

Nomad SECure

SECure enables content to be signed, encrypted and compressed on the DP which clients can download – content is downloaded according to the data format (0 – original, 1 – compressed or 2 – encrypted+compressed) specified in the client policy. If you intend to use this feature, you must update all Nomad clients to 6.1 or they will fail to download encrypted content. This is because older clients only supports the original unencrypted data format.

The Download Monitor

If you installed the Download Monitor in basic mode, you will only see progress bars in the UI – useful for those who only need to see the status of the downloads. If you installed it in advanced mode, you will see an extended UI – useful for administrators to troubleshooting downloads as they can connect to remote machines to view the status of the downloads and provided they have sufficient Remote Activation DCOM permissions, By default, the Download Monitor connects to the local machine.

Cloud Support

Nomad now supports the following Configuration Manager on Azure scenarios: IaaS (Infrastructure as a Service) scenario where you host your Configuration Manager 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

The Nomad Baseline Wizard is used to create a Configuration Manager Baseline from the Configuration Manager console for settings related to Nomad and Client Health.

Managing large package distribution with multicast

If you want to make more efficient use of your network when distributing the same data to many end-points, 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.