Summary

Information that will help you design and plan the implementation of Nomad in your organization.

This page is part of the design phase of implementation.



Nomad architecture

The architecture for Nomad. This describes the customer-facing components and how they connect to provide the functionality in Nomad.

For a full description of Tachyon Platform Stacks, their components, the clients and how they connect to provide Tachyon Platform features, refer to Tachyon Platform 5.2 - Tachyon Architecture.

Installation scenarios

New installation

Nomad is included with Tachyon Platform, so you'll need to use the Tachyon setup wizard to install. To activate Nomad, you'll need a valid license file.

Before installing Tachyon Platform, please refer to Tachyon Platform 5.2 - Implementing Tachyon Platform, this includes details of server sizing. The addition of Nomad does not affect sizing, as it is included with the Tachyon Platform.

Existing Nomad installation

If you already have Nomad configured in your environment, you can install Nomad 7.1 as a local consumer application on your existing Tachyon web server, if it is Tachyon Platform 5.2

Please refer to Upgrading Nomad for guidance on:

  • Upgrading to the latest version of Nomad within a Configuration Manager operating environment
  • Additional guidance on upgrading ActiveEfficiency to Content Distribution
  • Upgrading Configuration Manager when Nomad is in use.

Infrastructure dependencies

Tachyon Platform

These features require the full deployment of the Tachyon Platform infrastructure, including Master and Response Stacks, with optional DMZ Server for Internet based clients.

Tachyon Platform is installed using Tachyon Setup, which should also be used to install the following components, included in the Tachyon Platform download zip.

  • Nomad app - this consumer application replaces the legacy Nomad Dashboard
  • Content Distribution - this web service is required by the Nomad app, and replaces the legacy ActiveEfficiency Server.

Please refer to:

Implementing a Tachyon Platform DMZ server

If you have internet based clients you will need a Tachyon Platform DMZ Server to support your Internet-facing Tachyon clients. The DMZ Server is a type of Response Stack used to provide Tachyon Real-time and Inventory services to Internet-based clients. For details about installing a Tachyon DMZ Server to support Internet-facing Tachyon clients refer to Tachyon Platform 5.2 - Implementing a Tachyon DMZ Server.

Tachyon client integration with Nomad

When Tachyon and Nomad clients are both enabled in the 1E Client, then the clients and Tachyon instructions will - by default - automatically use Nomad to download content. Tachyon client uses Nomad to download content from the Tachyon Background Channel, or from any website, without any dependency on Configuration Manager.

For more information, from a Tachyon perspective, please refer to Tachyon Platform 5.2 - Design Considerations: Downloading content and Nomad integration.

Nomad components

To understand what Nomad can do for you please refer to Nomad overview and Nomad fundamentals. Once you have decided what features you will use, then you will need to deploy relevant components to clients and servers.

In addition to the Nomad app and Content Distribution components described above, the following sections provide a brief overview of Nomad components:

1E Client

The Nomad client is the core component of Nomad, and can be used on its own without any other components.

Nomad client is part of the 1E Client and is only supported on Windows devices. You must deploy the 1E Client (with Nomad enabled) to:

  • In-scope client devices - use 1E Client Deployment Assistant 1.6 (CDA) to help deploy 1E Client via Configuration Manager
  • Configuration Manager Distribution Points - use the installer transform file created by CDA edited as required to suit the type of DP, ensuring LSZ Generation is enabled (enabled by default in SpecialNetShare).

The 1E Client also includes the following clients that must be enabled to support optional Nomad features:

  • Tachyon client - provides real-time features required by the Download Pause feature
  • Shopping/WSA client - provides Windows Servicing Assistant (WSA) features
  • PXE Everywhere Agent - allows computers to automatically boot up into Windows PE, which then allows a Windows Operating System to be installed.

Please refer to:

Configuration Manager Console extensions

The extensions must be installed on all computers where Configuration Manager administrators use their CM Admin Console to :

Please refer to:

Configuration Manager OSD Tools

