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.

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.

The Novell and Partner URLs for Lumension and Akamai, listed below, must be allowed access in the Firewall policies to enable the Patch Subscription process to download patch content for other vendors such as Microsoft and Adobe.

Action: Follow the steps below:

  1. Open outbound access to the following websites from the ZENworks Patch Management Server:

    • Novell

      • https://nu.novell.com

      • download.novell.com

    • Lumension

      • novell.patchlink.com

      • cache.patchlinksecure.net

      • novell.cdn.heatsoftware.com

    • Windows Content

        • go.microsoft.com

        • www.download.windowsupdate.com

        • go.microsoft.com -- CAB file used for Native Scan.

        • download.windowsupdate.com

        • download.microsoft.com

        • wsus.ds.download.windowsupdate.com

    • Adobe Content

      • ardownload.adobe.com

      • ardownload2.adobe.com

      • armdl.adobe.com

      • download.adobe.com

      • swupdl.adobe.com

      • www.adobe.com

    • Oracle Linux

      • linux-update.oracle.com

    • HP-UX

      • itrc.hp.com

      • ftp.itrc.hp.com

    • Red Hat

      • www.redhat.com

      • rhn.redhat.com

    • Oracle Solaris

      • https://getupdates.oracle.com

    • SUSE 9

      • https://you.novell.com

    • SUSE 12

      • https://scc.suse.com

    • Apple

      • http://updates-http.cdn-apple.com

      • secure-appldnld.apple.com

    • National Vulnerability Database

      • https://nvd.nist.gov

    • Dropbox

      • clientupdates.dropboxstatic.com

    • Lumension

      • cache.lumension.com

    • Skype

      • download.skype.com

    • Mozilla Firefox

      • http://ftp.mozilla.org

    • SourceForge

      • http://downloads.sourceforge.net

    • UVNC

      • http://support1.uvnc.com

    • VideoLAN

      • http://download.videolan.org

    NOTE:While adding hosts on the ZENworks server, either use the nslookup or ping command to get the IP address or secondary DNS names for each URL.

    Patch content is downloaded using the SSL-based (TCP port 80) connection. The network should not block the download of binaries or exe files from these remote URLs as they are provided by partners.

  2. If you have ZENworks Agent clients in the zone that use Microsoft Office 365, configure those clients to receive Office 365 updates natively.

    For information about how Patch Management works with Office 365, see the Cool Solutions article Patching Microsoft Office 365.

  3. Test your connectivity to the new hosting provider from your ZENworks Primary Server that the Patch Management feature is currently running on:

    • Ping test:

      Log in to the server console, and launch a command prompt or shell window:

      ping novell.cdn.heatsoftware.com

      If your server is able to connect to the cloud hosting network without a problem, you see a response similar to the one shown below:

      PING ddnkgb0d00fm8.cloudfront.net (13.35.90.100) 56(84) bytes of data.                                  64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (13.35.90.100): icmp_seq=1 ttl=236 time=30.6 ms
64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (13.35.90.100): icmp_seq=2 ttl=236 time=30.5 ms
64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (13.35.90.100): icmp_seq=3 ttl=236 time=40.8 ms
64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (13.35.90.100): icmp_seq=4 ttl=236 time=30.1 ms
64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (13.35.90.100): icmp_seq=5 ttl=236 time=30.5 ms

      The ping command shows you the address of the nearest server to your current location.

      NOTE:The Ping test is a simple way to establish that a server has a route available to reach the server, it is not used by Patch Management in normal operations.

      Ping (ICMP) may be blocked by your corporate firewall, or the server may need to pass through a proxy to reach the hosting provider: In these circumstances the Ping test will fail, so other tests will be needed.

    • Browser test:

      Using a Web browser, type in the following URL:

      http://novell.cdn.heatsoftware.com/novell/pulsar.xml

      The browser should display formatted output from the website, as shown in the figure below:

      If your browser cannot access the XML file, you experience a browser timeout and receive some kind of error message. If the ping test succeeds and the browser test fails, this indicates that the firewall administrator has limited access to the cloud network or the HTTP (TCP port 80) is blocked.

      NOTE:If the ZPM server needs to use a proxy to get to the outside world, ensure that the browser is configured for the same proxy or the test is not valid.

No patches are shown in the Patches page

Source: ZENworks; Patch Management.
Possible Cause: The server has just been installed.
Action: You need to start the patch subscription download, and then wait twenty minutes or more for patches to be downloaded automatically from novell.patchlink.com.

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.

“Failed but set to continue” error shows in progress bar

Source: ZENworks; Patch Management
Explanation: After an 11.2.4 server and agents are set up and some deployments are made, and then following an upgrade from 11.2.4 to 11.3, this error will be shown in the progress bar. The patches ARE installed, but the system can not ‘see’ this. patchReportResult does not action on older agents.
Possible Cause: Mismatch, new actions from the newer architecture are not recognized in older versions. Functionality is NOT affected.
Action: Disable the action in both the deployment and remediation bundles, and immediately refresh the agents to avoid the error.

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.

Patch Policy assignment: Error Message should be displayed for (failed) assignment to older agents

Source: ZENworks; Patch Management.
Possible Cause: “Patch bundles assigned through patch policies do not flow down to older version agents than 11.3" message should be displayed on assignment of patch to older version agents.
Action: Assignment can be done from the device side as well as from the object (patch policy/bundle) side. So, various checks are required here i.e. whether the device is an older agent and whether the object type is patch policy.Also, since multiple objects can be assigned to multiple devices (including folders and groups), the checks need to be iterative which further increases the complexity.

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 Deploy Remediation. In the wizard, select the Advanced option and configure the deployment with the uninstall action. For more information on the uninstall action see Advanced 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:

  1. Download the latest version of the Database Migration tool.

  2. Unzip the Database Migration tool, and then copy the db-migration-utility.jar file to the following location:

    • On Linux: /opt/novell/zenworks/java/lib/

    • On Windows: %ZENworks_HOME%\lib\java\common

  3. After copying the file, run the following configure action:

    novell-zenworks-configure -c FixSequencesConfigureAction

Remediation cannot be deployed error is displayed when remediating vulnerable devices from security dashboard

Explanation: When a patch is superseded during a patch subscription run, 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 subscription run to complete and patch status to update.