In the first post in this series, we created an OSD Task Sequence that is ideal for the SMB market. We touched on some of the automation options available with MDT, and were ultimately able to deploy operating systems to machines at the main office.

Our next step is to make this Task Sequence deployable to branch workstations so they don’t need a nearby Distribution Point, PXE Service Point, or State Migration Point. To do that, we’ll update a copy of the Task Sequence with some integrations that come with 1E Nomad. But first, let’s right click on our Task Sequence from the first post and choose Copy. We’ll append -Nomad to the task sequence name, so it looks like this:


Once we have our copy, we’ll go in and edit the new sequence. However, before we start adding the Nomad injections, we need to fix a problem that Nomad will have with Bare Metal Deployments.

When a brand new computer begins Task Sequence Execution, it will first partition and format the drive. The Task Sequence will perform some actions, and then ultimately format the drive again. This is a problem, as we’ve already started caching packages and created references to files that will be force-removed. Therefore, we need to get all the format stuff taken care of at the beginning.

To do that, we’ll simply move the Format Drive group, that’s currently in the Preinstall -> New Computer Only group, and move it immediately after the Set Variable for Wizard action. This causes two Use Toolkit Package actions to be almost concurrent, so we’re going to delete the first one and move the Capture Network Settings using MDT action below the remaining Use Toolkit Package. This will cause the Capture step to run regardless if the drive has been formatted or not, but that’s okay. After we apply the changes, our sequence will look like this:


Regarding the Nomad injection process, there’s a couple of key points that we need to keep in mind:

  1. We must cache a package locally on the client before executing it.
  2. Our goal is to implement soft failures. This means that if a Task Sequence is going to fail, we want it to fail out as early as possible.
  3. The sequence is designed for Bare Metal, Refresh, and Replace scenarios. The stage at which some/all packages are cached will differ depending on the deployment scenario.
  4. WinPE is stored on a RAMDrive, so content cached in PE will not persist through a reboot.

Points 1 and 3 are really the key to how we place our Nomad injection steps, but we can’t forget about 2 and 4 either.

As we start going through our Task Sequence from the top, the first package reference is for the Use Toolkit Package step immediately after the Format Disk group. This is part of the Initialization group, so will run regardless of the deployment scenario (We validate this by checking for any conditions in the Options tab). We also need to ensure we can use Nomad to cache the Toolkit package before this step, regardless of the deployment scenario.

Before we can cache a package in WinPE, which will be required for a Bare Metal run, we need to add a step to Install and Configure Nomad in WinPE. This will configure a lite version of Nomad in PE that doesn’t have dependencies on a full Windows installation or functioning Configuration Manager Client. Since this step will fail in full Windows, we need to ensure this step will only run in PE. To do this, we will add a Condition that says _SMSTSInWinPE=True.

We’re also going to change the SpecialNetShare value to 8240, which will additionally configure Nomad to access NomadSHR$ instead of NomadSHR.


At this point, regardless if we’re in Windows or WinPE, Nomad will work. So the next step we need to add will precache the required packages on the client. Our goal here is to get everything precached that will be required up until the OS has been applied and we’re back in Windows again. With our Prestage content using Nomad step, we’ll select every package (although the WinPE image is not required for the Bare Metal scenario, its less management to have it selected here for all), however we’re not going to use the All References button. This is a big NO NO, as it will automatically include every package (and driver package) that’s added in the future, including any custom apps that we lay down after the OS is applied. We’re also going to check off Show error dialog, as this will tell us the package that failed in the event the Task Sequence fails while prestaging content.


The prestage action will cache the package content to C:\ProgramData\1E\NomadBranch, which cannot be used by the Task Sequencer, so we need to get it moved into the protected _SMSTaskSequence folder. We will enlist another Nomad step to help us here, Save Nomad Cache. We’re going to choose to Move the content, and if it’s in Windows, we will also want to wipe the CCM cache…otherwise the existing hardlinks would cause the Apply OS step to fail when it tried to wipe the C: drive. To accomplish this, we will actually need to add the Save Nomad Cache step in twice, once with the Wipe CCM Cache setting enabled and one without. There will be a condition on each step to only run in the proper environment. We’ll also rename each step so we know which is configured to run in Windows and which for WinPE.


Once the packages have been successfully cached to the _SMSTaskSequence folder, we will add another custom Nomad step to Enable Run from Distribution Point. Although the packages are already cached, the Task Sequencer will download another copy from its own cache, as it thinks the precached content location is actually a Distribution Point. By adding this step, the packages will execute from their cached location.


With these steps in place, content can now be precached using Nomad regardless of the deployment scenario, and referenced packages will be accessed from Nomad cache when required.

Our next steps are to address the State Migration process for Replace Scenarios. This is when a user is moving from one PC to another, which means we cannot use hard links to persist user state data. In a traditional environment we would use a State Migration Point to store this data, however with an optimized hierarchy we will be using Peer Backup Assistant to temporarily store the .mig files during deployment.

If we scroll down to the State Capture group, everything we need to modify exists within the Online USMT group underneath it. The Request State Store action will be replaced with Peer Backup Assistant: Provision PBA Data Store, and the Release State Store is replaced by Peer Backup Assistant: Close PBA Data Store.

After these changes, our sequence looks like this:


In order to get our Driver Packages to apply properly using Nomad, they have to be pre-cached. We’re going to Copy the Apply Driver Packages Group, and paste it at the beginning of the sequence below the other Prestage content using Nomad step, then rename it to Pre-stage Driver Packages. We now need to replace each Apply Driver Package step with a Prestage content using Nomad step, using the same WMI query. This will ensure that workstations only precache the driver package for their particular model.


*Note: I added the driver section after the sequences were built, and thus the remaining screenshots show the Auto Apply Drivers step and not the individualized Driver Packages as detailed above.

