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

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


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

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

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



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


    Toggle between 32bit and 64bit

    CVE Identifier

    Insert a relevant CVE code


    Choose Impact of patch ‘Critical’ or ‘Recommended’.

    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


    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. In the next page configure the settings for the Patch Policy rebuild schedule and publish schedule as defined below:

    Rebuild Schedule

    The Rebuild Schedule determines how often you want the Patch Policy to rebuild. The build essentially refreshes the policy to include any patches matching rules that you set in the policy that have been released since the last build and delivers those patches to assigned devices. Building the policy without publishing enables you to install patches on Test devices before deploying the policy in your operational environment.

    NOTE:In addition to the schedule you define here, you will have the option to build the policy upon creation rather than waiting for the first scheduled build; or, you can run a build manually at anytime after policy creation by navigating to the Automation page on a selected policy.

    Configuration options for the build schedule are described below:

    • Days of the week: This option enables you to schedule the build on selected days of the week.

      To set the build day, select the Days of the week button, select the required day or days of the week, and set the start time for the build.

    • Monthly: This option enables you to specify the monthly build options.

      In the Monthly build option, you can specify the following:

      • Day of the month: Enables you to schedule the build on a specific day of the month. You can specify any number between 1 and 31.

      • Last day of the month: Enables you to schedule the build on the last day of the month.

      • Particular days of the month: Enables you to schedule the build on a specific day or days of every month. The valid options for the day are first, second, third, fourth, and fifth. The valid options for the weekday are Sunday through Saturday. To select one particular day of the month, use the drop-down arrows.

        To select an additional day of the month, click the Plus icon and use the drop-down arrows in the second row. To remove a particular day from the list, click the Minus icon.

    • Fixed Interval: This option enables you to schedule a recurring build that runs after a fixed duration on a regular basis. You can choose the number of months, weeks, days, hours, and minutes of the interval and the start date and time for the build schedule.

    Publish Schedule

    The Patch Policy does not get enforced on operational devices until it is published. However, we highly recommend that you test the policy in Sandbox mode before publishing to your live environment. For more information, see Test a Policy Before Deploying to a Live Environment.

    Publish options are defined below:

    • Do not publish: This option is the default setting for the policy and requires you to manually publish the policy, which you can do directly from the policy or from the Action menu with the policy selected in the Patch Policies page.

    • Publish immediately: This option has no backstop for deploying the policy on Test devices and we recommend that you use it with caution.

    • Publish after successful Sandbox version enforcement on __% of test devices: This option will publish the Patch Policy automatically after the percentage of test devices specified here is successfully patched. The default setting shown in a new policy subscribes to the percentage set in the Patch Test Devices configuration.

      • Delay publishing for __ days after successful enforcement: This option is only enabled if you select the parent option. Valid numbers are 0 through 90.

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



    Create as Sandbox

    Enabled by default and strongly recommended in order to test the policy before deploying in your live environment. You cannot disable the setting unless you deselect the Build policy on creation option, which is also set by default.

    Build policy on creation

    Enabled by default. Builds the patch policy upon policy creation to deploy patches to assigned Test devices.

    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 Build 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 based on the schedule you set when creating the policy. Both the manual Build option and the Rebuild Schedule are accessible from the Automation page on a selected policy.

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 six other pages where you can modify patch policy criteria:

    • Requirements

    • Rules

    • Members

    • Actions

    • Automation

    • 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




    Toggle between 32bit and 64bit


    Bundle Installed

    Choose between installed bundles


    Configuration Location

    The location of the server


    Configuration Network Environment

    Select the network environment



    Connected or Not Connected


    Connection Speed

    Choose the speed of the connection


    Disk Space Free

    Select by Disk space available


    Disk Space Total

    Select by Disk space total


    Disk Space Used

    Select by Disk space used


    Environment Variable Exists

    Is there a pre-existing variable


    Environment Variable Value

    The value of the pre-existing variable


    File Date

    Select by File date


    File Exists

    Select by pre-existing File name


    File Size

    Select by File size


    File Version

    Select by File version


    IP Segment

    Select by pre-existing File date


    Linux Distribution

    Select the Linux variants to target


    Linux Kernel version

    Select the Linux Kernel version to target


    Linux Service Pack

    Select the Service pack version to target


    Logged on to Primary Workstation

    Select Logged on or not Logged on


    Mac Distribution

    Select the Mac OS version



    Choose the memory


    Novell Client Installed

    Novell client installed - yes or no


    Operating System- Windows

    Choose the Windows variant


    Primary User is Logged In

    Primary user logged in -yes or no


    Processor Family

    Select by Processor


    Processor Speed

    Select by Processor speed


    Registry Key Exists

    Add a Registry Key and choose yes or no


    Registry Key Value

    Add a Registry Key value and yes or no


    Registry Key and Value Exists

    Add a Registry Key and Value and yes or no


    Security Location

    Select by security location


    Service Exists

    Insert a Service name and yes or no


    Specified Devices

    Add specific devices (has search function)


    Version of Application

    Select by Application Version


    Version of RPM

    Select by RPM Version


    ZENworks Agent Version

    Select by ZENworks Agent version


  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.

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

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

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

Publish after successful Sandbox version enforcement

If the patch policy has Publish after successful Sandbox version enforcement configured, the policy will automatically enforce on non-Test devices assigned to the policy after successfully applying ALL patches to the percentage of Test devices specified in this setting.

Other considerations for this setting:

  • A patch scan determines and reports when the specified percentage of 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 the Rebuild Schedule), 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 Publish after successful Sandbox version enforcement is enabled, you can use the Delay publishing option in the policy Schedule 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 Satellites 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 Build Now option from the policy Automation 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.

6.2.6 Configuring the Success Rate for Patch Test Devices

When deploying a Patch Policy in a test environment, which is strongly recommended, you can configure the policy to automatically deploy to your live environment once the success rate percentage you define in the Patch Test Devices configuration is met. This configuration defines the default value shown in a patch policy when creating the policy. However, you can change the default value when creating the policy or anytime thereafter in the Policy > Schedule page.

The default setting in the Patch Test Devices configuration is 100 percent. To change the default setting, navigate to Configuration > Management Zone Settings > Security > Patch Test Devices.

For information about this setting in the Patch Policy, see the Publish Schedule settings, in the Create a Patch Policy section.

6.2.7 Publish a Patch Policy

If you chose to not Publish after successful Sandbox version enforcements in the patch policy configuration, you will need to publish the policy after executing Build 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. Select the Automation tab and click Build Now.

    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.