Deploying Software Updates with Nomad

In this lab, you will use Nomad to distribute content for ConfigMgr Software Updates.

Deploying Software Updates with Nomad

In this exercise, you will enable Nomad for Software Updates and set up a Software Update deployment to the lab workstations.

Enable Nomad for Software Updates

As with Applications, Nomad is enabled or disabled for all Software Update deployments through the Client Settings. In this task, you will enable Nomad for Software Updates in the Default Client Settings. 

The purpose of the lab is to observe Nomad taking part in the download process and sharing the content, it is not to ensure the machines successfully patch, therefore please do not worry if some patches fail to install.

1ETRNCM



In the ConfigMgr console, open the Administration workspace and select the Client Settings node


Right-click Default Client Settings in the right-hand pane and select 1E Nomad → Nomad Properties


In the Nomad Properties dialog box, select Software Updates on the left and make the following changes and click OK


Check Enable Nomad 
Check Work Rate (%) and set the value to 20


Use the method learned earlier to force a policy update on the members of the Lab Workstations collection


Create a Software Update Deployment

For the purposes of this lab exercise, an Update Group has been created to include a number of Windows updates that are required on the lab workstations. These updates have been downloaded and added to a Software Updates Deployment Package.

1ETRNCM



In the ConfigMgr Console, open the Software Library, expand the Software Updates node then select the Software Update Groups node


Double-click the Windows 7 Updates Software Update Group in the Software Updates Group pane to display the list of updates included


Note that the status shows a compliance % and that the updates are required on three systems – these are our three Windows 7 machines.


Click the back arrow button to the left of the breadcrumb trail above the navigation pane


Right-click the Windows 7 Updates Software Update Group in the Software Updates Group pane and select Deploy from the context menu to start the Deploy Software Updates Wizard


On the General page, select the Lab Workstations Collection. Click OK and then click Next


If a License Terms dialog box appears, accept the license terms and click OK


On the Deployment Settings page, ensure the Type of deployment is Required and click Next


On the Scheduling page set the Installation deadline to As soon as possible and click Next


There are 2 schedules presented here, one for when the deployment is made available, and the other for Installation deadline. Ensure both are set to As soon as possible


On the User Experience page click Next


On the Alerts page click Next


On the Download Settings page, ensure that Download… option is selected in both sets of deployment options. Click Next


Software Update Deployments always download the required content and install 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. As 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.


On the Summary page, click Next to complete the wizard, then click Close


Trace the progress of the update download

In this task, you will observe the activity on the clients as they receive the Software Updates policy and begin to download the necessary content.

1ETRNW71



