Upgrading Messaging Server to Messaging Server 7 Update 2

This information describes the three Messaging Server upgrade strategies to upgrade individual hosts within a deployment. This document assumes that you have chosen a target deployment, and have developed an architectural design and deployment plan for your target deployment.

This document focuses on upgrading single hosts and contains the following sections:

Note If you are upgrading from Messaging Server 5.2, refer to Coexistent Upgrades From iPlanet Messaging Server 5.2 for additional information. This article provides good general information for any upgrade.

Overview

Messaging Server can have multiple back-end message stores, multiple webmail servers, front-end MMPs, and MTA relays. Like all upgrades, you simply upgrade host by host. The major steps for upgrading a Messaging Server deployment are as follows:

• Define your upgrade target and the required products and components for that target.
• Design and Plan Your Messaging Server Architecture and Topology.
  Refer to Convergence Deployment Planning and Communications Suite 6 Update 2 Installation Guide for details on deploying Sun Convergence into your current environment. In addition, although you might be satisfied with your current Messaging Server architecture and topology, upgrading can provide the opportunity to redesign your deployment for more optimal performance. Refer to the Communications Suite Deployment Planning Guide for more information.
• Select the sequence of upgrading Individual Messaging Server Hosts.
  This includes upgrading components such as the message store servers, proxies, webmail servers, and front-end relays.
• Choose a Messaging Server Upgrade Strategy for Each Host.
  Three Messaging Server upgrade strategies offer choices that strike a balance between system downtime, cost, simplicity, and risk. You choose a strategy for each host, and you can use different strategies on different hosts within a Messaging Server deployment.

Technical Features Supporting Messaging Server Upgrade

The following features support Messaging Server Upgrade:

• You migrate mailboxes by using the imsbackup and imsrestore commands. See Migrating User Mailboxes to a New System. These commands support moving mailboxes from old message store versions to new ones (including when the message store database format changes, for example, from Messaging Server 32-bit to Messaging Server 64-bit). These commmands also support moving mailboxes from new message store versions to old ones for back out purposes.
• In-place Upgrade supports changing the old mailbox format to the new format, but it does not support going from the new format back to the old. You cannot back out from new data format to old data format by using the In-place Upgrade Strategy. The conversion is done "on-the-fly" as mailboxes are accessed.
• Migrating the Messaging Server configuration from the old system to the new system is done by using the migrate-config utility.
• Alternative Root install is supported. See Performing Multiple Installations with an Alternate Root for more information.
• In-place server upgrade is by done using commpkg upgrade.

Messaging Server Upgrade Strategies

Messaging Server supports the following three upgrade strategies for individual hosts. These strategies provide a balance between downtime, risk of extended downtime, complexity, and potential hardware costs.

• In-place Upgrade. The binaries of the old version are replaced with the binaries of the new version on the same host.
• Side-by-side Upgrade on the same host. The new software version is installed on the same host as the old version in a different directory. After you migrate the software configuration to the new version, you switch the deployment over to the new version.
• Coexistent Upgrade. You keep existing services online while you construct a new host on separate hardware.

The strategy chosen for any particular host might differ. For example, you might wish to use an in-place or side-by-side upgrade on your front-end servers (relays, MMPs, and webmail servers) but you might want to do a coexistent upgrade on your message stores.

Caution There is a data format change in the message store starting with Messaging Server 7. Coexistent Upgrade is recommended to facilitate backout.

The strategy you chose also depends upon the version you currently have installed and whether you are using 32-bit or 64-bit Messaging Server product. Issues and compatibilities are described next.

Table 1. Upgrading to Messaging Server 7 Upgrade 2 32-bit

Table 2. Upgrading to Messaging Server 7 Upgrade 2 Upgrade 64-bit

Using the Coexistence Strategy to Upgrade Messaging Server

The Coexistence Migration Strategy is the safest and most secure method of upgrading. It also has the lowest downtime of the three upgrade strategies. In the coexistence model, existing services remain online while you construct a new target host (or entire Messaging Server environment) on new hardware or in a Solaris whole root zone on the existing hardware. After the new host/environment is established, you can migrate a small number of friendly users to the new system to verify operations and administrative procedures. For a certain period both systems are accessible to user traffic. This is called a coexistence phase. Messaging access is not disrupted and proceeds invisibly to users. When all users are migrated to the new environment, you can decommission your legacy deployment. This phased approach ensures that the new system is fully prepared to handle production users before making the full migration.

Note Read Coexistent Upgrades From iPlanet Messaging Server 5.2 for useful information on coexistent upgrades.

Advantages and Disadvantages of Coexistence Migration:

• Service downtimes are usually rare and short. There is less danger that they will be longer than the off-line windows imposed by service level agreements.
• Allows a gradual adoption of the new software so that you can gain confidence by trying it out with a small group of sympathetic users before migrating production users.
• The risk of upgrade failure is mitigated by the fact that your legacy system remains fully functioning throughout the upgrade process.
• Because the new system is built alongside a functional old one, you do not need to install or modify anything on the working legacy machines. This is an advantage as there is always a natural reluctance to modify or reconfigure a working legacy system in significant ways.
• Coexistence is the safest upgrade model and has the least amount of user downtime.
• Simpler back off procedure. Anytime you upgrade software, you need to make provisions for backing off from the new system to the old system in case of failure. Other upgrade models might require that you back up and turn off the old system, install, configure, and migrate to the new system. Only when you switch on the new system do you know if the upgrade succeeded. If it turns out, that it did not, then you might have to use your back off plan to put everything back into place. A coexistence migration is much simpler as a working legacy system is already in place.
• You must move user data, such mailboxes, from one host to another.
• Might require extra hardware to set up a parallel system. (This can be mitigated by upgrading legacy machines after they are no longer used.)

