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:

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

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:

Click Patch Management in the navigation menu, and select the Patch Policies page.
Click New in the Patch Policies panel.
Choose a platform, and click Next.
Name the policy, add any descriptive notes to identify the policy by, and click Next.

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.

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.

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	Approves and applies patches to non-test devices after they are successfully tested in the Sandbox on one or more test devices.
Approve after x days	Approves patches the number of days specified after a successful test.
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 assigning 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:

Go to Patch Management > Patch Policies.
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

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

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.

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

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 Assign Devices to a Patch Policy

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:

Go to the Patch Policy Summary page (Patch Management > Patch Policies), and click the patch link in the Name column.
Select the Relationships page, and click Add.
Click the down arrow for Devices to display the type of devices available.
Click the down arrow for Servers or Workstations to display the groups and devices for the selected folder.
Select the devices that are targeted for patch testing or deployment to move them into the Selected panel, and then click OK.

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

Beginning in the navigation menu, click Devices > Workstations.
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.
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.”
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.5 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:

Go to the Patch Policy Summary page, Patch Management > Patch Policies, and click the patch link in the Name column.
Review the policy configuration in the Summary page (if applicable, make changes).
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.
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.