When you upgrade the Application Server, the system moves the existing files to a backup directory and installs the new files in the current directory. This allows you to uninstall the upgrade if you need to.

Note: A fresh installation of the Application Server erases the database that holds the Media Server configuration information; however, upgrading the Application Server does not erase the database.

4. During the upgrade, the system copies all of the notification templates for SMTP and the Microsoft Outlook front-end deployment to a backup directory under /opt/cisco/meetingplace/var.<version> /mail/res/email_templates. It also backs up the back-end notification templates and copies them to the same directory.

Related Topics

Verifying Available Disk Space Before Upgrading the Application Server

The upgrade installer automatically removes files and folders that are safe to remove during the upgrade. At the end of the pre-installation, the summary page will display how much space is required on the /opt folder for the upgrade.

Before You Begin

The size of the upgrade bin file is indicated on the Cisco Software Download page.

Note: The upgrade file requires at least 100 MB of free space in the / and /tmp partitions, and 2.5 GB in the /opt partition.

Procedure

Open an SSH to the Application Server.

Enter su- to switch to the root login.

Use the CLI command df –h to list the used and free space for all disk partitions.

Confirm that the free space available for each meets the requirements before proceeding. If they do not meet the requirements, delete files and folders to make the free space available.

WARNING! Do not try to remove or rename any files under /opt/cisco/meetingplace. If you still do not have enough free disk space after completing this procedure and removing unnecessary files, contact Cisco TAC to find out what can be removed.

Enter screen -S mp_upgrade to create and attach to a screen named mp_upgrade.

Note: If the SSH remote session disconnects while you are upgrading the Application Server, follow these steps to reattach to the installation screen and continue the upgrade:

Using an SSH client, log in as the user called mpxadmin.

Enter screen -ls to find out the full name of the screen created in Step 5. The full name of the screen consists of an identifier followed by a dot and then the name that you used in Step 5. For example, the full screen name might be 1665.mp_upgrade.

Enter screen -rD <full_screen_name> to reattach to the installation screen.

Change to the root user by entering su - and enter the root password.

From the CLI, navigate to the directory where you saved the upgrade file. Use the command md5sum <filename> to compute the MD5 checksum of the uploaded file to confirm integrity of the upgrade file.

Before You Begin

You have the Release 7.0 or Release 7.1 FCS software available in case you need to restore your data.

Note the following nomenclature:

Node 1 is the original active Application Server.

Node 2 is the original standby Application Server.

Note: Do not leave a standby server out of production for an extended period of time. Doing so may cause the primary server to fail. If you must bring the standby server down for days or weeks at a time, disable replication before you do so.

Step 1: Prepare Node 1 for Upgrade

Procedure

Log in to the CLI of Node 1. If you are logging in remotely, use the hostname (FQDN).

Enter su- to switch to the root login.

Enter mp_replication status on Node 1 to ensure that all database changes have been synchronized.

The system displays the queue column as zeroes.

Enter mp_replication switchOFF -r <Node 2 eth0:0-hostname> where <Node 2 eth0:0-hostname> is the eth0:0 FQDN for Node 2. This switches off replication between the two Application Servers.

Enter mp_replication teardown -r <Node 2 eth0:0-hostname> where <Node 2 eth0:0-hostname> is the eth0:0 FQDN for Node 2. This tears down the replication setup with the remote Application Server.

Enter failoverUtil setDeployment singleServer to change the mode of Node 1 to SingleServer.

Note: This backup/archive set is taken when the primary server is a Single Server/Standalone configuration, and can only be restored to the same server when it is in a Single Server configuration. The backup/archive cannot be used to restore to the same server when it is configured as Failover node.

Procedure

Log in to the Administration Center.

Click Maintenance > Backup and Archive.

Set up the archiving method if your system is not already set up.

Select SSH/rsync as your archiving method.

Set Pathname location of archive to the directory on the remote server.

Set Remote archive host to the hostname (FQDN) of the remote server.

Set Remote host username and Remote host password.

Set Notification email to a valid email address.

From an SSH session on the existing Application Server, make sure that you can successfully SCP a dummy file using the server/username/password path parameters you set up in this procedure.