On the Windows 7 machines, starting with 1ETRNW71, run the Machine Policy Retrieval & Evaluation Cycle followed by the Software Updates Deployment Evaluation Cycle a minute after machine policy (It may be that machine 1ETRNW71 is not the first to initiate the download, identify the machine that is and trace the stages using the information below. (With the Nomad Gui tool open you will see the start of the download process)





Open the UpdatesDeployment.log. Identify the point when the ConfigMgr client received the software updates assignment, and note the subsequent log entries that indicate that each of the updates has been added to the targeted list and that the DownloadCIContents Job has started





From the File menu, open UpdatesHandler.log. 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 updates are required and download is initiated





From the File menu, open CAS.log. Identify the point where the Content Access Service requests the content for the requested updates in the deployment





From the File menu, open ContentTransferManager.log. Identify the points where CTM invokes the NomadBranch provider for each of the required updates





From the File menu, open the NomadBranch.log (refer to Exercise: Tracing the Nomad download process, if you cannot remember where to find it)





Identify the point where Nomad is invoked by the Content Transfer Manager as the Alternate Content Provider




The ccmcache value might be different in your environment.




Identify the point where Nomad initiated the election for the content associated with the first update. From the log entries, identify which machine became the master





Identify the point where the client gets the LsZ file. If you are looking at the NomadBranch.log file on the master, you will 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. If you are looking at the log file on one of the other clients, the LsZ file will be downloaded from the master





Identify the point where the client downloads the content for the first update (either from the DP or from the master) completes the hash check and creates the hard-link to the ConfigMgr cache





Note that the above process are repeated for each of the updates for which content is required




1ETRNW73



Open the NomadBranch.log. Review the elections for the Updates, as well as the subsequent P2P content transfer


For Software Updates, each update is identified as an individual piece of content, and thus there will be an election for each Software Update. Since all machines in an environment might not need all the same updates, each update will have its own election, and different masters might emerge for different updates.


1ETRNW72 is on a separate subnet, so the download for all the updates will be directly from the DP. You can review the logs if you choose. The Windows 10 workstations are not in scope for the Windows 7 Software Updates group, so they will not evaluate as applicable for any of the updates, and thus not get involved in any of the elections.


Please note that the installation of these software updates will require a reboot and this reboot must be performed before any other software may be installed. A script has been provided that will enable the remote reboot of all workstations before deployment in the next lab. Since we are mainly interested in seeing how Nomad is invoked to download the content, we can move onto the next lab for now. Remember this is about how Nomad handles the download of the content, it will not matter if patches fail.


Confirm and configure Settings for Software Updates to download from Microsoft Update

In the previous exercise Nomad was configured on Software Updates, here we will cause the update to get source from Microsoft Update and then Nomad will share that content as in the previous exercise. And these notes continue to apply:

For Software Updates, each update is identified as an individual piece of content, and thus there will be an election for each Software Update. Since all machines in an environment might not need all the same updates, each update will have its own election, and different masters might emerge for different updates.


1ETRNW72 is on a separate subnet, so the download for all the updates will be directly from the DP. You can review the logs if you choose. The Windows 10 workstations are not in scope for the Windows 7 Software Updates group, so they will not evaluate as applicable for any of the updates, and thus not get involved in any of the elections.


Please note that the installation of these software updates will require a reboot and this reboot must be performed before any other software may be installed. A script has been provided that will enable the remote reboot of all workstations before deployment in the next lab. Since we are mainly interested in seeing how Nomad is invoked to download the content, we can move onto the next lab for now.


Downloading from Microsoft Updates may not be the most performant option to select, you should consider implementing Single Site Download before allowing this type of download as each update is treated individually


For the purposes of this lab exercise, an Update Group has been created to include a number of Windows updates that are required on the lab workstations. These updates have been downloaded and added to a Software Updates Deployment Package. They were distributed, as in the previous exercise, but the content has been removed from the DP, so that for our purposes the Updates are not available in the environment and a machine will need to call out to Microsoft to obtain the source. The purpose of the lab is to observe Nomad taking part in the download process and sharing the content, it is not to ensure the machines successfully patch, therefore please do not worry if some patches fail to install. 


1ETRNCM 



In the ConfigMgr Console, open the Software Library, expand the Software Updates node then select the Software Update Groups node 


Right-click the deployment of the Windows 7 Updates v2 Software Update Group in the Software Updates Group pane and select Properties from the context menu


On the Deployment Settings page, note the Type of deployment to Available


On the Download Settings page, confirm that Download… option is selected in both sets of deployment options. And that the If software updates are not available on distribution point in current, neighbour or site boundary groups, download content from Microsoft Updates is checked


Click OK to close the deployment screen


Open the Monitoring Workspace, expand the Deployments node then double click the Windows 7 Updates v2 deployment


The two windows 10 machines will appear in the Compliant tab as these updates are not applicable to them. (And they will not take part in the election process)  


Log onto each of the Windows 7 machines and in Software Center on the Updates tab select install all


Trace the progress of the update download

1ETRNW72



Open Software Center then select Updates the deployed updates should be visible, if not then open Configuration Manager from the desktop and force a machine policy refresh





Open the NomadBranch.log and observe the Nomad branch event and it starting to download from windows update and the calls for an election with itself winning:





This will repeat for each of the updates, and as 1ETRNW72 is the only Windows 7 machine in its subnet it will always win the election



1ETRNW71



Open Software Center then select Updates the deployed updates should be visible, if not then open Configuration Manager from the desktop and force a machine policy refresh





Open the NomadBranch.log and observe the Nomad branch event and setting the download to come from windows update and the calls for an election with 1ETRNW73 winning as it has 100% of the content:





This is followed by the connection to the Master, copying and checking the LsZ, the transfer of the update to the NomadCache, carrying out the Hash check and the completion of the job





In this lab as each update is downloaded separately the actual download you will see may be different, but the steps will be the same



1ETRNW73



Open Software Center then select Updates the deployed updates should be visible, if not then open Configuration Manager from the desktop and force a machine policy refresh





Open the NomadBranch.log and observe the Nomad branch event and setting the download to come from windows update and the calls for an election with itself winning as there is no content on any machine in the subnet:





Followed by the connection to the remote download source, creation of the LsZ, and the beginning of the content download:





The content download status is logged and the periodic election is called:





Until finally the download completes, the hash check is carried out and content integrity is confirmed, and the hardlink to the CCMCache is created:





You saw in the previous lab, where the content was obtained via Config Mgr how the updates handler worked, this would be the same as that you can review as you did in the previous lab if you need to


As before each update is downloaded separately therefore the actual download you will see may be different, but the steps will be the same


Lab Summary 

In this lab, you have seen how Nomad can be used to download content 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. You 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. 

Next Page
Ex 4 - Nomad 7.0 - Using Single Site Download and FanOut