The Configuration Manager OSD Tools (also known a NomadBranch Tools) must be installed on all Site Servers (except Secondary) and all SMS Provider servers. Specifically servers which Configuration Manager Consoles may connect to.

The installer copies the Nomad binaries to the ConfigMgr site installation folder .\OSD\bin\<Architecture> on the SMS Provider server. This enables the files to be injected into the OSD boot image allowing Nomad to be used during the WinPE deployment phase. The installer will also extend the Configuration Manager Site WMI namespace to include definitions of the 1E Nomad built-in task sequence steps.

Please refer to:

Download Monitor tool

Also known as NomadBranch GUI, the Nomad Download Monitor  tool is optionally  installed on client devices alongside the Nomad client, and is used for troubleshooting and testing only. It should not be installed generally in your network.

Client deployment and common configuration settings


1E Client Deployment Assistant (CDA)

The 1E Client Deployment Assistant (CDA)  is the recommended method of deploying 1E Client to Windows computers if you have Microsoft System Center Configuration Manager, and also for deploying 1E NightWatchman Agent. 1E Client may be deployed independently using alternative software distribution methods.

The CDA creates Packages, Applications, empty Collections and Deployments with custom Windows Installer transforms to simplify the installation and initial configuration of the 1E Client and its modules. You can then simply add devices into the Collections to upgrade Nomad on those devices.

The wizard allows you to configure commonly used settings. The template .mst contains many additional installer properties, but not all of them. You should review your requirements and decide which installer properties to modify or add. The full list is available in Nomad installer properties

Some of the less common settings are described in more detail further below.

In addition to deploying 1E Client (with Nomad client module enabled) on all computers and on Configuration Manager Distribution Points, the following are also required:

  • Nomad tools installed on Configuration Manager sites and SMS Providers
  • Nomad Configuration Manager Console extensions on Configuration Manager site servers any other computer that has the Configuration Manager Console installed.

For full documentation on the 1E Client Deployment Assistant refer to 1E Client Deployment Assistant 1.6 - Introducing 1E Client Deployment Assistant, including:

  • Preparation
  • Running the wizard - where you configure commonly used settings, for example Nomad client settings below
  • Configuration Manager objects
  • Supported platforms
  • Installer properties.


Nomad client settings

Nomad client installer properties are associated with each area of functionality in Nomad, and are mostly configured in the registry, it's only the enabling of Nomad and Tachyon that's completed in the 1E Client configuration file. 

They can be specified during installation of the 1E Client as Windows installer properties, and must be specified in upper-case. Settings that exist in the 1E Client configuration file can be mixed-case, and can be reconfigured after installation using 1E Client command-line parameters.

For a full list of the 1E Client installer properties available for the Nomad client module refer to Nomad client alphabetic installer properties.


Common configuration settings

These are settings that most frequently vary between organizations, and are therefore presented as options in CDA.   

Nomad client settings in CDA



Nomad client settings in 1E Client installer

Each of the following features is optional. Although not a requirement for generally using Nomad, Tachyon Platform 5.2 must be installed and available before you can use certain Nomad features. 

Nomad featureDescriptionInstaller propertiesInfrastructure requirement

Hidden Nomad Share

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.

MODULE.NOMAD.SPECIALNETSHARE

Single Site Download (SSD)

When SSD is enabled in the CDA wizard, then Content registration is also enabled.


MODULE.NOMAD.SSDENABLED

MODULE.NOMAD.CONTENTREGISTRATION

FanOut

MODULE.NOMAD.SPECIALNETSHARE

Peer Backup Assistant (PBA)

The Peer Backup Assistant (PBA) feature enables files and settings data to be backed-up to a peer computer so that they can be maintained when the computer is being migrated to a new Operating System.

Using PBA, you can avoid the cost of State Migration Point servers to hold the backup data, as peer computers can be used to provide this storage. The risk of losing user data through the migration process is also greatly reduced in the process.

MODULE.NOMAD.SSPBAENABLED

Prevent Failing Over to BITS

