Contents

Ex 3 - Nomad 7.0 - Deploying Software Updates with Nomad

Exercise Overview:

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


  1. In the ConfigMgr console, open the Administration workspace and select the Client Settings node
  2. Right-click Default Client Settings in the right-hand pane and select 1E Nomad → Nomad Properties
  3. In the Nomad Properties dialog box, select Software Updates on the left and make the following changes and click OK
    4. Check Enable Nomad 
    Check Work Rate (%) and set the value to 20
  4. 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

  1. In the ConfigMgr Console, open the Software Library, expand the Software Updates node then select the Software Update Groups node
  2. Double-click the Windows 7 Updates Software Update Group in the Software Updates Group pane to display the list of updates included
    3. Note that the status shows a compliance % and that the updates are required on three systems – these are our three Windows 7 machines.
  3. Click the back arrow button to the left of the breadcrumb trail above the navigation pane
  4. 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
  5. On the General page, select the Lab Workstations Collection. Click OK and then click Next
  6. If a License Terms dialog box appears, accept the license terms and click OK
  7. On the Deployment Settings page, ensure the Type of deployment is Required and click Next
  8. On the Scheduling page set the Installation deadline to As soon as possible and click Next
  9. 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
  10. On the User Experience page click Next
  11. On the Alerts page click Next
  12. On the Download Settings page, ensure that Download… option is selected in both sets of deployment options. Click Next
    13. 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.
  13. 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

  1. 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)

  1. 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

  1. 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

  1. Eventually the scan determines the updates are required and download is initiated

  1. 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

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

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

  1. 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.

  1. 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

  1. 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

  1. 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

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


1ETRNW73

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


    2. 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 

  1. In the ConfigMgr Console, open the Software Library, expand the Software Updates node then select the Software Update Groups node 
  2. 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
  3. On the Deployment Settings page, note the Type of deployment to Available
  4. 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
  5. Click OK to close the deployment screen
  6. Open the Monitoring Workspace, expand the Deployments node then double click the Windows 7 Updates v2 deployment
  7. 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)  
  8. 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

  1. 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

  1. 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:

  1. 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

  1. 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

  1. 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:

  1. 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

  1. 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
  1. 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

  1. 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:

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

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

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


  1. 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
  2. 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