6.2 Creating and Publishing Patch Policies

Keep the policies reasonably simple. Try to organize individual patch policies around a common outcome, for example: assuming some of your stock is comprised of Windows 10 machines; setup a policy called Win10 and use this to deliver all Microsoft updates to those targets. Similarly, you could organize policies by vendor or architecture.

Devise a naming convention for your policies; this will enable you to track policies more easily, and will also make it simpler to make changes to individual policies.

When you are setting up individual policies, try to plan into the policy. For example: in real terms, how often will a policy be deployed? does that specific vendor have regular updates? and what would your expectation be for throughput? It is our general recommendation that you should have a team process to steer your approach to this. This is in line with NIST recommendations.

When you are designing policies, be careful not to apply conflicting statements. There are a lot of different settings built in to ensure that policies can perform some very useful tasks, but be aware that changing Rules, Requirements, Actions, Relationships, and Members may bring your policy into conflict with previously defined settings.

Choose a schedule type based on network load, for example: it might be advisable to schedule policy deployments out of hours or at times when you know that your network will be least busy.

Use the Patch Policy Enforcement and Distribution settings in ZENworks > Configuration to their full extent, especially around Reboot settings; why reboot if the patch does not require this?

Use the Sandbox function to its full extent. We cannot stress how important it is to test patches before deploying them, especially over big networks. It is therefore prudent to set up a test server or a proving ground and deploy to this in the first instance. Once there has been a clean and issue free deployment, then you are ready to release to the wider network.

For more information, see Test a Policy Before Deploying to a Live Environment.

Do not overload the policy. Patch Management has a default limit of no more than 1500 bundle actions per policy. This is to keep policies within a manageable parameter. If you believe your patch server has performance issues due to the number of patch bundle actions, you can divide up your patch polices with a more defined set of rules and requirements for each policy, which will reduce the number of actions per policy.

You can also modify the default limit for policy bundle actions with the use of the system variable, PATCH_POLICY_ACTIONS_LIMIT. For information about setting the variable, see Patch Management System Variables.

Continually monitor patch policies, ensuring that you have the available space and bandwidth to avoid any calamity on your network. If you have large groupings among your assets, it may be necessary to stagger deployments; this way you will not impact the integrity of your network, and normal operating can continue alongside the task of protecting against future problems.

If you want to make changes to the schedule of a Patch Policy, ensure that you configure it within the Patch Policy Settings page. If the schedule is configured within any other page of ZCC, such as Device's Assignments or the Bundle's Relationship page, under Assignment Details, it will not override the schedule that was previously defined in the Patch Policy Settings page. Instead, it will be run multiple times, based on the schedule configured within each page.

If you delete an old patch policy from an end point and then publish a new policy to replace it, the end point may list a Device-Assigned Bundle Status of Not Installed for an indefinite period of time. If you encounter this end point status, reboot the end point to complete publication of the patch policy.

Vendors will occasionally supersede Critical patches with Recommended patches. For example, Microsoft sometimes releases a second recommended Windows 10 cumulative update later in the month that supersedes an earlier critical update. The recommended update fixes the same security issues as the superseded critical update, but no new security issues are fixed so Microsoft rates it as Recommended rather than Critical.

If you want to continue to distribute the Critical patch rather than a Recommended patch that supersedes it, you can use the following options:

For example, assume that you have a Patch policy that installs all Microsoft critical patches. If Microsoft releases a second recommended monthly update that supersedes the critical monthly update, the superseded critical monthly update will no longer be distributed by the policy and the recommended update will not be included in the policy (even if the policy is rebuilt) because it is not critical. To avoid this situation and ensure that devices continue to receive the critical cumulative update, you would need to enable the “Do not disable superseded patches that are included in a policy” option.

A second example would be a Patch policy that installs all patches with “Cumulative Update for Windows 10” in the name. Occasionally, Microsoft releases a preview patch with “Cumulative Update Preview for Windows 10” in the name. The preview patch, which is recommended, supersedes the critical cumulative update so the policy no longer installs the superseded critical update. In this situation, enabling the “Do not disable superseded patches that are currently in a policy” option would also resolve the issue.

The two supersedence options are in the CVE and Patch Cleanup settings in ZENworks Control Center (Configuration > Management Zone Settings > Security > CVE and Patch Cleanup).