1E 8.1 (on-premises)

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.

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.

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.

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

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

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.

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.