Introduction

The ZENworks System Update can be performed in two ways either from Novell Control Center (NCC) or by importing the system update using the ZMAN command

1. NCC: Register the zone in NCC. After registering, you will be getting notifications on the ZCC System Update page, whenever a new build is available. Using this notification, you can download the content.
2. ZMAN: Download the build in one of the Primary Server. Open the terminal where you have saved the build, and then run the "ZMAN SUI <build_name>.

After importing the content into ZCC, the remaining steps are the same for both NCC and ZMAN.

System Update Workflow

Workflow Process

Evaluation of Pre-requisites

After the Golbal_PRE_REQS command is executed, the prerequisite framework evaluates all the zone-wide prerequisites applicable for the update. Prerequisites can be categorized as mandatory and optional. All mandatory prerequisites must be met for an update to continue. In case one or more prerequisites are not met, then the update will move to an ERROR state. Click on the "ERROR" link to view the failed prerequisites in a tabular form. If only optional prerequisites are not met, then the super administrator will be provided the choice to either fix the errors or acknowledge and continue with the update. Even if one of the mandatory prerequisites fails, then the update will not continue until those prerequisites are met.

Refer to the following screenshots for more information:

Preparing the Update

                                    

>  Creation of Update XML: The update XML for INSTALL and PRE-INSTALL commands are also constructed as part of the preparation activity. These files can be found in the prepare folder under the ZeUS work folder:

On Linux: /var/opt/novel/zenworks/ZeUS/work 

On Windows: %ZENWORKS_HOME%/ZeUS/work

> Creation of UpdateInfo XML: The generated updateInfo.xml contains information about the update, it's identifiers, the list of updates it requires and/or supersedes, and whether it is a role-based update or not. This XML file will be inside the "prepare" folder under ZeUS "work" folder. After all the above steps are completed, the update is added to the list of prepared updates list, maintained in the "updates-prepared" file that is available in the following locations:

On Linux: "/var/opt/novell/zenworks/work/system-update"

On Windows: %ZENWORKS_HOME%/work/system-update

 

                                    

2. This queue action performs the Preparing activities on the servers. After the preparation is completed on all the servers, additionally, a monitor thread is started that will move the update status to "PREPARED".

The "PREPARING" state is a link which allows you to monitor the status of all the servers. This dialog also allows you to ignore any unreachable server in the zone. 

Monitoring Thread and Ignoring servers
The Monitor Thread runs in the loader context and logging will be seen in loader-messages.log.

                                     

 

Every step performed during the preparation stage will be logged in to prepare-update.log in the logs folder.

Prepare-update log: The start and end of the System Update Preparation phase are tracked in Prepare-update.log.

Screenshot 1

                                   

                                

                         Screenshot 2

                                   

                        

Re-trigger Preparation Update

You can also re-trigger the preparation of the update by using the "Retry Prepare Update" action. When you retry the prepare update, if all the zone-wide prerequisites were met, or if only optional prerequisites were failing and the administrator chose to ignore those failures and continue, then, in these scenarios the evaluation of prerequisites will be skipped. Two entries are created in the "zOpaqueData" to keep track of this information.

The keys for the same are as follows:

• com.microfocus.zenworks.pre.requisite.status – This entry will be set to "PASS" if all prerequisites were met.
• skip.optional.prerequistes - This entry will be created when an administrator ignores the failing optional prerequisites and continue with the update.
  

Schema Changes

There are several stages involved in the preparation of an update. These stages should be tracked to know the progress of the update. To track the update, a new table is introduced, which keeps track of the update preparation progress on each of the Primary Servers. This information is persisted in a new table named zSystemUpdatePrepareStage.             

 

 

 

All the column names are self-explanatory except the SUID column, which is nothing but the updateUID. For a given update, this table will have one entry for each of the Primary Servers in the zone. An entry is created as soon as the preparation process starts. As already mentioned, an option is provided to ignore a server from preparation. This will be updated in this table and marked with the help of prepIgnored column. The "status" column is an interesting one. it is a bitmask that encapsulates the progress of all stages involved in the preparation process.

