5.1 Creating and Publishing Patch Policies

Patch policies are designed to make deployment of multiple patches easier across large estates. They can be used as a testing ground for new patches before they are released onto the network, and can also be used to filter content, so that some devices can be selected or omitted as part of the patch remediation.

5.1.1 Patch Policy - Best Practices

In general use, the Patch Policy function is the most effective and labor saving way to deploy patches across large estates. Once set up, it can deliver the patches to the target machines with much less oversight than manual remediation.

While we advocate the automated setup that this function delivers, it is important to remember not to overstretch your systems or the capabilities of the product.

Recommendations:

  1. 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 7 machines; setup a policy called Win7 and use this to deliver all Microsoft updates to those targets. Similarly, you could organize policies by vendor or architecture.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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?

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

  8. 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.

  9. 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.

  10. 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.

  11. 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.

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

    • Delay the disabling of superseded patches for XX days: This option causes the superseded patch to remain enabled so that it can continue distributed to devices.

    • Do not disable superseded patches that are included in a policy: This option keeps a superseded patch enabled until it is removed from a Patch policy during the policy’s next scheduled rebuild.

    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).

5.1.2 Create a Patch Policy

Before creating a patch policy it is important to plan your deployment, and ensure that you know the devices you would like to reach and the remediations you would like to deliver. It is recommended that you setup a test machine to test the efficacy of the patch before deploying across a global environment. For more information, see Test a Policy Before Deploying to a Live Environment.

To create a new patch policy:

  1. Click Security in the navigation menu, and select the Patch Policies page.

  2. Click New in the Patch Policies panel.

  3. Choose a platform, and click Next.

  4. Name the policy, add any descriptive notes to identify the policy by, and click Next.

  5. Click Add Filter and select rules for the policy that will limit the patches cached in the zone to only those you need. The following filters are available:

    Filter Item

    Result

    Age

    Select by age of patch: in days, weeks, months etc.

    Architecture

    Toggle between 32bit and 64bit

    CVE Identifier

    Insert a relevant CVE code

    Impact

    Choose Impact of patch ‘Critical’, ‘Recommended’, or ‘Informational’

    NOTE:Software Installers are not included to avoid unnecessary risk. However, you can always add specific installers to the policy via the Members tab.

    For more information, see Step 4 in Configure Advanced Parameters.

    Patch Name

    Filter by Patch Name ie: MSxxx xxx

    Release date

    Select by Patch Release date

    Vendor

    Select by Patch Vendor

    It is also possible to add multiple filters; by clicking Add Filter Set, you can add a number of extra levels to further refine the patch cadre. For example, you could filter by Age + Architecture + Vendor.

  6. Once the selection is made, click Apply. The box below the selection tool will populate with relevant patches (assuming that you have replicated and have at least one registered agent).

    Review the Patches in the Included Patches table, and if satisfied to continue, click Next.

  7. Configure the final options for creating the policy in Step 4 of the wizard (see below), and then click Finish.

    Option

    Description

    Auto approve patches after successful test enforcements

    Automatically applies patches to non-test devices after they are successfully tested in the Sandbox on one or more test devices.

    Approve after x days

    Delays applying patches to non-test devices this number of days after a successful test in the Sandbox.

    Recalculate after x days

    Rebuilds the patch policy to include any filter changes after a number of specified days.

    After the policy is created, this setting can be modified in the policy Summary page by editing Time to recalculate patch policy from rules.

    Rebuild policy on creation

    Auto-rebuilds the patch policy upon policy creation.

    Define additional properties

    Opens directly to the policy editing pages after the policy is created. From here you can assign the policy and make other property changes. When this option is not selected, the Patch Policies list displays, and you have to open the policy from the list to define additional properties. See Configure Advanced Parameters.

Before you can test or publish a policy, you need to assign one or more devices to it and then execute the Rebuild function. Any changes to the patch policy after initially testing it, or publishing it, will not be effective until you either manually rebuild the policy or it is auto-rebuilt on the Recalculation interval.

For information on editing a patch policy, assigning the patch policy to devices, testing the patch policy, or publishing the patch policy, see the following:

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

Configure Advanced Parameters

