This section contains detailed explanations of the error messages you might receive or problems you might encounter when using ZENworks Patch Management. You can also reference these online references:
NOTE:If you cannot resolve an issue related to Patch Management using this troubleshooting section or the online resources above, please contact Technical Support.
Review the issues below to see if any them are applicable to your patch environment and take the prescribed action where needed.
Patch Content Download Fails for Slack or TreeSize
Source:
Patch Management, Advanced Patch Feed
Explanation:
In the Advanced Patch Feed, when you try to perform the remediation of Slack or TreeSize software, the patch content download fails.
Unable to Trigger Patch Scan on SLES Devices
Source:
ZENworks 23.3, Patch Management
Explanation:
Patch Scan might not be triggered on SLES devices.
Possible Cause:
This might be due to missing RPMs. Ensure that the following RPMs are available on the device:
Action:
Run the following command to install the missing RPMs:
rpm -ivh <rpmname>
In the above command, replace “rpmname” with the following RPMs:
The Version Installed with the Remediation Bundle and Version Available on The Device Are Not Identical
Source:
ZENworks 23.3, Patch Management, Advanced Patch Feed
Explanation:
A browser version installed with Remediation Bundle and the browser version available on the device is not identical.
Possible Cause:
When Auto-update for a browser is enabled, then the version installed using Remediation Bundle might be updated to the latest available version. Hence, the version installed using the remediation Bundle and the version available on the device might not be identical.
Action:
Disable the auto-update feature on the browser.
The Patch Scan Fails on Linux Agents
Source:
ZENworks 23.3, Patch Management, Advanced Patch Feed
Explanation:
In the Advanced Patch Feed, the patch scan fails on Linux (SLES 12 and SLED 12) agents, and the Error while initializing scanner message is logged in the PatchScan log file.
Action:
Patch Management does not support SLES12 SP4 and below versions. Ensure that you update the device to a higher SLES version that is supported by Patch Management.
Superseded Patch Updates are not Pre-cached in the Airgap Server
Source:
ZENworks 23.3, Patch Management, Advanced Patch Feed
Explanation:
In the Airgap zone, superseded patch updates are not pre-cached
Possible Cause:
This might be due to the behavior that the superseded patch might not be detected during the first scan and thereby the patch will not be pre-cached.
Action:
The issue will be resolved during the next transfer of patch content to the Airgapped (importer) zone.
Patch Services does not honor changes to Local Device Logging settings
Source:
ZENworks 2020 Update 3
Explanation:
At the zone level, in the Local Device Logging (Configuration > Device Management) setting, when you modify the and settings, the changes might not be honored by Patch Services.
This issue is applicable and observed only when the ZENworks environment that you have is updated to ZENworks 2020 Update 3 and migrated to the new patch feed, or if you have deployed ZENworks 2020 Update 3 from a new installation.
Action:
In the following location, configure logging for Patch Services in all the Primary Servers.
Patch settings are hidden even after activating the Patch Management license
Source:
ZENworks; Patch Management
Explanation:
Some of the patch-related settings are hidden even after successfully activating the Patch Management license.
Possible Cause:
This might happen only when the administrator deactivates Patch Management and then reactivates Patch Management in the evaluation mode or by providing a key.
Action:
After activating the license, log out and re-login to ZCC.
In the Advanced Patch Feed, the Patch Deployment with Reboot Action Fails
Source:
Advanced Patch Feed, ZENworks 2020 Update 3, Patch Management
Explanation:
In the Advanced Patch Feed, when you initiate a patch scan on older agents and deploy a patch with reboot action, the patch deployment and patch reboot might not work as expected.
Action:
None.
Patches are unavailable because of connectivity or firewall issues
Source:
ZENworks; Patch Management.
Explanation:
Ensure that your server environment can access patch providers and hosts and that applicable clients are properly configured for Office 365 updates.
No patches are shown in the Patches page
Source:
ZENworks; Patch Management.
Possible Cause:
The server has just been installed.
Action:
You need to wait for managed devices to run a patch scan and report their results. Patches will begin to appear at that time.
Patch remediation bundles are not replicating to Primary servers
Source:
ZENworks; Patch Management.
Possible Cause:
The patch remediation bundle(s) was modified.
Action:
Patch remediation bundles from patch policies or deployment remediations should not be modified.
Patches do not seem to be deployed on the target device
Source:
ZENworks; Patch Management.
Possible Cause:
The ZENworks administrator has not deployed the patches into the applicable devices in the ZENworks server, or the patches have been deployed in the server but the device refresh schedule has not been triggered in the ZENworks Agent.
Actions:
Check to see if the option is set as or on the Configuration page, and wait for the specified interval.
The Cancel button disappears in the Reboot Required dialog box
Source:
ZENworks; Patch Management.
Explanation:
When two or more patches are deployed, if the option is set as No on the Pre Install Notification Options page and the Notification and Reboot Options page of the server, the button disappears in the Reboot Required dialog box for all patches of the agent.
Action:
None necessary.
Superseded patches are shown as NOT APPLICABLE
Source:
ZENworks; Patch Management.
Explanation:
In earlier releases of Patch Management, a patch showed its status as PATCHED or NOT PATCHED, regardless of whether the patch was new or outdated. This often caused many more patches to show as NOT PATCHED than were actually necessary for deployment to a given target device. This issue has been addressed in many of the new advanced content patches provided with ZENworks 2017:
-
When a patch is superseded, it is automatically disabled.
-
If the patch is re-enabled and detected, in most cases the patch shows as NOT APPLICABLE because it has been replaced by a superseded patch. However, if the device has not installed the superseding patch then the re-enabled patch will show as properly scanned (either patched, not patched or not applicable depending on the device patch state of the original patch).
Although this is inconsistent with the behavior of earlier versions of Patch Management, this change is an improvement because only the patches that currently need to be installed are reported or analyzed on each device.
Action:
None necessary.
Patch deployment might not start when scheduled
Source:
ZENworks; Patch Management.
Possible Cause:
If the deployment schedule type includes both the and options, when the device becomes active, the deployment of the patch does not start on the first of its scheduled recurring dates. However, the patch is deployed when the next recurring date occurs.
Action:
Instead of selecting a recurring schedule, select a date-specific schedule so that the patch is applied when the device becomes active.
Linux - Custom Patches: Bundles fail to launch
Source:
ZENworks; Patch Management.
Possible Cause:
RPM Application Bundle and Custom RPM Bundle fails on both SUSE as well as Red Hat when it is assigned to the device with Launch Schedule On Device Refresh.
Action:
Work around for the custom patch: Add 1-2 minutes of delay execution after refresh for “Remediation Schedule” to resolve it.
Airgap Server: User receives trial license email after adding the license info to system variables
Source:
ZENworks; Patch Management.
Explanation:
After setting up an Airgap server, you receive trial license emails from the server although you’ve added your license to the Airgap server system variables.
Possible Cause:
The Airgap server requires the Patch Management license file from the connected server.
Action:
Contact Micro Focus Support.
Blank PowerShell window is displayed after deploying patch policies during device shutdown
Source:
ZENworks; Patch Management.
Explanation:
After assigning the Patch Policies on Shutdown schedule to a Windows 1903 device, during the device shutdown, a blank PowerShell window is displayed. Though the patches have installed correctly on the device, the Powershell window does not display any messages.
Action:
None. Ignore the blank PowerShell window.
Unable to uninstall patches
Source:
ZENworks; Patch Management.
Explanation:
Patches that support uninstall cannot be removed from a device by clicking the Patched count within the Patches page in ZCC.
Action:
In the Devices page of the patch object, select the device on which you want to uninstall the patch and then click . In the wizard, select the option and configure the deployment with the uninstall action. For more information on the uninstall action see Remediation Options.
The patch policy might not rebuild and fails to create a sandbox or published version
Source:
ZENworks 2020
Explanation:
While creating a patch policy, the policy might not rebuild. Hence, it fails to create a sandbox or published version, and in the services-messages.log, the following message is displayed:
ERROR: duplicate key value violates unique constraint "zpatchpolicysignaturemap_pkey"
Possible Cause:
This error might be displayed due to the newly added sequences in the database.
Action:
Perform the following steps to correct the sequences in the database:
-
Download the latest version of the Database Migration tool.
-
Unzip the Database Migration tool, and then copy the db-migration-utility.jar file to the following location:
-
After copying the file, run the following configure action:
novell-zenworks-configure -c FixSequencesConfigureAction
Patch Policy assignment: Bundle stays in ‘Pending’ state forever
Source:
ZENworks; Patch Management.
Possible Cause:
There are issues between bundles and older agents
Action:
Bundle Assignment having State as "Not Effective" has a reason associated like "System requirement failed", "Unsociable Type", "Blocked", "Wrong Platform" etc. Similarly we have to define a new State like "Not Effective because Older Agent" and then update the existing logic to set that State while filtering the assignments.
Adding / defining new State for Bundle Assignment has more impact as other components on server might be using the value of Effective State for other computations.
Remediation cannot be deployed
error is displayed when remediating vulnerable devices from security dashboard
Explanation:
When a patch is superseded and the managed device has not yet uploaded the status for the new patch, during this interval if you try to remediate the device, an error is displayed and inconsistency is seen in security dashlets. (Example, CVE Severity Distribution, Top CVEs, etc.)
Action:
Wait for the patch status to update.