The Nomad cache is configured as a share that enables peer-to-peer distribution of downloaded content. Nomad provides control over the accounts that have access to the share and also provides an advanced Nomad FanOut mechanism that can overcome the connection limit to shares on workstations to ensure that content is distributed efficiently and securely.
If Nomad is configured to use exclusively HTTP/HTTPS for peer copy, then the Nomad share is not created by the NomadBranch service.

Enhanced Nomad share security

Nomad leverages native Windows security to define which accounts have access to the Nomad share. In Nomad’s default configuration, a Nomad share is created when the Nomad service is started and removed when it is stopped. The default Nomad settings also grants both Authenticated Users and the SMSNomadP2P& Nomad share account read-only access to the its share.

In earlier versions of Nomad, further restricted access to the Nomad share could only be done using custom share permissions. The major disadvantage to this approach was that the Nomad service no longer managed the Nomad share and it had to be created and managed through other methods. So, if you wanted to exclude Authenticated Users from the Nomad Share permissions, you must take over the management of the share.

From Nomad 6.0 onward, a cache access security option has been implemented that is controlled using the AuthenticatedUsers registry value. This optionally restricts access to the Nomad share to just the SMSNomadP2P& Nomad share account, thereby excluding Authenticated Users from the Nomad share permissions but still leaves Nomad in control of the creation, management and removal of its share.

Nomad Branch service and the Nomad share

The Nomad share is created each time the Nomad Branch service starts and removed when it stops. When the Nomad Branch service starts:

  • A share called NomadSHR for the Nomad cache folder is created. The share is removed when the Nomad Branch service stops. If this share is created on a workstation, only 6 concurrent users can access it. If the share is created on a server, there is no limitation.
  • A local user account called SMSNomadP2P& is created with its password attribute set to Password Never Expires. This account is not removed when the Nomad Branch service stops. The password for this account is changed each time the Nomad service restarts and is made up of 14 characters using a combination of upper and lower case alpha-numeric characters. This account is not a domain user and does not have the logon locally privilege. Account details are requested by peer clients during the master election process
  • If the AuthenticatedUsers registry value is configured to use the built-in security principal Authenticated Users, the NTFS permissions on the Nomad cache folder are updated so that Authenticated Users is granted Read and Execute, List folder contents and Read permissions for the folder, its subfolder and files. These NTFS permissions are not removed when the Nomad Branch service stops.

Share Permissions for NomadSHR is configured as Read-only for the local SMSNomadP2P& user account and optionally a built-in security principal as specified by the AuthenticatedUsers registry value. The default is:

  • local user account SMSNomadP2P&
  • built-in security principal Authenticated Users

The default location for the Nomad cache is C:\ProgramData\1E\NomadBranch. The CACHEPATH installer property is also used to configure the location of the Nomad Cache, which is stored in the registry value LocalCachePath.

You can use the SPECIALNETSHARE installer property or update the SpecialNetShare registry value so that Nomad hides the Nomad share. If you do this, the share will be renamed NomadSHR$ and you will need to update all Nomad installations to use the hidden share.

Nomad can also be configured to use the machine account for peer connections instead of the local SMSNomadP2P& account by using the SPECIALNETSHARE installer property or by updating the SpecialNetShare registry value. If the machine account is used, the local SMSNomadP2P& account is not created. Machine$ accounts in trusted domains are considered as Authenticated Users – the AuthenticatedUsers registry value must include Authenticated Users. Peer clients must be in trusted domains.

Use the AUTHENTICATEDUSERS installer property or update the AuthenticatedUsers registry value to configure read-only access to the Nomad share for Authenticated Users (default), Everyone or neither in addition to the Nomad Share Account (SMSNomadP2P&). If Authenticated Users is selected, additional NTFS permissions are also configured for Authenticated Users on the Nomad cache folder.

The difference between Authenticated Users and Everyone depends on the OS version but in general Everyone includes Authenticated Users plus Guest.

Domain controllers

When Nomad is installed on a domain controller (DC), it does not create the SMSNomadP2P& account and does not create the Nomad share. This is because it is not possible to create a local account on a DC. Nomad will not respond to elections and cannot be elected as a master.

  • If software is targeted at a DC, Nomad downloads the content from the distribution point (DP)
  • If the DC is also a DP, Nomad continues to process LsZ files and respond to Nomad clients as normal

Custom share permissions

The SpecialNetShare registry values enables administrators to create their own share called NomadSHR, set the user limit and permissions. The Nomad cache is shared as NomadSHR, giving read access to the local Nomad share account and authenticated users. This enables new peer connections to be established and also allows access to the cache for computers with existing connections.

Share permissions can be configured on the share and requires the minimum Read-only permission for

  • the local user account SMSNomadP2P& if not using the machine account
  • Built-in security principal Authenticated Users if using the machine account

NTFS security can also be set on the Nomad cache folder and requires these minimum permissions:

  • Built-in security principal SYSTEM requires Full control permission (because the Nomad Branch service uses the local system account)
  • Local group Users requires Read & execute, List folder contents and Read permissions
  • Local group Administrators requires Full control permission

In addition, if using the built-in security principal Authenticated Users, as required when using the machine account, it requires NTFS security permissions Read & execute, List folder contents and Read.

Hard linking

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 the LocalCachePath registry value which is set during installation using the CACHEPATH installer 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