To achieve an even more targeted remediation within the Patch Policy function, there are a number of advanced settings available. These settings are accessible when a patch policy is opened from the Patch Policies page or when Define Additional Properties is selected during patch creation.

To configure advanced parameters in a patch policy:

  1. Go to Security > Patch Policies.

  2. Click a patch name in the Patch Policies page to display the editing page options. In addition to the Summary and Relationships pages, there are five other pages where you can modify patch policy criteria:

    • Requirements

    • Rules

    • Members

    • Actions

    • Patches

  3. Select the Requirements page to configure filters from several variables that further define the devices that will get patched as a result of the patch policy.

    Click Add to choose a single filter option, or click Add Filter Set to insert the and/or operator between a set of variables.

    Filter Item

    Result

    Platform

    Architecture

    Toggle between 32bit and 64bit

    All

    Bundle Installed

    Choose between installed bundles

    All

    Configuration Location

    The location of the server

    All

    Configuration Network Environment

    Select the network environment

    All

    Connected

    Connected or Not Connected

    All

    Connection Speed

    Choose the speed of the connection

    All

    Disk Space Free

    Select by Disk space available

    All

    Disk Space Total

    Select by Disk space total

    All

    Disk Space Used

    Select by Disk space used

    All

    Environment Variable Exists

    Is there a pre-existing variable

    All

    Environment Variable Value

    The value of the pre-existing variable

    All

    File Date

    Select by File date

    All

    File Exists

    Select by pre-existing File name

    All

    File Size

    Select by File size

    All

    File Version

    Select by File version

    Windows

    IP Segment

    Select by pre-existing File date

    All

    Linux Distribution

    Select the Linux variants to target

    Linux

    Linux Kernel version

    Select the Linux Kernel version to target

    Linux

    Linux Service Pack

    Select the Service pack version to target

    Linux

    Logged on to Primary Workstation

    Select Logged on or not Logged on

    Windows

    Mac Distribution

    Select the Mac OS version

    Mac

    Memory

    Choose the memory

    All

    Novell Client Installed

    Novell client installed - yes or no

    Windows

    Operating System- Windows

    Choose the Windows variant

    Windows

    Primary User is Logged In

    Primary user logged in -yes or no

    Windows

    Processor Family

    Select by Processor

    All

    Processor Speed

    Select by Processor speed

    All

    Registry Key Exists

    Add a Registry Key and choose yes or no

    Windows

    Registry Key Value

    Add a Registry Key value and yes or no

    Windows

    Registry Key and Value Exists

    Add a Registry Key and Value and yes or no

    Windows

    Security Location

    Select by security location

    Windows

    Service Exists

    Insert a Service name and yes or no

    All

    Specified Devices

    Add specific devices (has search function)

    All

    Version of Application

    Select by Application Version

    Mac

    Version of RPM

    Select by RPM Version

    Linux

    ZENworks Agent Version

    Select by ZENworks Agent version

    Windows

  4. Select the Members page to add a specific patch to the policy.

    The patches can be selected by Name, Impact, Date, Vendor, or All and either added or removed. If you are using this feature in conjunction with other settings, it will ensure no duplication of caching, and the selected patch will stay as a member of the policy until it is removed.

  5. Select the Actions page to specify an administrative action before or after a deployment.

    Click the Add button on Pre-Enforcement or Post-Enforcement sections to open the selection menu. Each selection has its own set of custom parameters.

    End Process

    Choose to end a process -i.e. Notepad

    File Removal

    Choose to remove a file

    Install Bundle

    Select to install a bundle

    Launch Bundle

    Select to launch a bundle

    Launch Executable

    Launch an executable

    Run Script

    Run a custom script

  6. The purpose of the patches page is for the user to have control over the deployment of patches. When a policy is first created, the final step is to rebuild the policy. This is done using the Rebuild button on the policy Summary page. After this button is clicked, the list of patches in the Patches page should populate.

    After the page is populated with patches, click Actions and it will open a small menu. The options available are Enable, Disable, and Update Cache. When you have an action to take, check the box next to the patch you wish to take action with and select the appropriate action. The Patches page also contains information about patch deployment status, including patch impact, patch or not patched devices for a given patch, and the patch release date.

5.1.3 Editing Patch Policies

