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 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.
Refer to Deploying software with Configuration Manager for example scenarios about deploying Applications and Packages where Nomad is integrated with Configuration Manager and how you can monitor those deployments using the Nomad app.
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.
See Election rules and master elections for more details about the election process.
Nomad cache
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.
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.
Note
Refer to Nomad cache for more details, including peer access methods, switching between wireless and wired network connections and multi-forest environments.
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 Nomad clients 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.
Note
Standard Configuration Manager behavior remains unchanged when using Nomad. 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 Nomad clients 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 halfway through downloading a package. In this way, software is downloaded once over the WAN and distributed locally.
Cached packages are kept on the local computer. 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 computer 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). The higher the value, the greater the probability of winning the election.
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
If necessary, you can use the P2PElectionWeight registry setting to increase or decrease a Nomad client's probability of being elected a master. The range for this registry value must be between 0 and 99 inclusive. If not set, Nomad uses the values listed above.
The registry key is located at:
HKLM\software\1e\NomadBranch\P2PElectionWeight
To take effect after setting the registry value, the client sevice must be restarted.
This method is not recommended because Nomad is already quite efficient in the way it elects a master and needs very little intervention in this process. However, you may want to reduce the chance of computers with low processing power, or prevent critical servers, becoming a master.
You should also consider the following points before you influence the weighting:
Use this technique in exceptional circumstances and only after testing has shown that you need to make a particular computer more or less likely to be elected as a master for specific operational reasons.
Choose the simplest weighting strategy possible - for example, set servers at 90, laptops at 10 and workstations at 50.
The weighting does not guarantee that the more heavily weighted computers 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 computer during an election may differ from the registry value as Nomad will automatically adjust it depending on the chassis and the network connection used.
In the event you no longer need the values to be set, you should remove it and restart the service to resume dynamic election weighting.
Setting to 0 is a special case called Sensitive server weighting designed for use on critical servers. The 0 value prevents Nomad from acting as master, and devices with this value will not respond to election requests.
Sensitive server weighting
You can exclude computers 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 computers are still available for election. Computers 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.
When using the default Nomad configuration, Nomad will not respond to elections on a DC 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. To prevent Nomad from becoming a master, set its weighting to 0. The topic on Nomad scenarios illustrate how elections are carried out and how it ties in with downloading installation packages, refer to Basic Nomad behavior in a simple environment.
Inhibiting sites and subnets
You can also define subnets and AD sites where computers will download but not participate in Nomad election, refer to Design Considerations: Inhibiting subnets and sites. This feature is useful for sites that have a local DP or 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.