This table is of vital importance to track the progress of the preparation of an update. We have a monitor thread that keeps monitoring the progress on all the Primary Servers and when preparation is successful, it will move the update to the Prepared state. If a server is ignored from preparation, the prepIgnored flag is set and those servers will not be monitored.

Authorization Stage

After successful completion of the prerequisites check and preparing process on all the Primary Servers, the update is Prepared and ready for the Administrator’s authorization, which is the Awaiting Authorization stage.

Configure Update Stage

After the system update is Prepared and Authorized, the Configure Update option will be shown only if the update requires inputs. If the inputs are required, the Configure Update web console is opened in a new tab, with the single sign-on, where you will be prompt for the inputs. After the inputs are provided, the data is saved into the "zSystemUpdateConfiguration" table and each page-wise inputs will be saved to the "zSystemUpdatePageInputs" table. Inputs, which are gathered, can be changed until the update is deployed to one of the devices.

Ready to Deploy Update Stage

After the system update is Prepared, Authorized, and Configured, it can now be deployed to all the devices in the zone. The update can be deployed to a stage or manually selected set of devices. As soon as we deploy the update, a "stop services" Quick Task is created to stop services on all the servers and after successfully stopping the services, a Remote Method Invocation asking ZeUS to launch the preglobal jar. So, the point to note here is that going forward, ZeUS will launch the preglobal jar. Once pre-global actions are successfully executed, ZeUS will update the "globalActionsRun" flag in zSystemUpdateEx and proceed with the launch of configuration action "PreGlobalAdvanceNextStage" to advance to the next stage if an update is assigned to a Stage and is not set to postpone staging. Once this stage is completed, ZeUS will be refresh and it will launch ZENUpdater to perform the package update. Before you click Finish in the Deploy update wizard, a pop-up window will be displayed. In the pop-up window, a link will be displayed, where you can track the system update progress. The link will be similar to https://ServerFQDN:7444//systemupdate/sustatus. The FQDN in the URL can be replaced with the server IP/name where the update is in progress, and the status web app can be launched.

Introducing the Stop Services Quick Task

When an update is deployed to a set of devices, a "stop services" quick task is created for all the servers, except the server on which the preglobal actions are executed. ZeUS will process this quick task, which goes ahead and stops the loader, server, and monitor services on the Primary Server.

On the server in which the preglobal actions are running, ZeUS stops the services without creating a quick task. On successfully stopping services, the preglobal action jar is launched.

If for some reason, stopping of services fails on one or more servers, the update moves to the "ERROR" state. Clicking on the Error link displays the list of servers on which the task failed. The Administrators can then either go ahead and manually stop the services or redeploy the update.

Following is a sample screenshot of the dialog that lists the servers on which stop services Quick Task had failed.

After successfully deploying the System Update to the device, the status will be changed to Scheduled.

Tracking of System Update Status

Since the System Update Loader and Monitor services are down, we will not be able to launch the ZCC to track the System Update Status. However, we have the Status Webapp option from which we can tack the System Update Status, https://ServerFQDN:7444//systemupdate/sustatus. In this URL, replace the “ServerFQDN” with the device IP on which the System Update was initiated, and open the link in a browser.

Following are the images that display the system update statuses:

Status of Updating the Schema

Status of Updating the Package

We can also track the System Update Status by logging into the deployed device by clicking the ZENworks icon in the taskbar.

After completing 100 % installation of System Update, a prompt is displayed to restart the device.

Launch ZCC after the services are running. In ZCC, go to the System Update page, check the status, and deployed the build version on the configuration page.

For more information, see the following two images:

Screenshot 1

Screenshot 2

Deployed Build Version might take some time to reflect the data.