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