Introducing Nomad 6.3
Working with Nomad
Distributing software with Nomad and Configuration Manager
Download once to branch
Download resumption and consistency checking
FIPS compliant communication encryption
Full control over WAN link usage
IPv6 and DirectAccess support
Remote differential compression integration
The Nomad Dashboard
- App-V support
- Core features
Operational best practices
Frequently asked questions
- Feature Reference
Technical support for Nomad
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.
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.
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.
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.
See Election rules and master elections for more details about the election process.
Nomad cacheThe 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.
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.
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.
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)
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:
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.