1E 8.1 (on-premises)

Nomad removes the need for distributed servers and intelligently uses only available bandwidth for all content distribution, so the business is never impacted by Configuration Manager or Windows deployments.

Nomad uses Configuration Manager console extensions to enhance the Configuration Manager Admin console, so you can configure Nomad settings, pause and resume Nomad downloads, use Nomad pre-caching and create baseline configuration items. By integrating with your OSD strategies Nomad maximizes the efficiency of distributing large OS content across the network. It does this by providing a number of Task Sequence steps that can be integrated directly into your OSD Task Sequences. Nomad also supports content distribution for Configuration Manager and Tachyon with the 1E Client.

A new Tachyon Platform component, called 1E Content Distribution, provides support for a number of Nomad features such as Single Site Download. Nomad clients send information back to Content Distribution related to the Nomad features and the performance of Nomad. Content Distribution is a replacement for ActiveEfficiency used in earlier versions of Nomad.

In addition, with the Tachyon Platform there is the new Nomad app replacing the Configuration Manager Nomad Dashboard. The Nomad app provides a high level view of the current status of content throughout the entire network.

The picture opposite shows the high-level relationship between the Nomad components listed in the Nomad components table.

Nomad integrates with the Configuration Manager (CM) client content download process. When Nomad is installed, it registers with the Configuration Manager client as an Alternate Content Provider (ACP), which means the CM client will use Nomad as an alternative to BITS when it requires content if Nomad is enabled for the requested content object. Nomad can be enabled on individual packages (including Driver Packages, Operating System Images, Operating System Upgrade Packages and Boot Images) and Task Sequences.

For Applications and Software Updates, Nomad is enabled on each client for all Applications and Software Updates through Default Client Settings. When the CM client requires Nomad-enabled content, it passes a request to Nomad, which in turn downloads the content, places it in the CM client cache and passes back to the CM client for execution. The 1E Client (with Nomad client module enabled) must be installed on all CM client machines and on all Distribution Points (DP).

Nomad dynamically analyzes the overall WAN traffic to ensure that it only uses a percentage of the total. It is also aware of mobile devices and knows the difference between wireless and wired connections and is able to select the most efficient available connection to use.

Full control over WAN link usage

Nomad respects business data on the network – it detects the true end-to-end available bandwidth and monitors this throughout the duration of the download. This is calculated using a sophisticated algorithm that looks beyond the receiving capabilities of each device's network card. If bandwidth is available, the transfer speeds up; if it becomes restricted, the transfer slows down. As a result, overall WAN availability is maximized and the impact on the critical link between the branch networks and the central network is minimized.

To avoid placing a burden on office wireless bandwidth and to use the most efficient transfer system possible, Nomad can be configured to switch from a wireless to a wired network connection automatically when one becomes available. (Please refer to Design Considerations - Managing stable LAN connections).

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.

To minimize repeated downloads of the same content from the Distribution Point, Nomad supports download resumption and consistency checking.

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.

Not only is Nomad aware of the file level differences between different versions of a package so that only changed files are downloaded, it is also aware of the differences within individual files, refer to File-level delta downloads for details.

In our example, a package that has been previously downloaded has one of its files updated. Nomad compares the Configuration Manager RDC signature file (where each block in the file is given a number that identifies it according to its contents) for the new version of the file and the one before it. By identifying the changes, Nomad is able to download just the file blocks containing the differences.

The Nomad app provides visibility of content distribution activity and cache status for content distributed by both Nomad and Delivery Optimization. This includes Configuration Manager content distributed with Nomad and Software Updates content distributed with either Nomad or Delivery Optimization.

1E Content Distribution is a Tachyon Consumer, providing control and visibility on content deployments and delivery in an organization.

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

Nomad supports application virtualization (App-V) applications which are deployed as streamed content by Configuration Manager.

Nomad has always provided encryption for most of its communications and uses an advanced FIPS compliant encryption algorithm. The United States Federal Information Processing Standard (FIPS) http://en.wikipedia.org/wiki/FIPS_140-2 is a standard that defines security requirements for software used by the U.S. federal government. It stipulates that applications that encrypt any sensitive data should use only a certain set of approved encryption algorithms.

Pre-caching lets you preload the Nomad caches of particular machines directly from the Configuration Manager console. This enables downloads to be available on the branch prior to a deployment taking place, which can be very useful in large-scale deployment scenarios.

Windows imposes a limit on the number of concurrent connections on the Nomad share. The FanOut featurecompensates for this limitation by enabling any peer that has more content than the requester to respond to the FanOut request. It is not limited to peers that have an active connection to the master.

Nomad's Single Site Download (SSD) feature ensures a download across the WAN only happens once per site. It does this by maintaining information about which subnets are neighbors of each other (accessible on LAN rather than WAN), so that when an elected master considers a download from a DP rather than a peer in its subnet, it can discover which other local subnets already has the package. These subnets are typically at a single customer site, specifically a single geographical location.

Nomad SSD uses Content Distribution. When a Nomad client downloads a package, it registers this information with Content Distribution, enabling a profile to be created on which Nomad clients hold particular packages.

The Peer Backup Assistant (PBA) feature enables files and settings data to be backed-up to a peer device so that they can be maintained when the device 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 devices can be used to provide this storage. The risk of losing user data through the migration process is also greatly reduced in the process.

Nomad integration with WakeUp enables Nomad to share content from its devices that are holding particular content, even if those devices are offline. One reason why peers in the local subnet may not respond to the request even though they have content in their caches is that they are offline (shutdown, in hibernate or sleep mode). However, if WakeUp is integrated, the Nomad client would know which offline device has the content and can wake it up when it queried Content Distribution.

The wake up list is maintained by Content Distribution and is the same list that Single Site Download (SSD) uses. Separate lists of peers are returned for subnet and site. This feature requires Nomad SSD to be enabled, Content Distribution and a NightWatchman infrastructure. The feature is enabled during installation of PreparationNightWatchman Management Center. Please refer to Nomad Preparation for requirements.

Nomad can integrate with OSD strategies to maximize the efficiency of distributing large OS content across the network. It does this by providing a number of Task Sequence steps that can be integrated directly into your OSD Task Sequences.

The Nomad Download Monitor tool (also known as NomadBranchGUI) is useful for administrators for troubleshooting downloads as they view the status of downloads on local and remote Nomad client devices.

The Nomad Baseline wizard is used to create a Configuration Manager (CM) Baseline from the Configuration Manager console for settings related to Nomad.

Nomad integrates with Tachyon to enable pausing or resuming Nomad downloads throughout the estate. This feature provides a safety measure for situations when a faulty or harmful deployment is made by mistake. In such situations, pausing Nomad downloads on all targeted devices can prevent or limit the potential damage.

It can also be used to facilitate troubleshooting, making it possible to pause all Nomad downloads across the network and enable IT teams to eliminate content distribution from their assessment of network bandwidth usage.