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

      • 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

      • 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

    • Akamai

      • akamai.net

      • akamaiedge.net

        NOTE:The akamai.net and akamaiedge.net URLs can change for each connection depending on the user’s geographic location, across the world. Hence, you need to set up the firewall to account for the random URLs associated with these domains.

    • National Vulnerability Database

      • https://nvd.nist.gov

    • Dropbox

      • clientupdates.dropboxstatic.com

    • Lumension

      • cdn.lumension.com.edgesuite.net

      • 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.lumension.com

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

      Pinging a1533.g.akamai.net [12.37.74.25] with 32 bytes of data:                                  Replyfrom 12.37.74.25: bytes=32 time=14ms TTL=55                                       Reply from 12.37.74.25: bytes=32 time=14ms TTL=55                                       Reply from 12.37.74.25: bytes=32 time=14ms TTL=55                                        Reply from 12.37.74.25: bytes=32 time=13ms TTL=55                                          Ping statistics for 12.37.74.25:                 Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),                                             Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 14ms, Average = 13ms

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

      If you receive the following message:

      Ping request could not find host novell.cdn.lumension.com. Please check the name and try again.

      The firewall administrator needs to open access to the Akamai network for both ping and HTTP (TCP port 80) traffic.

      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.lumension.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 Akamai network, but that the HTTP (TCP port 80) is blocked.

      NOTE:The server needs to use a proxy to get to the outside world. If the browser is not configured for the same proxy, the test mentioned above will fail.

No patches are shown in the Patches page

Source: ZENworks 2017; 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 2017 Update 1; 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 2017; 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 2017; 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 2017; 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 more recent 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 2017; 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 2017; 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 2017; 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 2017; 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 2017; 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.