Specific Steps for Upgrading Messaging Server Using the Coexistence Model

1. Make sure that your hardware is installed as per the deployment plan created from the Convergence Deployment Planning and Communications Suite Deployment Planning Guide. See also the Requirements for Communications Suite 6 Update 2.
2. Install new version of Messaging Server in the proper sequence on new machine, by using the commpkg install command.
3. Configure Messaging Server.
   You must do so manually. Basically you must clone the legacy machine's configuration to this new machine.
4. If you are doing a coexistent migration on a message store, migrate user mailboxes (a few at a time) to the new machine. See Migrating or Moving Mailboxes to a New System. Details on message store internals can be found in Upgrading the Message Store.

Using the Side-by-Side Strategy to Upgrade Messaging Server

In this model, you install the new software version on the same machine as the old version. After migrating the configuration to the new version, you can switch over to the new version. This upgrade strategy is new with Communications Suite 6. The basic steps are as follows:

1. Install Messaging Server 7 Update 2 side-by-side on the same machine with your earlier version of Messaging Server by using the commpkg install command.
2. Back up configuration and mailbox data just in case a back out is required.
   For the configuration data, simply back up the configuration directory. For mailbox data you can do a snapshot or use the imsbackup command.
3. Migrate the configuration from Messaging Server to 7 Update 2 by using the migrate-config utility.
4. Start Messaging Server 7 Update 2.

Advantages and Disadvantages of Side-by-Side Messaging Server Migration

• Second best minimal downtime.
• Second best in backout.
• Does not require extra machines
• Does require different directory location for fresh install. (Do not want to be working the old version.)
• Typically does not involve moving the mailboxes. New version just "points" to the mailboxes and mailbox conversion to the new version is automatic and transparent.
• Backout is problematic because mailbox format changes. Simply stopping the new version and starting the old version will not work.
• The only advantage of side-by-side over in-place is that the binaries of the old version remain intact on the system so you do not have to reinstall and reconfigure in the case of a back out.

Specific Steps for Upgrading Messaging Server Using the Side-by-side Migration Model

1. Back up the message store.
   You can use either the volume snapshot of the file system or perform an imsbackup and imsrestore.
2. Install the new version of Messaging Server on the same system as your previous version of Messaging Server, but in a different directory (for example, in this procedure, /opt/sun/comms/messaging7.0/).
3. To migrate the configuration and message store data from the previous version of Messaging Server, run the migrate-config (migration configuration) utility: /opt/sun/comms/messaging7.0/sbin/migrate-config old-msg-svr-root.
   For example:

   /opt/sun/comms/messaging7.0/sbin/migrate-config /opt/SUNWmsgsr
   

4. Run the following command:

   /opt/sun/comms/messaging7.0/sbin/patch-config
   

5. Run the following command:

   /opt/sun/comms/messaging7.0/sbin/install-newconfig
   

6. To back out the migration, run the following command:

   /opt/sun/comms/messaging7.0/sbin/migrate-config \-u /opt/SUNWmsgsr
   

   where -u is the undo flag.

Next Steps

• Once you complete the migration, stop using the old server-root directory:
  • Update PATH and any scripts referencing the old server-root location.
  • If you are using Legato Networker, be sure to update the server-root location in the configuration.
  • Replace the server-root location with the server-root binary location.

• Start the new server with the following command:
  /opt/sun/comms/messaging64/sbin/start-msg

• If you need to back out the migration, use the ---u (undo) flag:
  /opt/sun/comms/messaging64/sbin/migrate-config ---u old-base-dir (where old-base-dir is the old server-root) directory.

• To restart the old Messaging Server, use: old-base-dir/sbin/start-msg

• Uninstall the old version Of Messaging Server when you are satisfied with the performance of the new one: commpkg uninstall

Backing Out of a Side-by-side Messaging Server Upgrade

Ideally you could just stop the new version and start the old version up and your back out recovery would be complete. However, because there is a mailbox database format change between pre-version 7 and version 7 Messaging Server, this does not work. To back out, you need to restore the message store either by reinstalling the volume snapshot of the file system, or by performing an imsrestore on the backed-up message store.

In either case, there is a potential of losing data as mail comes in during the recovery period. For the most part, back out is considered a disaster recovery operation. Backouts are done immediately after major unacceptable problems are found in the upgrade. Thus volume snapshots are quite acceptable as a back out plan.

The basic procedure is as follows:

• Stop new version.
• Restore mailbox data
• Start old version.

Using the In-Place Upgrade on Messaging Server

In this method you simply replace the old server binaries with the new server binaries on the same machine by using the commpkg upgrade command. This command removes the old packages and installs the new ones. For details about this command, see commpkg upgrade Usage.

Advantages and Disadvantages of In-place Messaging Server Upgrade

• Simplest. One command installs the old packages and removes the new packages. This command migrates and upgrades configuration.
• Requires least amount of extra disk space.
• Messaging Server stays in the same disk location.
• Has the most downtime.
• Back out is complicated. Requires old product version be available. Note that if you do a mailbox data restore, then new messages that arrived since that backup might be lost.
• This method is probably best for evaluators/testers/developers.
• Useful for upgrading Messaging Servers configured without the message store. For example, front-end relays and webmail servers.

Specific Steps for Using In-Place Upgrade on Messaging Server

• Run commpkg upgrade and select Messaging Server.
  • Stops the servers.
  • Removes the old version.
  • Installs the new version.
  • Performs migration of configuration and mailbox data.

For information about using the commpkg upgrade command, see commpkg upgrade Usage. Here is a commpkg upgrade sample session.