Upgrading secondary servers

After you upgrade platform components on the primary server in a server group Open link , you can choose to upgrade the platform components on the secondary servers sequentially (one at a time to leverage failover), or in parallel (at the same time during an outage window). When you upgrade secondary servers in parallel, the overall upgrade time is further reduced.

During a secondary server upgrade, the component's application files are upgraded without interacting with the database; therefore, a secondary server upgrade is faster compared to a primary server upgrade. (The database is upgraded with the primary AR System server. All of your secondary AR System servers connect to this database.)

When you upgrade secondary servers, the Server Group option is not displayed because the installer automatically detects that the server is a part of a server group based on the database details provided during installation.

On the Installation Summary panel for the AR Server, the type of upgrade is displayed. For example, upgrade on secondary server.

In this topic

Preparing for zero-downtime upgrade of the platform

Before you begin

The primary server must be upgraded, running, and ranked to perform the administrative operations. No other secondary servers should be ranked for administrative operations; otherwise, the operations that are normally owned by the primary server might fail over to one of the secondary servers.

For a secondary server upgrade with an outage, you should have followed the steps in Preparing the AR System server for a server group upgrade prior to upgrading the primary server.
From 9.1.04 onward, you should upgrade the platform components by using the zero-downtime upgrade method. For a secondary server upgrade without an outage (zero downtime), you should have followed the steps in Preparing for zero-downtime upgrade of the platform.

To upgrade secondary servers (staged or in-place)

(For a staged upgrade) If you did not set up staging secondary servers, point your existing secondary servers to the new production database or staging server database, depending on the environment you are upgrading.

For instructions on how to set the Db-Host-Name, see Centralized Configuration settings C-D or ar.cfg or ar.conf options C-D .
Perform the upgrade on the secondary servers in parallel or sequentially.
- For an in-place upgrade with zero downtime, you must upgrade the secondary servers sequentially to provide failover.
- For a parallel upgrade, if you do not want to upgrade all of the secondary servers together, manually shut down those secondary servers before you proceed with the upgrade so failover to those systems does not occur.
The installer will automatically shut down a secondary server for upgrade. For instructions on how to upgrade a component, see either Upgrading the platform or Upgrading the applications.

To verify the server group upgrade status

If you are upgrading the Remedy platform components in a server group, the installer triggers the post installation tasks after successfully upgrading all the secondary servers. However, no message is displayed indicating all the secondary servers are upgraded or the post install tasks are triggered.

To view the upgrade status of a server group, go to AR System Administration > Server Information form, Platform tab. The Server Group Upgrade Status field displays the status Done if all the servers of a server group are upgraded successfully.
To verify if the post upgrade activities are triggered, check the arerror.log located at <InstallDirectory>\BMC Software\ARSystem\Arserver\Db.

To complete an in-place, zero downtime upgrade of the platform after upgrading secondary servers

If you are performing and in-place, zero-downtime upgrade, complete the following activities after you upgrade all secondary platform servers sequentially.

Sync the BMC Remedy Mid Tier cache.
If your existing version of BMC Remedy ITSM applications is below version 9.0, apply the
Error rendering macro 'link-window'
Failed to transform the HTML macro template for display. Nested message: The XML content could not be parsed. There is a problem at line 4, column 23. Parser message: Unexpected character '9' (code 57) (expected a name start character) at [row,col {unknown-source}]: [4,23]
.

For a secondary server you need to deploy jar/dll only, there is no need to import definition files.

Where to go from here

Next task

After you complete the upgrade, you can add and modify the entries in the BMC Remedy AR System Server Group Ranking form. See Setting failover rankings for servers and operations Open link .

Up to process

When you have finished upgrading the secondary servers, return to the appropriate upgrade process: