Deploying software updates using Configuration Manager

Nomad integrates with the Configuration Manager (CM) client content Distribution Point (DP) download process, and 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 in Configuration Manager.

In addition, Nomad can also download content from Windows Update / Microsoft Update (WUMU). Starting in CB version 1806, software updates can be deployed to devices without first downloading and distributing content to Distribution Points, instead clients download updates directly from Microsoft Update.As a system administrator, we'll show how you can use Nomad to deploy software updates with CM from a CM Distribution Point or directly from Microsoft Update. While Nomad is enabled or disabled for all Software Update deployments through CM Client Settings, downloading from Microsoft Update is enabled by default. The settings are defined in CompatibilityFlags and you will need to ensure the relevant bits remain set if you are using that registry value to configure other options.

For details about the types of updates enabled by default in the Nomad client (1E Client 4.1 and later), refer to Downloading content for CM Software Updates from Microsoft Update.

Note

You can use the Content Distribution app, powered by the 1E Platform to get a visual snapshot of download activity in your environment. The Nomad app will be available after you install the 1E Platform and can be accessed using the 1E DNS Alias FQDN, for example https://tachyon.acme.local/Tachyon

The section Monitoring Nomad on this page provides an overview of how you can use the app to view download progress for large and small scale deployments.

Enabling Nomad for Software Updates

Nomad is enabled or disabled for all Software Update deployments through the Client Settings. In our example we will enable Nomad for Software Updates in the Default Client Settings and see how Nomad takes part in the download process and shares the content.

Before deploying our software updates, we are going to amend the Work Rate for our deployment. The Work Rate determines the percentage of available bandwidth to use for the download.

In this example we have changed this from the default 80% of available bandwidth to 10% to slow down the deployment and so making it easier to monitor.

For more details about the Nomad tab, and how you can use Work Rates, refer to Nomad tab and Setting intra-day work rates.

In our example in Configuration Manager:

We select the Administration workspace and choose the Client Settings node.
Then click Default Client Settings in the right-hand pane and select 1E Nomad→ Nomad Properties from the displayed Ribbon.
In the Nomad Properties dialog box, we select Software Updates on the left and make the following changes.
1. Check Enable Nomad
2. Check Work Rate (%) and set the value to10.

Once this is done, we force a policy update on the collection containing our workstations called Lab Workstations.

Note

As Windows 10 cumulative updates get very big, very quickly (often in excess of 1GB a few months after any given Feature Upgrade), Microsoft started publishing express installation files for these updates in addition to the traditional full update files. Configuration Manager introduced support for Windows 10 Express Installation File updates in Current Branch 1802 hotfix KB4163547.

