A.1 Patch Management Issues

Patches are unavailable because of the CDN switch to Akamai for ZENworks Patch Management

Source: ZENworks 11 SP4; Patch Management.

Explanation: In the week of 18 February 2008, the hosting infrastructure for the patch content Web site used by ZENworks 11 SP4 Patch Management was migrated to Akamai as the new host provider. This switch was done through a global DNS change.

Action: Follow the steps below:

Open access to the following Web sites:
- novell.cdn.lumension.com
- novell.cdn.heatsoftware.com
- cdn.lumension.com.edgesuite.net
- cache.lumension.com
- a1533.g.akamai.net
- go.microsoft.com
- www.download.windowsupdate.com
- www.download.windowsupdate.nsatc.net
- download.windowsupdate.chinacache.net
- download.windowsupdate.com
- download.skype.com
- download.microsoft.com
- cc00022.h.cncssr.chinacache.net
- a26.ms.akamai.net
- wsus.ds.download.windowsupdate.com
- a767.dscd.akamai.net
- fg.ds.dl.windowsupdate.com.nsatc.net
- main-ds.dl.windowsupdate.com.nsatc.net
- ds.download.windowsupdate.com.edgesuite.net
- xmlrpc.rhn.redhat.com
- a248.e.akamai.net
- cache.patchlinksecure.net
- rhn.redhat.com
- www.redhat.com
- wildcard.redhat.com.edgekey.net
- wildcard.redhat.com.edgekey.net.globalredir.akadns.net
- linux-update.oracle.com
- itrc.hp.com
- ftp.itrc.hp.com
- mirror.centos.org
- vault.centos.org
- https://getupdates.oracle.com
- e4579.c.akamaiedge.net
- nu.novell.com
- ardownload.adobe.com
- armdl.adobe.com
- download.adobe.com
- swupdl.adobe.com
- www.adobe.com
- http://ftp.mozilla.org
- http://support1.uvnc.com
- http://downloads.sourceforge.net
- http://download.viedolan.org
NOTE:Adding hosts on ZENworks server, please use "nslookup" on command to get the IP address for each URLs.
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: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 Web site, 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.
  
  The license server is still using the same address as in ZENworks Patch Management 6.4. If you want to enter a serial number to register your Patch Management usage, you need to leave the IP addresses of our old servers in your firewall rules.
  
  NOTE:The server needs to use a proxy to get to the outside world, and the browser isn't configured for the same proxy, then the test in the mentioned would fail.
- Firewall information for ZENworks 11 SP4:
  
  ZENworks Patch Management license replication goes to the following servers:
  
  206.16.247.1
  
  206.16.45.33
  
  206.16.45.34
  
  Port 443
  
  ZENworks 11 SP4 Patch Management content replication goes to the following DNS name:
```
http://novell.cdn.lumension.com/novell
```
  To find out what IP your specific server is using, ping novell.cdn.lumension.com from several machines and enter the applicable address range into your firewall rules.

No patches are shown in the Patches tab

Source: ZENworks 11 SP4; 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.

No vendors are shown are shown in the Select vendors to use in the system options

Source: ZENworks 11 SP4; 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.

Patches do not seem to be deployed on the target device

Source: ZENworks 11 SP4; Patch Management.

Possible Cause: The ZENworks administrator hasn’t 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 hasn’t been triggered in the ZENworks adaptive agent.

Actions: Check to see if the Device Refresh Schedule option is set as Manual Refresh or Timed Refresh on the Configuration tab, and wait for the specified interval.

The Cancel button disappears in the Reboot Required dialog box

Source: ZENworks 11 SP4; 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 11 SP4; 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 11 SP4:

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 11 SP4; 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.

Microsoft System Installer (MSI) might need to be updated for some patches

Source: ZENworks 11 SP4; Patch Management.

Explanation: Deployment of certain .NET patches might require that the latest MSI is installed. Otherwise, you might receive errors when deploying those patches.

Action: Prior to deploying .NET patches, verify whether an MSI version is a prerequisite. If necessary, create a bundle to deploy the latest MSI (version 3.1 or later) to your systems. MSIs are available from Microsoft.

Remediation of Linux patches displays an error on the SLES 11 SP1 agent

Source: ZENworks 11 SP4; Patch Management

Explanation: On a SUSE Linux Enterprise Server (SLES) 11 SP1 x86, when you apply some patches, though they get applied successfully, an error is reported in the bundle system.

Possible Cause: This is a reporting error, related to patches that have java dependencies.

Action: In the jexec script installed by the sun/oracle java rpm in the /etc/init.d folder, after the # Required-Start: $local_fs line, add the following line: # Required-Stop.

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

Source: ZENworks 11 SP4; 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 11 SP4; 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 11 SP4; Patch Management.

Possible Cause: “Patch bundles assigned through patch policies don't 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 11 SP4; Patch Management.

Possible Cause: RPM Application Bundle and Custom RPM Bundle fails on both SUSE as well as Redhat 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 11 SP4; 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 Novell Support.