MODULE.NOMAD.SUCCESSCODES

Single Site Peer Backup Assistant (SSPBA)

MODULE.NOMAD.SSPBAENABLED

Use FIPS Encryption

FIPS encrypts the following types of Nomad data:

Data sent over a network in peer-to-peer communications, including:

    • Election communications
    • Connectionless data transfer
    • Nomad FanOut requests
    • Sign-on/sign-off communication
    • SSD Package Status Requests
    • PBA communications.

MODULE.NOMAD.USEFIPS

Delivery Optimization Reporting

Monitor and report on Delivery Optimization (DO) downloads. This feature is only supported in full versions (OS with UI) of Windows Server 2016 and Windows 10 Version 1909 onwards.



P2P Protocol

  • SMB
  • HTTP
  • HTTP(S)

If you are installing Nomad for the first time, consider how your peers are going to communicate for content transfer. You will need to make sure your clients are configured to use the same protocol.

Depending on whether you use either SMB, HTTP or HTTP/S the configuration steps will be slightly different, for example if you decide to use a PKI certificate for server or client authentication HTTP/S.

Refer to Peer copy over HTTP or HTTPS for more information, including:

  • Enabling HTTP/HTTPS
  • Authentication
  • Certificate Selection
  • Firewall exceptions
  • Windows PE support
  • Configuring use of PKI-issued certificates post-installation.

MODULE.NOMAD.P2PENABLED


Other configuration settings

In general, the default values using in the CDA template .mst file will suit most organizations, however you should consider the following to ensure you have the optimum configuration for your organization.

Maximizing download speed for high-bandwidth links using Dynamic Block Sizes


The following is a duplicate of the BlockSize page.



Managing stable LAN connections


The following is a duplicate of the WLanBlipSecs page.



Setting intra-day work rates


The following is a duplicate of the MaxWorkRates page.



Inhibiting subnets and sites

You can define subnets and AD sites where machines will download from the DP (these machines will not relay download status messages) and not participate in Nomad elections. This feature only supports IPv4 subnets and is useful for sites that have a:

  • Local DP
  • 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) 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 enabling Nomad to elect a master that is not on the same local network.

The Nomad additional setting ++pr will not override the download priority.

The Nomad NomadInhibitedSubnets or NomadInhibitedADSites registry values can be set with a comma separated list of sites or subnets in which Nomad functionality should be inhibited. If the client machine exists in either an inhibited subnet or an inhibited site, peer functionality is disabled, the agent will not participate in elections and will download from the DP.

Inhibit files and formats

You can append the inhibited subnet and AD site lists with content from text files to make it easier to manage if there are many sites and subnets to be defined. Inhibited sites or subnets are defined in text files with a .inh extension and must reside in the %INSTALLDIR%\Inhibits directory.

Each file should contain a list of the inhibited subnets in a classless inter-domain routing (CIDR) format, or a list of inhibited AD sites. Each site or subnet must be on a separate line or be separated by commas. For example, the following defines two subnets and one AD site to be inhibited:

192.168.0.0/24, 192.168.1.0/24
ACMEDOM1

When the Nomad service starts or is reset, any .inh files in the Nomad %INSTALLDIR%\Inhibits directory are read in. Both the registry values and the contents of these files are used together to determine the list of inhibited subnets and sites.

A service reset occurs when the Nomad registry is updated or there is a change of subnet. So, if a laptop moves to another subnet half way through a download, the Nomad service will reset and check the current subnet against its list of inhibited subnets. If the check determines that the new subnet is an inhibited subnet, Nomad’s peer-to-peer functionality is disabled – the service stops downloading from the peer and will instead download from the local DP.

Support for IPv4 and IPv6

Nomad supports IPv4 by default, and optionally supports IPv6, which is commonly required when clients connect to the corporate network using the DirectAccess.

To configure support for IPv4 and/or IPv6, update the Nomad SpecialNetShare registry value:

  • Bit 1 - 0x0002 - Enable IPv6
  • Bit 2 - 0x0004 - Disable IPv4