Using Patch Management for Windows in a Hierarchy and with Replication

Products

• IT Management Suite
• Client Management Suite
• Patch Management Solution
• Patch Management Solution for Servers

Issue/Introduction

This article provide information on using Patch Management for Windows Solution in a Hierarchy environment as well as explaining the workflow and use of the Patch Management replication rules. This also highlights some best practices and recommended use in certain scenarios.

Environment

ITMS 8.x

PM 8.x

Resolution

Quick Setup

 

Best Practice settings for the Patch Replication Schedules are found in the SMP Console > Hierarchy Management > Replication Tab > Resources:

1. Patch Management Import Data Replication for Microsoft:
   1. Scheduled: Daily - Late Evening (7pm) - Differential replication
   2. Note: This may be configured for 'Complete' replication to assist with replication troubleshooting of the PMImport data
2. Patch Management Language Alerting
   1. Scheduled: Daily - Whenever convenient - Complete replicationAdditionally:
3. Additionally, enable the Revise Software Update Task on the Parent Notification Server's SMP Console > Manage  > Jobs and Tasks > System Jobs and Tasks > Software > Patch Management > Import Patch Data for Windows (or other needed vendors)

Best Practices Settings for the Patch Replication / Schedules are found in the SMP Console > Hierarchy Management > Replication Tab > Configuration and Management Items: 

1. Enable replication for standard configuration and management items such as policies, filters and reports. Configuration and management items replicate down the Hierarchy.
   1. Set to 'All'
2. WARNING: Any customization settings will be cleared for Filters, Policies & Reports if this default setting is enabled.

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:
   

   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 Server 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. Child Servers send Compliance Summary information UP to the parent:
   

   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 > Compliance > 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 / Not applicable to by CVE-ID) 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. Software Update Policies are created on the Parent and replicated DOWN to the Children:

Replication for the Software Update Policies down the hierarchy to the Child NS is now handled on the default daily replication schedule. This is default setting of 'Differential' and the policy will not be replicated until it has been changed. The Software Update Policy may be replicated now by highlighting / right-click > Hierarchy > Replicate Now.

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.

Advisory: Please note the following:

If there is a Site Server for the Parent, the packages need to be in a ready status on that Site Server before the manifest for the Software Update Policy will be generated and replicated to the Child NS. When the Daily Replication job finishes, the manifest replication for the Software Update Policies will be complete, and the Software Update Policy will be created from the manifest data on the Child NS. The Download Software Update Package job will run on the Child NS; hitting the SolutionSam and any other 3rd Party Sites as needed, and creating the Software Update Packages on the Child NS. 

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