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.
Nomad cache is used in a number of deployment scenarios, for example scenarios and how you can monitor those deployments using the Nomad app refer to:
Hard links
Nomad uses file system hard links between the Nomad and Configuration Manager client caches, ensuring that only a single copy of the content is retained. The use of hard links can be disabled using the NoHardlink setting.
Hard links 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
Content downloaded from Cloud Distribution Points
A hard link is the file system representation of a file by which more than one path references a single file in the same volume. Nomad uses this technique when making files in its cache available to the Configuration Manager cache if both of them are on the same volume and hard linking is not disabled. Both caches will hold the files but only uses one footprint on the physical volume. The Nomad cache is defined in theLocalCachePathregistry value which is set during installation using theCACHEPATHinstaller property. If these caches are on different volumes, or hard linking is disabled, then Nomad copies content to the Configuration Manager cache.
Irrespective of whether hard linking is used or not, the following applies:
The Configuration Manager client and Nomad Branch each independently manages the content in their respective cache folders
When Nomad removes content from its cache as part of cache management, it also removes the same content from the Configuration Manager cache
When Configuration Manager removes content from its cache, content in the Nomad cache is not purged
Content downloaded directly by the Configuration Manager client (outside of Nomad) is not hard linked or copied to the Nomad cache
If the Configuration Manager client does not have sufficient space in its cache, it will not request a Nomad download.
Peer access methods
Nomad uses peer-to-peer connections to enable Nomad peers to access the Nomad master's cache. Nomad can share content with peers either through a file share (using Windows File and Printer Sharing Services) over SMB, or through an HTTP web service implemented in the Nomad client. Nomad also supports a 'connectionless' option for sharing content over UDP, but this should only be used as a last resort if SMB or HTTP/S are not viable in your environment.
Due to the complexity of network environments, Nomad provides some low-level control over the way the P2P communications are handled to help overcome certain scenarios that may arise. Specifically Nomad has a number of peer-to-peer connection related enhancements that enable it to work where:
File and Print Sharing Services are disabled
The connections may switch between wired and wireless communications
A multi-forest environment where peer computers from different forests may co-exist in the same subnet and are unable to access the Nomad master share using its hostname alone
Large files are being transferred.
HTTP/S
Nomad can be configured to use HTTP or HTTPS for all P2P sharing – thereby eliminating Nomad's dependency on SMB and File and Printer Sharing Services. Nomad also supports certificate-based client authentication, which eliminates the local SMSNomadP2P& account previously required for clients to authenticate with the elected master.
This is the recommended method of peer sharing content.
Note
For more detail please refer to Peer copy over HTTP or HTTPS.
SMB and File and Printer Sharing Services
This is the original and default method for Nomad peer sharing, which uses SMB and requires File and Printer Sharing Services.
Note
For more detail please refer to The Nomad share.
Connectionless P2P
Nomad can be configured to bypass these services and use the connectionless transfer protocol over the User Datagram Protocol (UDP) instead. Connectionless P2P does not use authentication and is approximately five times slower than SMB. This transfer method is only recommended for environments where other methods are not available.
To enable Connectionless P2P update the Nomad P2Penabled registry value on all Nomad clients to:
0x0000 – P2P disabled
0x0002 – Enable connectionless P2P server
0x0004 – Enable connectionless P2P client.
In most cases both P2P server and P2P client should be enabled, by setting 0x0006 (decimal 6), as shown below:
Switching between wireless and wired network connections
When network connections are switched between wireless and wired, Nomad may encounter problems accessing the share. Problems are likely to occur if DHCP uses a short lease time and the DNS does not reflect these changes quick enough. To mitigate these issues, Nomad has support for net literal names (IP addresses) for identifying its shares. Nomad clients normally use the elected master's hostname to connect to the NomadSHR in order to download the LSZ, LST and package files.
To configure Nomad to use net literal names (IP addresses) when connecting to peer shares, update the P2Penabled registry value to include:
0x0001 – P2P enabled
0x0008 – Enable use of net literal names (IP addresses).
For example, P2P enabled (0x1) plus enable use of net literal names (0x8), by setting 0x0009 (decimal 9), as shown below:
Multi-forest environments
By default, Nomad clients use the master's hostname to connect to the master in order to retrieve the package and signature files.
In a multi-forest environment computers from different forests may be present in the same subnet as the peers and are not able to connect to the master using just the hostname. In this scenario, Nomad should be configured to use FQDN for peer-to-peer connections. For this to work, it is necessary that the reverse lookup for IP addresses is correctly configured and running. If this is not available, Nomad reverts to using the IP address for its connection to P2P shares.
To configure Nomad to use FQDN when connecting to peer shares, update the P2PEnabled registry value to include:
0x0001 – P2P enabled
0x0010 – Enable use of FQDN name.
For example P2P enabled (0x1) plus enable use of FQDN (0x10), by setting 0x0011 (decimal 17), as shown below:
