Introducing Nomad 7.0.200
Working with Nomad
OS Deployment features
OS deployment task sequences
Set Nomad as download program
Create Nomad application policy
Delete Nomad application policy
Disable Run from distribution point
Enable Run from distribution point
Install and configure Nomad in WinPE
Install 1E Client
Get migration settings
Peer backup assistant Provision Nomad PBA data store
Peer backup assistant Finalize Nomad PBA data store
Peer backup assistant Locate existing Nomad PBA data store
Peer backup assistant Release Nomad PBA data store
Pre-stage content using Nomad
Save Nomad cache
Restore Nomad cache
Stage 1E Client Package
1E WSA Actions
Peer backup assistant Close Nomad PBA data store
Peer backup assistant High-availability
Redirect content location to the Nomad cache
- Set Nomad as download program
Peer Backup Assistant - PBA
- OS deployment task sequences
Operational best practices
Frequently asked questions
- Core features
Nomad 6.0 introduced key OSD enhancements that increase Nomad's integration with OSD task sequence. These changes drastically simplify the task sequence engineering process and the steps that are required to integrate Nomad with OSD. These enhancements are:
- SMSTSNomad.exe – a new executable that is part of the OSD tool-set, allows Nomad to leverage the Configuration Manager SMSTSDownloadProgram option and act as Alternate Content Provider during OSD
- Preserving Nomad logs – the Save Nomad Cache and Restore Nomad Cache task sequence actions now ensure that Nomad logs are preserved across all OSD phases
- More robust Nomad cache handling – the functionality of the Save Nomad Cache and Restore Nomad Cache task sequence actions has been improved to reduce the risk of the copy/move content behavior leading to task sequence failures.
From Nomad version 6.3.200 onwards, SMSTSNomad.exe now supports the use of Configuration Manager's OSDDownloadContent.exe directly from a Run Command Line step in a Task Sequence, as well as the previously supported Download Package Content Native Configuration Manager Task Sequence Step. No additional configuration is required to make this work. NomadBranch.exe has also been enhanced to support SMSTSNomad.exe.
Prior to version 6.0, invoking Nomad during OSD, especially when running under WinPE, required some overly complex procedures. Nomad 6.0 simplifies the process by leveraging the Configuration Manager
SMSTSDownloadProgram task sequence variable. When this variable is set to the path to an executable, the task sequence engine calls the executable whenever it has to download some content. For this to work effectively Nomad 6.0 introduces a new executable specifically for this purpose, called
To avoid the overhead of having to manually set the
SMSTSDownloadProgram variable to
SMSTSNomad.exe in your task sequence, use the Set Nomad as download program custom task sequence. The following are the content types that are supported by
- OS Images
- Boot Images
- Driver packages
- Drivers (via Auto apply drivers TS action)
Preserving Nomad logs
Prior to version 6.0, the Save Nomad cache task sequence action made no attempt to preserve the Nomad logs. This meant that if any problems occurred during the WinPE phase of the OSD, the Nomad logs were no longer available for troubleshooting. From Nomad 6.0, Save Nomad cache now saves the Nomad log files along with the contents of the Nomad cache, meaning that they are restored when the Restore Nomad cache is called after the new OS has been deployed. Save Nomad cache also appends a timestamp to each log file name to prevent name conflicts with any log files that may already be present in the target location.
Nomad can be used in an OSD task sequence to find OSD packages required by WinPE that are located on pre-cached Nomad peers on the local subnet rather than downloading them from the nearest DP. Using Nomad in WinPE as part of an OSD bare metal task sequence has a number of distinct advantages:
- Multiple connections are supported by Nomad caches maximizing the number of machines that can be built concurrently
- Multiple pre-cached locations can be supported (we recommended at least 2 per subnet to increase the number of simultaneous imaging jobs are supported)
- Nomad in WinPE supports all the Nomad features, so elections, failover, multicast and bandwidth efficiency are all on hand to maximize the resilience and performance of the imaging process
- Multicast support enables the distribution of large packages to vast numbers of clients with minimum impact on the local network
These advantages become important when you plan a rapid OS refresh over a relatively short time. Nomad must be installed as part of a task sequence in order to support the use of pre-staged content from within WinPE and managed through custom task sequence actions,
Pre-caching packages used during OSD is important because:
- Image packages, especially for Windows, tend to be several gigabytes in size and downloading these across the WAN as part of an OSD is undesirable and slow
- Bandwidth throttling is enforced if Nomad senses that the WAN link is getting congested with other network traffic. This ensures that any impact on the WAN during pre-caching is kept to a minimum.
- Nomad in WinPE automatically locates local pre-cached content and uses these to avoid WAN traffic to ensurer that once the image package is on the branch there is no impact on the WAN and the time taken to retrieve the image is minimized because everything is local
To pre-cache an OS image, duplicate an existing Configuration Manager OSD task sequence and modify the tasks in the task sequence.
- Make a copy of an existing Install Windows task sequence and call it Pre-Cache Windows.
- Edit the copy.
- Remove every task except for the Apply Operating System.
- Edit the options for the task and add a condition that will never evaluate to True. For example, task sequence variable
- In the Properties for the task sequence on the Nomad tab, enable Nomad.
- Set the Cache Priority field to 9.
- Enable other Nomad options you want here too.
Adding binaries to an existing boot image
SnoItfPS.dll files are placed in the Microsoft Configuration Manager installation folder by the Nomad tools installers. They copy the 32-bit tools to
OSD\bin\i386 and the 64-bit tools to
OSD\bin\x64 and then modify the
osdinjection.xml file to include these in the WinPE boot images when DPs are updated.
On Configuration Manager, the
NomadBranchTools.msi installer must be used.
Using Nomad for an OS refresh
An operating system deployment (OSD) refresh typically uses two Configuration Manager site systems – a distribution point (DP) and a state migration point (SMP). A standard OSD refresh uses task sequences as follows:
- The user state is captured and either stored locally or on a SMP.
- The Configuration Manager client downloads the Windows Preinstallation Environment (WinPE) boot image to the local workstation while the Configuration Manager client is still running.
- If the task sequence is deployed as Download all content before starting, all content is downloaded into the Configuration Manager cache (not suitable for dynamic packages).
- The boot record is updated to enable the computer to reboot to WinPE.
- If the task sequence is deployed as Access content from DP as required or Download content as required, the content is obtained from the DP.
- The new OS is applied.
- The saved user state is reapplied to the new OS and the process completes.
Getting content when a task sequence is running
When a task sequence is running, it does not use the alternate content provider to obtain content for packages (although it does for application and software update content), so the normal hook that invokes Nomad when content is required cannot be used to download the boot image, OS image, user state migration tool (USMT) package, Configuration Manager client and any other content that is defined in packages.
In an OS refresh, you can deploy the task sequence with the Download all content locally before starting task sequence option, which causes the content transfer manager (and therefore Nomad) to download all packages referenced in the task sequence before rebooting into WinPE. However, this is impractical and inefficient when you consider the typically large volume of unnecessary driver packages that is downloaded by each client before it starts to rebuild and it does not help if dynamic packages are used in the task sequence.
When integrating Nomad into an OSD task sequence, special tasks are used to invoke the Nomad download directly, enabling the core content (boot image, OS image, drivers, Configuration Manager client and Nomad client) to be downloaded from a local peer (or worst case, a remote DP). Once Nomad has cached the content, it is then moved to the preserved
_SMSTaskSequence folder and the task sequence environment variables that define the location of these packages are updated to reflect this new location (the client will no longer be obtaining the content from the DP, but instead from a cache in the
In summary, the three options for getting content when a task sequence is running (as well as their particular characteristics) are:
- Download all content before starting.
- Can only be used for a refresh where the Configuration Manager client is running in the original OS
- Downloads all content – will include redundant files such as unnecessary driver packages
- Downloads using the Configuration Manager client so will use Nomad if it is available
- Download content as required.
- Only downloads what is required by the OSD
- In Configuration Manager, it uses Nomad if it is available but only for software updates. Applications and package downloads which include the boot image, user state migration tool (USMT) data, Configuration Manager client and the OS image do not use the client so Nomad is bypassed for this type of content.
- Does not provide bandwidth management
- Access content from the DP as required.
- Nothing is downloaded (except WinPE in an OS refresh)
- Content is accessed directly in the DP file share
- In Configuration Manager, the DP is configured as a website by default and does not have a file share – you cannot connect to an HTTP URL and execute from there. So, if any single package that is referenced within the task sequence is not established on a file share, (an option on the distribution settings for each package), this option will not be available for the task sequence in the Configuration Manager interface. If you do not set all the packages to be established on a file share, you are doubling the capacity required on the DP.
- Does not provide bandwidth management
OSD content distribution and task sequence deployments
OSD content distribution in Configuration Manager is handled differently, so let us consider how this affects Nomad.
- In Configuration Manager, any content associated with OSD updates and applications is typically installed after the Configuration Manager client (i.e. after the OS install and Configuration Manager client install task sequence steps). The Download content as required option uses Nomad for this type of content. Unfortunately, for package content, which includes the boot image, USMT data, Configuration Manager client and OS image, this is not downloaded using the Configuration Manager client and bypasses Nomad.
When the Access content from DP as required option is selected for a task sequence deployment, a universal naming convention (UNC) connection to the DP file share is initiated with the task sequence is run and the content is executed directly from the share.
- In Configuration Manager, the DP is a website and does not have a file share
When you use Nomad with a task sequence, set the following when you deploy it:
- In Configuration Manager, deploy the task sequence as Download content as required
- The Configuration Manager client gets the task sequence
- Nomad switches the running task sequence to Access content from the DP as required – a temporary measure whilst the content is downloaded
- Nomad determines the packages referenced by the task sequence
- Nomad gets the content and redirects the task sequence to use that content instead of content from the DP
- After the package content has been executed locally, Nomad switches the running task sequence back to Download content as required
- The software updates and application are downloaded by the Configuration Manager client using Nomad as the alternative content provider