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:
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
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:
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:
|If there is no pre-cached content on the local branch and multicast is not enabled, we recommend you configure Nomad to use connectionless P2P. This is because WinPE does not have File and Print Sharing services so Nomad machines cannot use their default P2P communications. Enabling connectionless P2P ensures that multiple WinPE Nomad machines only download their content once and then share it locally.|
To pre-cache an OS image, duplicate an existing Configuration Manager OSD task sequence and modify the tasks in the task sequence.
|Performing this step will update the Nomad settings for the OS image properties as well. This will affect the use of Nomad in every location this image is referenced.|
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.
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:
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:
OSD content distribution in Configuration Manager is handled differently, so let us consider how this affects 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.
When you use Nomad with a task sequence, set the following when you deploy it: