Patch Management for Windows and Hierarchy/Replication 7.x

book

Article ID: 181877

calendar_today

Updated On:

Products

Patch Management Solution for Windows

Issue/Introduction

Question
How can Patch Management for Windows be used in a Hierarchy and with Replication?

Resolution

Answer
 

For 8.x Servers see KB TECH252766

This article aims to provide information as to how Patch Management for Windows solution can be used in a Hierarchy environment as well as explaining the workflow and use of the Patch Management replication rules. The document will also highlight some best practices and recommended use in certain scenarios.

 

Workflow and Replication Rules:

 

 Patch Management replication can be broken down into four separate steps:

 

1. Child Servers need to replicate their managed language information UP the hierarchy to the Parent Server.

 

2. Replication of Patch PMImport data down the hierarchy to the Child Server machines based on their managed languages.

 

3. Child Servers send Compliance Summary information UP to the parent.

 

4. Software Update Policies are created on the Parent and replicated DOWN to the Children.

 

1.      Child Servers need to replicate their managed language information UP the hierarchy to the Parent Server

 

In a hierarchy environment, the Child servers may be managing different languages to one another. For example, one Child may just manage English, while another may just manage German. In order to ensure that the Child servers only receive the data for their managed languages, there is a replication rule called the Patch Management Language Alerting rule.

 

When a language to manage is selected on the Patch Core Solution page, the table Inv_PM_Hierarchy_Installed_Culture is populated with this information. The Patch Management Language Alert rule replicates the data from this table up the hierarchy tree to the Parent. The Parent will then use this information to ensure that only the data for the managed languages of the Child is replicated down to the Child.

 

The Language Alert Rule is enabled by default on all Patch installs and by default will run on the Standard Replication schedules. It can also be run on a Custom schedule.

To view the rule, go to:

 

Settings > Notification Server > Hierarchy > Hierarchy Management > Replication tab > Resources section.

 

To configure the rule, select the rule and click on the Edit icon. This will open the rule configuration page which allows the selection of scheduling options and the Replication mode. 

 

If the rule has not been run on the Child prior to Patch data being replicated down from the Parent, then only Invariant language data will replicated down the hierarchy.

 

A Parent Server is required to manage all languages required by the Child Servers in its hierarchy.

 

2.    Replication of Patch PMImport data down the hierarchy to the Child machines based on their managed languages

 

The next step is to replicate patch data down the hierarchy. This process replicates all data that is imported via the PMImport at the Parent, down the tree to any Child NS’s. Only data for the managed languages of the Child will be replicated based on data sent up to the Parent via each Child’s Patch Language Alert replication rule. If the Parent has no language information from the Child, then only Invariant data will be replicated.

 

The Patch Management Import Data Replication For Microsoft rule will replicate the PMImport data down the tree. It will also trigger a post replication task that carries out the same tasks that a normal PMImport would carry out after data is imported.

 

This includes removing resources for languages that are no longer managed or removing resources for excluded Software releases and also updating the inventory rule cache on the server so that agents of the Child will be able to obtain the latest Inventory Rule data.

 

The post replication task will be sent from the Parent on the first running of the Quarter Hour shared schedule after the data replication job has completed. As this task is triggered by a schedule that runs daily, there will be a lag between the data being imported, and final clean up occurring. An instance of this task will be displayed on the Microsoft Patch Management Import page on the Child Server.

 

It can take around an hour to do an initial replication of one language to a Child if that Child has no previous data. 

 

The data replication rule can be found here:

 

Settings > Notification Server > Hierarchy > Hierarchy Management > Replication tab > Resources section.

 

To configure the rule, select the rule and click on the Edit icon. This will open the rule configuration page. It is not enabled by default.

 

It can be run in Complete or Differential modes and can be run according to the Standard Replication Schedules (created when a child is added to a hierarchy) or to a Custom schedule. Note that if run on a Custom schedule, the data will be replicated to ALL children in at once. The Standard Replication Schedules are created per Child so there will be a separate replication schedule for each Child in the hierarchy. 

 

3.    Replication of Compliance Summary Information UP the hierarchy

 

When the Daily Shared Schedule runs on an NS Machine, it will populate the Inv_Compliance_Summary  table with summary information regarding the number of applicable, installed and vulnerable updates for the agents of that Server. If the Server is a Child in a Hierarchy, the contents of that table will be replicated up to the equivalent table on the Parent.

 

A user can then run the Microsoft Compliance Summary report on the Parent, from the Console > Reports > Software > Patch Management > Complaince > Compliance Summary, and see a snapshot of the number of applicable, installed and vulnerable updates for the agents of that Child.

Note: The drill down will run a query from the Child Notification Server's database. The data is not replicated from the Child NS back up to the Parent NS.

 

 

The user can then select a row for a specific Child Server and drilldown to run the various more detailed Compliance reports (by Bulletin, Computer or Update) via remote console on the Child Server.

 

This allows the user to then choose which updates to create policies for and replicate down the hierarchy.

 

 

4.    Replication of Software Update Policies down the hierarchy

 

Once data has been replicated, Software Update Policies created on the Parent can be replicated down to the Child Server’s.

 

This is done via the Patch Management Software Distribution Replication for Microsoft replication rule.

 

The rule can be accessed here:

 

Settings > Notification Server > Hierarchy > Hierarchy Management > Replication tab > Resources section.

 

To configure the rule, select the rule and click on the Edit icon. This will open the rule configuration page. It is not enabled by default.

 

On this configuration page, the software update policies to be replicated can be selected and added to the rule. Note that the policies must be added to the rule otherwise they will not be replicated. This is configured at: Console > Settings > Notification Server > Hierarchy > Replication Tab > Resources Dropdown, and highlight the Patch Management Software Distribution Replication for Microsoft. Then select the Pencil Icon on the toolbar to Edit the rule. In the Rule Window, select the Software Update Policy link (0 Software Update Policies), and add the software policies for Patch Management in the Selected Items pane from the Available Items pane. Select OK and the policies are added.

 

The rule can be run in Complete or Differential replication mode and can be run to the Standard Replication Schedules or a Custom schedule.

 

On the Child, the policies and advertisements will be imported first – however the packages will not initially exist. Once the initial replication job is complete, on the first running of the Quarter Hour shared schedule on the Parent, a post replication task will be sent to the Child which will kick off Recreate Packages for the bulletins contained within the replicated policies. This will download the packages (from Microsoft) to the Child server’s staging location and once complete, the replicated SW Update Policies will be ready for distribution. There is potentially a lag time of days between the initial import of the policies and the download of the packages(This depends on NS performance and the amount of packages being replicated), however it may take as little as 1 hour, again depending on NS performance and packages being replicated.

 

Before the packages are downloaded, the policies will effectively be incomplete and if agents request configuration in that lag time, there will be errors recorded in the logs (see KB article 45882). Once the package download is complete, the errors will no longer occur.  

 

The replicated policies will be read only apart from the ability to enable/disable the policy and to change the default resource target.

 

Its important to remember that the policies are controlled/managed by the Parent server. If a replicated policy requires modification, it will need to be modified on the Parent first and then re-replicated to the relevant Child Server. Revise Software Updates should not be run on Child servers (see section below on Revise SW Updates on Child Servers).

 

Once the policies have been replicated and it is confirmed that they have been received at the Child node, it is best to remove the selected policies from the replication rule configuration page so that they are not replicated with each run of the selected schedule option.

 

Specific Items

 

Software Release Exclusion:

 

Software Release Exclusions must be set on the Parent Server. The selected exclusions will be replicated down to Child servers and resources removed when the post replication PMImport clean up task runs. If exclusions have previously been set on the Child, they will be overwritten during the replication process. The ability to select exclusions on a Child server will be disabled when –

  • The Patch data replication rule is enabled on the Child Server. Note that if the rule is enabled on the Parent, Item replication will result in the rule being replicated and thus enabled on the Child.

 

Custom Severities

 

Custom Severities must be created and assigned on the Parent server. Once a Child server is part of a hierarchy and is receiving Patch data via replication, Custom Severities cannot be set on the Child server. If Custom Severities have been previously created and assigned on a Child Server, they will be overwritten by the replication process. The ability to create and assign Custom Severities on a Child server will be disabled once –

  • The Patch data replication rule is enabled on the Child Server. Note that if the rule is enabled on the Parent, Item replication will result in the rule being replicated and thus enabled on the Child.Revise Software Updates on Child Servers:The Revise Software Updates task should not be run on Child Servers. If the task is run and needs to add new advertisements to a Software Update Policy, these advertisements will be owned by the Child Server. If the policy is then replicated down again from the Parent, there will be a duplicate advertisement present owned by the Parent. This can result in errors when Recreate Packages is called on the Child Server. Revise Software Updates should only be run on the Parent Server and revised Policies replicated down to Child Servers. This is consistent with the centralised management concept of Hierarchy and Replication. The option to run the task at the end of PMImport will also need to be disabled on the Parent server to prevent the task inadvertently running on the Child after Patch data is replicated.  In future Patch releases, there will be functionality added that will prevent the task from running on a Child Server.

 Best Practices Settings for the Patch Replication / Schedules:

  • Patch Management Software Distribution Replication Settings:
    • Scheduled: Daily - Early AM (1am) - Complete replication
           Note: Remove all old policies from the Parents settings for replication once they are no longer needed. This helps to increase replication performance, for the updates only need to replicate initially and if any changes occur.
       
  • Patch Management Import Data Replication for Microsoft:
    • Scheduled: Daily - Late Evening (7pm) - Differential replication
       
  • Patch Management Language Alerting
    • Scheduled: Daily - Whenever convenient - Complete replication

Note the following:
Child NS Needs to have internet access or HOWTO9724 setup for DMZ

If there is a Site Server for the Parent, the packages need to be in a ready status on that Site Server before they will replicate to the Child.
 

 

 

Patch Management Import (PMImport) on Child Servers:

 

To prevent the PMImport from importing data on a Child Server, enable the Patch Management Import Data Replication rule on that child server. The PMImport task will still be triggered at its scheduled time, however it will not import any data as with the rule enabled, the task recognises that the Server is a Child in a hierarchy.

Item Replication will replicate the Patch Data replication rule itself to the Child machine which will result in the rule being enabled.

 

Adding or Removing Managed Languages:

 

If a new managed language is added to a Child Server, the Patch Management Language Alerting rule will need to be run on the Child in order to replicate that information to the Parent Server. It is then recommended to run the Patch Data replication rule in ‘Complete’ replication mode to that Child to ensure that all required information is replicated. This will only need to be done once and the rule can be switched back to Differential mode afterwards.

If a managed language is removed from the Child Server, the Patch Data replication rule does not need to be run in Complete mode as the removal of the resources for that language will be done by the Post Replication Clean Up task.

 

To update existing Software Update Policies on the Child with new language information, the policies will need to be first revised on the Parent (if required) and then re-replicated to the Child nodes.

 

Scheduling Options:

 

All Patch Management replication rules can be run to one of two scheduling options –

  • Standard Replication Rules – if this option is selected, the Patch replication rule will be run when either the Differential or Complete replication schedule is run for a particular Child server. Note that with this option, the Patch replication rule will run in the replication mode of the schedule, not the mode selected on the Rule configuration policy.
  • Custom/User Defined schedule – if this option is selected, a user defined schedule can be created for the replication rule. Note that with this option, the rule will run for ALL Child Servers at once.

 It is important to be aware of when Patch Data and Software Update Policies are being replicated. This is so the Child Servers have the latest data set before the Software Update Policies are replicated.

 

 

Monitoring Progress:

 

There are a number of methods that can be used to check on the progress of the job –

  • Reports – The Notification Server report ‘Current Replication Activity’ can be run to check on the progress of a replication job. Note that the report only shows results when a replication job is running.
  • Logs – The logs can be used to see when various replication jobs are starting and ending.