Environment
Novell ZENworks Configuration Management 11.2.3
Novell ZENworks Endpoint Security Management 11.2.3
Novell ZENworks Patch Management 11.2.3
Novell ZENworks Asset Management 11.2.3
Novell ZENworks Endpoint Security Management 11.2.3
Novell ZENworks Patch Management 11.2.3
Novell ZENworks Asset Management 11.2.3
Situation
Some but not all Primary Servers are updated to 11.2.3a/11.2.4
If a Primary Server not yet updated to 11.2.3a/11.2.4 calculated the location changes at last, a 11.2.3a/11.2.4 server fails to provide location information
In such a case the zenworks-location URL of such 11.2.3a/11.2.4 servers get marked as bad by the managed devices:
Error messages in services-messages.log of related 11.2.3a/11.2.4 Primary Servers:
"...
[DEBUG] [3/26/13 1:40:24 PM] [] [LocationConfig] [31] [] [java.lang.ClassCastException: java.lang.String cannot be cast to com.novell.zenworks.webservice.location.schema.LocationAny
at com.novell.zenworks.webservice.location.schema.LocationMarshaler.deserialize(LocationMarshaler.java:134)
..."
If a Primary Server not yet updated to 11.2.3a/11.2.4 calculated the location changes at last, a 11.2.3a/11.2.4 server fails to provide location information
In such a case the zenworks-location URL of such 11.2.3a/11.2.4 servers get marked as bad by the managed devices:
Error messages in services-messages.log of related 11.2.3a/11.2.4 Primary Servers:
"...
[DEBUG] [3/26/13 1:40:24 PM] [] [LocationConfig] [31] [] [java.lang.ClassCastException: java.lang.String cannot be cast to com.novell.zenworks.webservice.location.schema.LocationAny
at com.novell.zenworks.webservice.location.schema.LocationMarshaler.deserialize(LocationMarshaler.java:134)
..."
Resolution
This is expected behavior: all primaries should be upgraded as soon as possible, in one session
Workaround:
a) Ensure that managed devices can fail over to a server which can still provide location information
1. There needs to be at least one Primary Server not yet updated to 11.2.3a/11.2.4 for the configuration role server list for all the managed devices. More information on setting-up the configuration role is available in the online documentation e.g. at Adding Closest Servers to Locations
2. New devices need to be registered against a server not yet updated to 11.2.3a/11.2.4
or
b) Ensure that all devices can contact the first Primary Server being updated to 11.2.3a/11,2,4 and keep shutdown the zenloader service on all Primary Servers not yet updated. This way location information can only get calculated by servers already on 11.2.3a/11.2.4 and the devices can still reach at least one Primary Server for required information. It is advised to update all Primary Servers as soon as possible in such a scenario. Please note that all Primary Servers and Satellites should be upgraded to at least 11.2.0 before starting to deploy. Please see the 11.2.3a Readme for more information.
Workaround:
a) Ensure that managed devices can fail over to a server which can still provide location information
1. There needs to be at least one Primary Server not yet updated to 11.2.3a/11.2.4 for the configuration role server list for all the managed devices. More information on setting-up the configuration role is available in the online documentation e.g. at Adding Closest Servers to Locations
2. New devices need to be registered against a server not yet updated to 11.2.3a/11.2.4
or
b) Ensure that all devices can contact the first Primary Server being updated to 11.2.3a/11,2,4 and keep shutdown the zenloader service on all Primary Servers not yet updated. This way location information can only get calculated by servers already on 11.2.3a/11.2.4 and the devices can still reach at least one Primary Server for required information. It is advised to update all Primary Servers as soon as possible in such a scenario. Please note that all Primary Servers and Satellites should be upgraded to at least 11.2.0 before starting to deploy. Please see the 11.2.3a Readme for more information.
Cause
The location web service response entry in the SQL database has
different format with 11.2.3a/11.2.4. These format changes are backward
compatible and Primary Servers with lower 11.2.x versions can still
hand out location information computed by a 11.2.3a/11.2.4 server. But a
11.2.3a/11.2.4 server fails to hand out location information compiled and
stored by an older 11.2.x version Primary Server.
Additional Information
The calculation of the location information can be enforced with
the command
zman lrr -f .
This will create a new ZCM queue action entry to be picked up immediately by any Primary Server.
To verify which server recomputed the location information, run the command
zman ql -t Location.Configuration.Module -R <file path>
and check in the created output for the line with newest date in the LastAccessTime column which does not have the N(ew) value in the Status column. Ideally the status should be S(uccess) and the ProcessingServer column give the information which Primary Server calculated the location information.
In case this is 11.2.x Primary Server not yet updated to 11.2.3a/11.2.4, the issue is occurring.
There is no good way to stop a Primary Server from calculating location information other than to stop the zenloader service.
zman lrr -f .
This will create a new ZCM queue action entry to be picked up immediately by any Primary Server.
To verify which server recomputed the location information, run the command
zman ql -t Location.Configuration.Module -R <file path>
and check in the created output for the line with newest date in the LastAccessTime column which does not have the N(ew) value in the Status column. Ideally the status should be S(uccess) and the ProcessingServer column give the information which Primary Server calculated the location information.
In case this is 11.2.x Primary Server not yet updated to 11.2.3a/11.2.4, the issue is occurring.
There is no good way to stop a Primary Server from calculating location information other than to stop the zenloader service.