Introducing Patch Policies

In talking with existing ZENworks Patch Management there were several common problems that we’ve heard, most dealing with administrative overhead. In ZENworks 11SP3 we are introducing Patch Management Policies to address the most common complaints we’ve heard. With Patch Management Policies you create a set of Rules based policies that help determine the patches that should be applied to the device and then you define when those policies should be put into effect. Once this is done then your job generally becomes seeing if the updated policy applies correctly on your test machines and then pushing a button in ZCC to publish the policy to your production workstations. Even the last step can be automated if desired.

Configure Patch Policies

A Patch Policy is a new type of object that can be created from the Policy tab under the Patch Management section of ZENworks Control Center. A Patch Policy is an object that represents the desired state for your devices. The following configuration is available for a Patch Policy object.

Summary Tab

The Summary tab allows you to see key information related to who the policy has been enforced on and its configuration. The key configuration options available on this page are:

• Auto approve patches after successful sandbox enforcement. This causes an automatic publishing of the policy from sandbox to published once all of the test devices assigned to the policy have successfully reported back that they have enforced the policy. When enabled you can specify a number of days after the successful sandbox enforcement to trigger the publish on.

• Time to recalculate policy from rules. This causes any new patches that have been added to the system that meet the rules and that are enabled to be added to the policy when this recalculation happens. This also means that superseded patches are now automatically replaced with the replacements.

• Last Rebuild Date.
This indicates the last time the policy was updated with the latest content and latest assignment details. If you make a change to an assignment you should manually rebuild this to cause an update of the Patches tab.

Relationships Tab

The relationships tab allows you to control which devices should be subject to the policy. Any devices, groups or folders listed will automatically receive all of the patches that are a part of the policy which are Applicable and which aren’t already installed on the device. Each time the Rebuild of the policy is triggered this list of devices is used to determine which devices patch results should be pulled in for the Patches tab view of compliance to this policy.

Requirements Tab

The requirements tab allows you to limit the conditions under which the patch policy should be applied. For instance you can prevent the policy from being applied if the device is at or not at a specific location. This can be used in the same way the Requirements tab is used for all other bundles or policies.

Rules Tab

The rules tab allows you to define a set of filters that define the patches that should be deployed. This means that I can create rules such as all Microsoft Critical Patches, All Critical Patches, etc. Each time that the Patch Policy is updated the Rules are reprocessed and any new patches that have been added are included and any that no longer meet the rules are removed.

Note:All patches that you include via either the members tab or the rules are automatically cached, so be sure that you have plenty of disk space before finalizing the patch policy.

Members Tab

If you want to add additional specific patches, besides those that meet your rule criteria you can add those here. This allows you to deploy other important patches besides those automatically included by the rules. For instance you may want to deploy all critical patches via a rule, but add a few Recommended patches that you consider important for your environment.

Actions Tab

On the Actions page you can configure actions that should occur either before or after the patches that are a part of the Rules or Members tabs. This allows you to perform actions such as stopping services, running scripts, or even launching a bundle.

Patches Tab

This tab shows a policy specific view of the overall patch status of the system. It is built each time the policy is built and includes only the patches that are a part of the policy and only devices that are assigned to the policy. This gives you an easy way to check the status of those devices assigned to this policy.

By using Patch Policies you can establish a desired state and a desired process for patching the devices and then let the system do the rest of the work on a periodic basis. If you have enable automatic publishing after test deployments, this essentially means that unless the policy needs to change that the devices in your organization will continue to maintain compliance to this policy until a patch fails to apply to the test devices appropriately.

Configure Patch Policy Distribution Settings

In many cases you will want to distribute the content for the patch policy to the devices prior to actually transacting the patch policy enforcement on the device. To do this you can configure a Patch Policy Distribution Schedule as shown below:



This allows you to configure a window of time when the patch policy content should be distributed to the device. On this page you can specify both a start time and a duration. Any location specific throttle rate will be used when distributing the content to the device.

Configure Patch Policy Enforcement Settings

Probably the most important setting related to patch policy scheduling is the Patch Policy Enforcement Schedule. This allows you to control when the patch policy payload is deployed to the device and what happens if a reboot is required on the device. Patch Policy Enforcement Schedules can be configured at the individual device, folder or zone level. By default Patch Policies are only applied when initiated at the device via the ‘zac patch-policy’ command. Patch policy enforcement schedules allow you to define a window of time where the device is available for patching. The dialog below shows the configuration options for scheduling patch policy enforcement:



Notice that in this scheduling control you can set both a Duration and a Start time. This means that if you want to make sure that your devices are patched from 10:00 PM – 2:00 AM you can set the start time to 10:00 PM with a 4 hour duration. This will cause patch policies to begin applying to the affected devices at 10:00. If all of the required patches are not completed by 2:00 AM then whatever patch may be installing at 2:00 AM will be completed and then depending on the reboot settings, shown below, the machine may reboot. Any additional patches required by the policy will be applied the next time that the schedule becomes active.

Note:If you want to enforce a policy immediately on a device you can use the ‘zac patch-policy’ command on the device. Also the Patch Policy Enforcement Schedule only impacts patches deployed via policy. If you need to immediately deploy a patch to a set of devices you can still do a onetime remediation of the patch.

Also in your Patch Policy Enforcement Settings you can set the Notification and Reboot settings that will be used to notify your users that patches are being applied, allow them to snooze the deployment and determine reboot behavior as shown below:

Other Patch Management Enhancements

The following are additional patch management enhancements made in 11SP3:

• When a machine applies patches if will only download the patch content and apply the patch if the patch is both APPLICABLE and NOT PATCHED. This means that if you have a single patch policy for Microsoft Critical Patches that only the critical Microsoft patches required by the individual machine will be downloaded to the device. This capability also applies for regular patch deployments and mandatory baselines.

• Patch subscription status and recent patches snapshots have been added to the dashboard making it easy to see an overall status of your patch management system.

• Patch audit log has been disabled by default. This will cause a significant reduction in the amount of data accrued in the database over time. Additionally, this means that the Patch Compliance time graph on the dashboard will be blank by default. Novell does not recommend enabling this capability in enterprise environments. In a small environment you can enable this capability in the Dashboard and Trending settings for Patch Management.

• Last Discover Application Updates scan date is now stored in the database. This allows you to create reports to discover when the last time your devices ran a patch scan was. The Time Since Last Agent Refresh graph on the Patch Management Dashboard has now been replaced with a Time Since Last Agent DAU.

• Improved reboot controls that allow you to control tray notification duration, tray notification text, and the reboot and snooze times with more granularity.

• Improved performance through enhanced indexes and multi-threading of the patch management loader module.

• The updated ZENworks Reporting solution in ZENworks 11SP3 includes support for reporting on patch management capabilities.

Summary

ZENworks 11SP3 Patch Management makes it easier than ever to keep your device estate patched with the most current patches and do so in an efficient, many times hands-off manner. Additionally with added controls for improved reboot handling and performance improvements you can get this done faster and with happier end users.