Using the Edit option you can make a copy of or rename an existing patch policy. You can save time by copying a patch policy when a complex patch configuration can be reused or slightly modified. The selection box must be checked to enable this option. When you copy a patch policy, the published version of the policy is copied.

5.1.4 Assign a Patch Policy to Devices

Once a patch policy is created and configured, you need to assign it to one or more devices. You can also assign it to a workstation group. If you have not already configured one or more devices as Test devices, see Test a Policy Before Deploying to a Live Environment.

To assign a patch policy to one or more devices:

  1. Go to the Patch Policy Summary page (Security > Patch Policies), and click the patch link in the Name column.

  2. Select the Relationships page, and click Add.

  3. Click the down arrow for Devices to display the type of devices available.

  4. Click the down arrow for Servers or Workstations to display the groups and devices for the selected folder.

  5. Select the devices that are targeted for patch testing or deployment to move them into the Selected panel, and then click OK.

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

The devices assigned to the patch policy will now be listed in the Relationships page. With the assignment complete, you are ready to test and publish the policy.

5.1.5 Test a Policy Before Deploying to a Live Environment

We advise ZENworks Administrators to always dry run their policies on a Test device before releasing to a live environment. Once a policy is released in a live environment, rescinding the changes that have been made can be difficult and time consuming.

Normally you would configure your Test devices before creating a patch policy for them; however, you can run a Rebuild at anytime. The Rebuild command uses the Sandbox to apply patches on all test devices assigned to the policy that is being rebuilt, according to the rules you configure for the policy.

If your test devices are configured as "Test" devices before they are assigned to the patch policy, applicable patches are automatically deployed to the test devices without rebuilding or publishing.

Understanding “Auto approve patches after successful test enforcement”

If the patch policy has Auto approve patches after successful test enforcement configured, the policy will automatically enforce on non-Test devices assigned to the policy after successfully applying ALL patches to ALL Test devices in the policy (post Rebuild).

Other considerations for this setting:

  • A patch scan determines and reports when all Test devices assigned to the policy have all applicable patches installed.

  • Having any of your assigned test devices offline for an extended period of time could impact the timing of non-Test devices assigned to the policy from getting patched.

  • Rebuilds (whether manual or automatic from recalculation), that are spaced too close together, could impact the timeliness of patching, because a rebuild restarts the patching of any uninstalled patches on Test devices according to the schedule set in the patch policy.

  • Once all assigned Test devices are successfully patched, the patch policy is published, irrespective of any schedule settings. However, when Auto approve patches after successful test enforcement is enabled, you can use the Auto approve time delay option in the policy Summary page to delay this action.

  • Patches are not applied to any devices (Test or non-Test) until the ZENworks Agent is refreshed on applicable devices.

To configure one or more devices for Test:

  1. Beginning in the navigation menu, click Devices > Workstations.

  2. Select the check box for one or more devices. Only workstations or satellite servers can be configured for test, a Primary Server cannot be used for testing while operating as a server.

  3. Open the Action drop-down menu, and select Set as Test.

    Once you have made the selection, a small yellow arrow appears on the workstation icon . If you mouse over the workstation icon, an info box displays “Test Workstation.”

  4. If you assigned the test device(s) to the policy before configuring it as a test device, you can now execute the Rebuild option from the policy Summary page to test the policy. Otherwise, make the assignments before testing the policy.

NOTE:You can also configure devices for testing directly from the device Summary page by clicking the Set link on the Test Device item. However, you can only configure one device at a time in this manner.

5.1.6 Publish a Patch Policy

If you chose to not auto approve patches after successful test enforcements in the patch policy configuration, you will need to publish the policy after executing Rebuild to apply patches to policy-assigned devices that are not set as Test devices.

To publish a patch policy:

  1. Go to the Patch Policy Summary page, Security > Patch Policies, and click the patch link in the Name column.

  2. Review the policy configuration in the Summary page (if applicable, make changes).

  3. Click Rebuild in the Summary page.

    When the policy is first created, its default status is Sandbox in the Displayed Version menu at the top of the page. If the policy was previously published, it will have one or more policy versions to choose from here.

  4. Click Publish to update the information in the summary box and to publish the policy.

    If you return to your agent device and refresh it, you will see the policy in the ZENworks Agent window.

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