A.1 Patch Management Issues

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 the Slack Software

Source: Patch Management, Advanced Patch Feed
Explanation: In the Advanced Patch Feed, when you try to perform the remediation of the Slack Software, the patch content download fails.
Action: Install the patch using Custom Patch. For more information, see Create a Custom Patch.

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:
  • libicu65_1-ledata-65.1-150200.4.5.1.noarch

  • libicu-suse65_1-65.1-150200.4.5.1.x86_64

Action: Run the following command to install the missing RPMs:

rpm -ivh <rpmname>

In the above command, replace “rpmname” with the following RPMs:

  • libicu65_1-ledata-65.1-150200.4.5.1.noarch

  • libicu-suse65_1-65.1-150200.4.5.1.x86_64

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 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 Device Refresh Schedule option is set as Manual Refresh or Timed Refresh 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 Allow User to Cancel option is set as No on the Pre Install Notification Options page and the Notification and Reboot Options page of the server, the Cancel 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 Recurring and Process Immediately If the Device Is Unable to Execute 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: To uninstall a patch, perform the following steps:
  1. Go to Security > Patches.

  2. Select a patch that can be installed.

  3. On the left navigation menu, click View Patch.

  4. Click the Patched tab.

  5. Select a device, and then click Action > Remove.

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.