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.
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 cloud hosting network without a problem, you see a response similar to the one shown below:
PING ddnkgb0d00fm8.cloudfront.net (126.96.36.199) 56(84) bytes of data. 64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (188.8.131.52): icmp_seq=1 ttl=236 time=30.6 ms 64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (184.108.40.206): icmp_seq=2 ttl=236 time=30.5 ms 64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (220.127.116.11): icmp_seq=3 ttl=236 time=40.8 ms 64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (18.104.22.168): icmp_seq=4 ttl=236 time=30.1 ms 64 bytes from server-13-35-90-100.lax3.r.cloudfront.net (22.214.171.124): 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.
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 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
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 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.
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
Blank PowerShell window is displayed after deploying patch policies during device shutdown
Unable to uninstall patches
The patch policy might not rebuild and fails to create a sandbox or published version
ERROR: duplicate key value violates unique constraint "zpatchpolicysignaturemap_pkey"
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:
On Linux: /opt/novell/zenworks/java/lib/
On Windows: %ZENworks_HOME%\lib\java\common
After copying the file, run the following configure action:
novell-zenworks-configure -c FixSequencesConfigureAction