Click Save and Run Backup.

A backup of the database is created in /db/backup/compressed_backup on the existing Application Server.

Return to the Administration Center page and click Save and Run Archiving.

The backup files and other important files are copied to the remote server.

Complete a selective check to verify that the backup and files were copied over.

Navigate to the directory where you installed the Application Server upgrade files and upgrade Node 1.

Reboot Node 1.

Enter failoverUtil setDeployment failover to change the mode of Node 1 to failover.

Note: This disables the eth0 interface of Node 1, so that Node 2 can become active.

Note: This backup/archive set is taken when the secondary server is in a Single Server/Standalone configuration, and can only be restored to the same server when it is in a Single Server configuration. The backup/archive cannot be used to restore to the same server when it is configured as Failover node.

Procedure

Log in to the Administration Center.

Click Maintenance > Backup and Archive.

Set up the archiving method if your system is not already set up.

Select SSH/rsync as your archiving method.

Set Pathname location of archive to the directory on the remote server.

Make sure that the pathname is distinct from the one you used for storing archives in Node 1.

Set Remote archive host to the hostname (FQDN) of the remote server.

Set Remote host username and Remote host password.

Set Notification email to a valid email address.

From an SSH session on the existing Application Server, make sure that you can successfully SCP a dummy file using the server/username/path parameters you set up in this procedure.

Click Save and Run Backup.

A backup of the database is created in /db/backup/compressed_backup on the existing Application Server.

Return to the Administration Center page and click Save and Run Archiving.

The backup files and other important files are copied to the remote server.

Complete a selective check to verify that the backup and files were copied over.

Navigate to the directory where you installed the Release 7.1 Application Server upgrade files and upgrade Node 2.

Reboot Node 2.

Enter failoverUtil setDeployment failover to change the mode of Node 2 to failover.

At this point, both Application Servers are in standby mode.

Enter the following command to initialize database replication on Node 2:

Upgrading Application Servers that are Used in a Directory Service Deployment for RSNA

Tip: This task is documented as three separate steps. We recommend that you review each step before attempting the configuration.

Restriction

During the upgrade process, do not make any user or group configuration changes on any of the Application Servers. If you make configuration changes on one Application Server, they will not be ported to the other Application Server, because you turned off database replication. If any changes are made, initial setup procedures may have to be followed to synchronize the data between the two Application Servers, depending on the type of changes made on the two servers.

Before You Begin

Note the following nomenclature:

Node 1 is the server that is in site 1.

Node 2 is the server that is in site 2.

Step 1: Upgrade Node 1 in a Directory Service Deployment

Before You Begin

Make sure you have already downloaded the Release 7.1 Application Server upgrade files.

Database replication is not active during the upgrade so if any User/Group configuration changes are made on either server, they will not propagate to the other server. To see how many Users and Groups are present in a server, run the dbsize command as root. If there is a difference and configuration changes were only made on one server, synchronize the differences by using the following command on Node 1:

mp_replication switchON -S -F<hostname to sync from>

Depending on the number of Users/Groups and the network bandwidth between the two servers, the sync may take several hours.

Note: If configuration changes for users or groups were made on both servers, automatic sync may not be possible. In such a scenario, the options are as follows:

Restore the servers from the backups that were taken just before tearing down replication. Setup replication again.

Clear the data of one server and follow the initial instructions of adding an empty server to an existing server in a directory services setup.

Note: Since you are restoring from the latest backup, you will lose any data added after you upgraded your system to Release 7.1.

Problem: The system displayed a message stating that it does not have enough disk space to install the upgrade.

Possible Cause: This may be caused by having too many earlier releases on the server.

Solution: Ensure that you have enough disk space on your system to install an upgrade. Previous releases on the system take up disk space. If the previous releases are not needed, delete them by using the mpx_cleanup command in the Command Line Interface (CLI). See the following process.

Restrictions: This command removes the previous releases that you select. However, it will not remove the first or last release on the system. Therefore, you must have at least three releases of Cisco Unified MeetingPlace installed on your system to successfully run this command.