Deployment stages are optional. However, if a failure occurs during the update process, the process is halted. Stages allow you to deploy an update in stages, such as to a test group first, then to your managed devices. E‑mail notifications can let you know when each stage has completed.
You can do the following with stages:
Set it up for different devices or groups, such as for a test group, specific devices or device groups, or all managed devices in the zone.
Modify an existing stage’s membership.
Change the order in which the stages run.
Rename and delete stages.
Specify the default timeout for a stage. If that time is reached, the update process quits and a message is sent that it failed on that stage.
Specify the reboot behavior when devices complete the update: prompt a reboot, force a reboot, or suppress rebooting.
Sort the stage information by using any of its panel’s columns.
Specify how the update process is to advance through the stages:
Automatically, with or without notification
One stage at a time with notification when each stage is completed
Bypass the configured stages and immediately apply the update to all devices
Following are some of the reasons for creating deployment stages:
Testing the system update on certain devices before deploying it to your production environment
Grouping your Primary Servers:
You can include all servers in one stage so they can be updated at the same time.
or
You can group your servers in several stages so that the update process isn’t too intensive for the Primary Server being used to perform the updates.
You can group the workstations in several stages so that the update process isn’t too intensive for the Primary Server being used to perform the updates.
Any managed devices that are not a member of a stage are automatically updated after the last deployment stage has been processed.
You cannot configure stages when they are currently in use.
The following table explains the column information. For some columns, you can sort the listed information by clicking a column heading. Click it again to reverse the sorting order.
Column Heading |
Explanation |
---|---|
|
Displays the order in which the stages are run. You can rearrange the staging order by using the and options.The first stage listed always displays ordinal 1, the second, ordinal 2, and so on. Therefore, you do not need to include a sequence number in your stage names. |
|
Name of the stage, which you specify when creating the stage by using the > option.Make this name descriptive enough to indicate its purpose. |
|
This column contains the option, which opens the Modify Stage Members dialog box that lists all of the members of the stage.Stage membership can include individual devices and groups that contain devices. |
|
Displays the current behavior for each stage, which you can change by using the > option. |
Reboot Behavior |
Displays the reboot behavior of devices after the update is deployed. Some updates do not require a device to be rebooted after they have been deployed to a device. However, if a reboot is required to complete the update process, the deployment is not completed until the device is rebooted. The following explains how each option works:
|
|
Displays the stage timeout, listed in minutes, which you can change using the Stage Timeout Settings. Changing the value here only changes it for the selected deployment stage. > option. The default is 3 days, 3 hours, and 3 minutes, which is the global timeout value that can be changed inWhen this time value is reached, the stage’s deployment terminates and the next stage starts. If the time is not long enough, the deployment might not be completed to all of the devices that are members of the stage. |
To configure deployment stages, perform the tasks in the following table:
Task |
Steps |
Additional Details |
---|---|---|
Creating a deployment stage |
|
A newly created stage does not have any members. You must modify the stage’s membership to add them. Use the stage names to help you to understand the stage’s purpose. You cannot add a stage while a deployment is in process. |
Modifying a stage’s membership |
|
These are the devices that will be updated when the stage starts. You can add individual devices or device groups, or any combination of them. Keep in mind that you can have both servers and workstations in the same deployment stage, or in different stages, or that you can split your servers and workstations into multiple deployment stages for each type. IMPORTANT:You should update your Primary Servers before updating your managed workstations. |
Modifying the deployment stage timeout |
|
If you specify a timeout value for this stage, set its value to be long enough to accommodate updating all of the devices in the stage. If you don’t allow enough time, some devices might not be updated. If the timeout value is reached before the stage completes, the deployment process is terminated and an error message is sent to the administrator. |
Bypassing staging |
To bypass a stage, see the steps in the Deploying System Updates panel help. |
This bypasses the use of stages for the next system update that you deploy. |
Modifying a stage’s behavior |
|
The default stage behavior is to advance through the configured stages automatically. You can configure stage behavior for individual stages or for all stages.
|
Modifying the deployment reboot behavior |
|
Some updates do not require a device to be rebooted after they have been deployed to a device. However, if a reboot is required to complete the update process, the deployment is not completed until the device is rebooted. The following explains how each option works:
|
Modifying the order in which stages start |
|
All updates that use stages deploy to the devices that are members of the stages in the currently listed order. |
Renaming a deployment stage |
|
Stage names can help you to understand the stage’s purpose. |
Deleting a deployment stage |
|
Deleted stages cannot be recovered. |
For trademark and copyright information, see Legal Notices.