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

On this page

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.

As outlined above, Nomad combines the use of elections and cached storage to ensure that content is only downloaded once per subnet over the WAN. Further efficiencies can be made by implementing the Single Site Download advanced feature to ensure that downloads over the WAN only occur once per site.

Election rules and master elections

When you install Nomad on computers within a remote branch, part of the installation includes a service called NomadBranch.exe. This service runs continuously on the branch computers and manages the process of electing masters and transfers the download between peers.

As a package is deployed to computers within a remote branch, one branch Configuration Manager client is elected as the Nomad master. This client downloads the package to its local cache and the other clients on the remote branch IP subnet uses this local master as an alternative distribution point. The other clients can either connect to the local master over HTTP[S] or they connect to its cache folder over Microsoft Server Message Block (SMB) protocol and download the package to their own cache.

Standard Configuration Manager behavior remains unchanged when using Nomad. Clients will not start to download the package until they have received the Configuration Manager deployment, subject to the usual polling cycle.

However, if this elected master became unavailable, the branch computers hold an election to nominate another master. The election process starts when the master is discovered to be unavailable.

A master is elected based on election rules including percentage of the package already downloaded and election weighting. Any one of the remote Nomad clients can be elected as a master, even when they are half way through downloading a package. In this way, software is downloaded once over the WAN and distributed locally.

Cached packages are kept on the local machine. If disk space becomes restricted, a separate automatic cache cleaning process is initiated which deletes packages cached by the peer-to-peer process.

Election rules

Elections for a master occur on a per package basis and are called for the following reasons:

  • Whenever any Configuration Manager deployment with Nomad enabled in the package properties starts
  • When a machine which is copying content from a master notices that the master is no longer available – this may happen if the master is switched off or disconnected from the network
  • Every 5 minutes while a master is actively downloading to ensure a more suitable master (one with more content than the currently elected master) has not been introduced to the network since the last election

The outcome of an election is decided using the following criteria in order of precedence:

  • Percentage of content already cached (it is only ever deemed to be 100% once it has been verified)
  • Election weighting (the higher weighting value wins)
  • Current master
  • Time since cache was last verified by Nomad
  • System uptime (amount of time the computer has been up and running)
  • Computer initiating the election
  • Computer name (alphanumeric)

Election weighting

Nomad performs automatic weighting depending on its situation, according to the criteria listed below, and stores the value in memory (not registry).

  • 61 – the agent is running on a server OS and it is not a domain controller (DC)
  • 40 – the agent is running on a laptop
  • 30 – the agent is running on a wireless network
  • 10 – the agent is running on WinPE
  • 50 – default

Although we do not recommend it, under certain circumstances, it may be advantageous to influence the automated wieighting process in order to increase or decrease a machine's probability of being elected a master. For example, if you want a machine with higher processing power to become a master, or to prevent a critical server becoming a master. If you have a reason to influence elections, use this technique in exceptional circumstances and only after testing has shown that you need to make a particular machine more or less likely to be elected as a master for specific operational reasons. Nomad is already quite efficient in the way it elects a master and needs very little intervention in this process. You can influence the election weighting by updating the P2PElectionWeight registry value for certain machines.

  • The registry key is located at: HKLM\software\1e\NomadBranch\P2PElectionWeight

You should also consider the following points before you influence the weighting:

  • The weighting does not guarantee that the more heavily weighted machines will win the election – they may be turned off or another local peer may have already cached more of the requested content
  • The final weighting value used by the machine during an election may differ from the registry value as Nomad will automatically adjust it depending on the chassis and the network connection used.
  • It may also take some time to modify the registry values for your network as each candidate machine needs to have its election weighting modified locally.

The range for this registry value must be between 0 and 99 inclusive.

Sensitive server weighting

You can exclude machines from the election process by updating the P2PElectionWeight registry value to 0 (zero) and restarting the service – if you do not restart the service, the update will not take effect and the machines are still available for election. Machines with this registry value will not respond to election requests and are never considered candidates for elections. We also recommend you set the SSDEnabled registry value to 1 if you are using the single site download feature as this will enable the device to consume content from an SSD peer but not be a provider.

Nomad on DCs will not respond to elections and cannot be elected as a master. This is because it is not possible to create the local SMSNomadP2P& account on a DC and allow it to become a Nomad master. Therefore, sensitive server weighting is not applicable to DCs. The topic on Nomad scenarios illustrate how elections are carried out and how it ties in with downloading installation packages.

Inhibiting sites and subnets

You can also define subnets and AD sites where machines will download but not participate in Nomad election. This feature is useful for sites that have:

  • A local DP
  • A VPN without isolation. Typically, VPN solutions isolate each client using single-node subnets (i.e. each client is in its own subnet with a 32-bit subnet mask). This is to prevent broadcast traffic between VPN clients that are typically geographically dispersed and not on the same local network. If the VPN solution is not configured in this manner and clients get an IP address with a subnet mask less than 32 bits, broadcasts can be exchanged between the VPN clients allowing Nomad to elect a master that is not on the same local network.