Moving down through the sequence, we eventually come to the part where the new OS is applied. The driver stuff is taken care of, and then it sets up Windows and the Configuration Manager client. Once this has been completed, the Task Sequencer is running in a full blown Windows installation, so we need to get the real Nomad client installed as it’s not a part of the image. We use the standard SCCM package for this, the same one that was used to deploy Nomad to all the clients originally, and place it right at the top of the State Restore group.


Once Nomad has been installed, we need to restart the computer. Coincidentally, a Restart Computer action is already present right where we need it to be.

After the restart, we will need to restore the Nomad Cache. This time, we’re going to hard link it to the _SMSTaskSequence folder, so the content can be available from both locations. There’s also a couple of clean-up actions that we need to make on the NomadBranch share, this is due to incorrect permissions that may have been carried over from the previous installation.

To make sure these additions stand out within the Task Sequence, we’ll create a new group called Restore Nomad Cache. The first thing we will do in this group is add a Run Command Line step which we will use to delete the LogFiles folder persisted from the old Windows environment, if it still exists.

The Command Line looks like this: cmd /c RD /s /q %_SMSTSMDataPath%\NomadBranch\Logfiles

And we’ll have a condition on the step, so that it only will run if the following folder is present:

%_SMSTSMDataPath%\NomadBranch\Logfiles


Once we have confirmed that a Logfiles folder doesn’t exist, we can go ahead and run the Restore Nomad Cache action. We will configure this step with a Link and Activate, so it will not only hard link the packages with the _SMSTaskSequence and ProgramData\1E\NomadBranch folders, but it will also activate this content so that SCCM recognizes its presence also.


After we restore the cache, we need to reset the Access Control List on the folder as they don’t have the proper default permissions. We will use another Run Command Line action to perform this, with the following command line: icacls.exe “%AllUsersProfile%\1E\NomadBranch\*” /grant “Authenticated Users”:(RX) /grant BUILTIN\Users:(RX) /T /C /Q


At this point we’re done with the packages that we precached earlier, so we’ll also add a Disable Run from Distribution Point step as well.


Before we continue with the customizations, we’re going to take care of one of my pet peeves. I despise using AppMode applications to install software in a Task Sequence. It’s buggy, uses GUIDs instead of PackageIDs, and needs a separate application if multiple deployment types are used for daily operations. The answer? Use a package. It works, it’s always worked, and it’s designed to do exactly what you’re looking for: Installing a full piece of software on a workstation. Logs are clean, troubleshooting is second nature for anyone with CM experience, and it works as expected (did I say that already?). Leave AppMode apps for your operational, patch, and App-V deployments where they really shine.

So we’re actually going to do two things here while we’re at it. We’re going to get rid of the AppMode references (they do work with Nomad, by the way…just as well as they work without Nomad. There are a couple of custom steps, similar to using a package, that are required around the actual Application install), and replace them with a template for how to install Packages using Nomad in the sequence. But we’re not going to go there, cause they’ll never be needed, right?

Down to business…In the Install Applications group, we’re going to delete the two existing steps. In their place, we’ll add a Prestage Content Using Nomad step, followed by Enable Run from Distribution Point, then an Install Package step, followed by a Disable Run from Distribution Point. The end result is this:


To install a specific application, such as Java, we first need to select the Java package in the Install Package step, then click Apply. This will refresh the package references associated to the sequence, and cause it to appear in the Prestage Content Using Nomad step, where we will go to select it…exactly like before.

If you need to add additional applications at a later date, just add new Install Package steps below the first, update the sequence and add them to the existing prestage action.

Keep 2 things in mind when doing this:

  1. The Prestage Content Using Nomad step in essence executes a command line, and therefore follows the same 255 character limitation. Since each package selected also includes the HTTP content location in its path, it does not take long to exceed 255 characters. I wouldn’t reference more than a half dozen packages in a single Prestage Content step, but it ultimately depends on the naming conventions used.
  2. Using the Install software packages according to dynamic variable list option utilizes Nomad in a completely different manner, as referenced packages are not actually associated with the Task Sequence (so they won’t show up in the Prestage Content step. Therefore, in order for this option to work, all referenced packages must have SMSNomad.exe appended to the Package’s Program. I don’t generally go down this road unless the customer already has it in production and it’s used to reference a boatload of different packages.

To keep it as a template and not reference any packages, select the Install software packages according to dynamic variable list, and put TEMPLATE as the Base variable name.

Our next task is to address the State Restore process. We’re going to do the same kind of thing here, that is replacing the MDT State Store components with the PBA ones. Request State Store will be swapped with Peer Backup Assistant: Locate Existing Nomad PBA Data Store, Connect to State Store is deleted, and after the Restore User State Step we add a Peer Backup Assistant: Release Nomad PBA Data Store. Both steps also need a condition to only run if the Task Sequence Variable USMTLOCAL equals False. The State Restore Steps now look like this:


Finally, we’re going to take a copy of the Restore Nomad Cache group from up above, and place it in the Gather Logs and StateStore on Failure group. This will allow Nomad to restore its cache if the Task Sequence happens to fail in Windows. It looks like this:


Click OK, and our Task Sequence modifications are complete!

That’s it! With the power of CM12R2, MDT, and 1E we’ve created an awesome task sequence that we can use anywhere in the company, for any deployment scenario. We ultimately leave the end user with a fast resolution to achieve a usable desktop, with the right locale settings applied without any interaction.

To address the delays with patching our image during deployment, we need to architect an automated solution using Automatic Deployment Rules that will not only streamline the production patch management process, but will ensure that your image is patched, offline, with updates that have been tested and verified in your own environment.  The third post in this series will walk you through this configuration, and why it is the optimal way of streamlining the OSD Software Update process.

É