Express installation files are a much larger payload on the Distribution Point compared to traditional software update files, but the feature enables clients to download delta byte-ranges from these files, so each month the amount of data a client has to download is typically much smaller. Configuration Manager Current Branch can be configured to support express installation files (refer to https://docs.microsoft.com/en-us/configmgr/sum/deploy-use/manage-express-installation-files-for-windows-10-updates for more details).

With the release of Windows 10 1809, Microsoft replaced express update files with a new way of managing deltas within software updates. In Configuration Manager 1902 the Enable installation of Express installation files on clients option in Software Update Client Settings was replaced with Allow clients to download delta content when available.

Note

Nomad supports the download of Express installation files and delta content for updates.

Refer to Windows 10 Express Installation Files and Delta Content for Updates for more details.

Deploying Windows updates from a DP

We have created a Software Updates group called Windows 7 Updates containing three updates for the Windows 7 computers on our network:

2018-05 Security Only Quality Update for Windows 7 for x86-based Systems (KB4103712)
2018-07 Security Only Quality Update for Windows 7 for x86-based Systems (KB4338823)
Security Update for Windows 7 (KB3000483).

We then deploy the updates to our workstations using the default deployment settings, but making sure we have set:

Deployment Settings - the Purpose is Required
Scheduling - Installation deadline is As soon as Possible
Download Settings - we selected both Download options.

Note

Software Update Deployments always download the required content and install it from the local cache. By default, clients connected within a boundary defined by an administrator as slow or unreliable will not download the content and therefore the update will not be deployed to those clients.

Because we are using Nomad to distribute the content, we always want the content to be downloaded, as we are not concerned about the bandwidth when using Nomad.

Tracing update download progress

We then watch the computers in our as they receive the Software Updates policy and begin to download the content. Using the Nomad download UI we can see the content being downloaded. We can also see that the 1ETRNW71 computer has been elected as Master.

Note

Nomad ensures that software packages are only ever copied once per branch over the WAN, utilizing local computers as temporary file caches to distribute the software locally. This reduces the bandwidth required for delivering software updates and means that small offices or sites connected by poor network links can receive software updates more reliably.

The Nomad clients with local copies of the package can themselves act as the master if the need arises. This significantly reduces the number of Configuration Manager servers required to manage a Configuration Manager hierarchy, thereby reducing initial and ongoing maintenance costs.

Refer to Download once to branch for details.

Using CMTrace.exe we open the UpdatesDeployment.log from C:\Program Files\SMS_CCM\Logs and can Identify the point when the Configuration Manager client receives the software updates assignment. We can also see log entries indicating that each of the updates have been added to the targeted list and that the DownloadCIContents Job has started.

In our example we can see this process for Security Update for Windows 7 (KB3000483).

We then open UpdatesHandler.log and identify the point where the updates handler initiates a scan to determine which of the updates included in the deployment are applicable.

Eventually the scan determines the required updates and initiates download.

We then open CAS.log and identify the point where the Content Access Service requests the content for the requested updates in the deployment.

In the ContentTransferManager.log we identify the points where CTM calls the NomadBranch provider for each of the required updates.

We look at the NomadBranch.log from C:\Windows\CCM\Logs and identify the point where Nomad is called by the Content Transfer Manager as the Alternate Content Provider.

We locate the point where Nomad initiated the election for the content associated with the first update. From the log entries, we can then see which computer became the master.

Then we locate the point where the client gets the LsZ file. As we are looking at the NomadBranch.log file on the master, we see the LsZ generation request (as this is the first time the content has been requested from the DP) and the LsZ file will then be downloaded from the DP.

Note

If we looked at the log file on one of the other clients, the LsZ file will be downloaded from the master.

Finally we identify the point where the client downloads the content for the first update (either from the DP or from the master). The client will then complete the hash check and create the hard-link to the Configuration Manager cache.

We have seen that each update is identified as an individual piece of content, resulting in an election for each Software Update. Because all computers on our network might not need the same updates, every update will have its own election, and different masters may emerge for different updates.

Deploying Windows updates directly from Microsoft Update

In this example, the source of our updates are from Microsoft Update and Nomad shares the content as it would if the content was available from Configuration Manager.

Configure and confirm settings

We have created a Software Updates group called Windows 7 Updates v2 containing two updates for the Windows 7 computers on our network:

Security Update for Windows 7 (KB3004375)
Update for Windows 7 (KB3021917).

We then deploy the updates to our lab workstations using the default deployment settings, but making sure we have set:

Deployment Settings - Type of deployment is Available
Download Settings - we selected both Download options and checked If software updates are not available on distribution point in current, neighbour or site boundary groups, download content from Microsoft Updates.

We then install the update using Software Center→Updates on our Windows 7 computers.

We open the NomadBranch.log on our computer 1ETRNW72 and see the start of the download from Windows update and the calls for an election with this computer winning.

1ETRNW72 wins the election because it is the only targeted device the subnet.

Note

Refer to Download once to branch for details.

In this example, we have seen how Nomad can be used to download Software Updates content. From both a Config Mgr deployment where content is available and when it is not and connecting to Microsoft Update has been allowed.

In addition, we have seen that Nomad is enabled within the Software Updates Client Agent settings rather than in the individual Software Update Deployments, so once enabled Nomad is used for all Software Update Deployments. The process of getting content is the same as with Applications and Packages – the Content Transfer Manager invokes Nomad as an Alternate Content Provider, which downloads the content then passes back control to CTM.