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
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.
Open outbound access to the following websites from the ZENworks Patch Management Server:
go.microsoft.com -- CAB file used for Native Scan.
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
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.
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.
Test your connectivity to the new hosting provider from your ZENworks Primary Server that the Patch Management feature is currently running on:
Log in to the server console, and launch a command prompt or shell window:
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 [22.214.171.124] with 32 bytes of data: Replyfrom 126.96.36.199: bytes=32 time=14ms TTL=55 Reply from 188.8.131.52: bytes=32 time=14ms TTL=55 Reply from 184.108.40.206: bytes=32 time=14ms TTL=55 Reply from 220.127.116.11: bytes=32 time=13ms TTL=55 Ping statistics for 18.104.22.168: 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.
Using a Web browser, type in the following URL:
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
Patch remediation bundles are not replicating to Primary servers
Patches do not seem to be deployed on the target device
The Cancel button disappears in the Reboot Required dialog box
Superseded patches are shown as NOT APPLICABLE
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.
Patch deployment might not start when scheduled
“Failed but set to continue” error shows in progress bar
Patch Policy assignment: Bundle stays in ‘Pending’ state forever
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
Linux - Custom Patches: Bundles fail to launch
Airgap Server: User receives trial license email after adding the license info to system variables