Versions Compared

Old Version 1

changes.mady.by.user publisher

Saved on

compared with

New Version Current

changes.mady.by.user publisher

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Advanced Panelboxes for Confluence
namegrey
titleExercise Overview:

Table of Contents
maxLevel3
minLevel2
indent20px
excludeSummary|On this page|In this section...
separatornewline

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.

1evirtualmachine

1ETRNCM


1eolstart


1eli

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


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


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


1eimplementationicontable

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


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

1evirtualmachine

1ETRNCM


1eolstart
startat5


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


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


1ediscussion point

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


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


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


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


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


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


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


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


1eli
On the User Experience page click Next


1eli
On the Alerts page click Next


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


1ediscussion point

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.


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

1evirtualmachine

1ETRNW71


1eolstart
startat18


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




1eolstart
startat19


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




1eolstart
startat20


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




1eolstart
startat21


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




1eolstart
startat22


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




1eolstart
startat23


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




1eolstart
startat24


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




1eolstart
startat25


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




1ediscussion point

The ccmcache value might be different in your environment.



1eolstart
startat26


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




1eolstart
startat27


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




1eolstart
startat28


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




1eolstart
startat29


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




1evirtualmachine

1ETRNW73


1eolstart
startat30


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


1ediscussion point

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.


1ediscussion point

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.


1ediscussion point

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:

1ediscussion point

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.


1ediscussion point

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.


1ediscussion point

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.


1ehot tip

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


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


1evirtualmachine

1ETRNCM 


1eolstart
startat31


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


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


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


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


1eli
Click OK to close the deployment screen


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


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


1eli

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

1evirtualmachine

1ETRNW72


1eolstart
startat39


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




1eolstart
startat40


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




1eolstart
startat41


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



1evirtualmachine

1ETRNW71


1eolstart
startat42


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




1eolstart
startat43


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




1eolstart
startat44


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




1eolstart
startat45


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



1evirtualmachine

1ETRNW73


1eolstart
startat46


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




1eolstart
startat47


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




1eolstart
startat48


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




1eolstart
startat49


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




1eolstart
startat50


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




1eolstart
startat51


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


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