Upgrading Messaging Server to Messaging Server 7 Update 1

Note: If you are upgrading from Messaging Server 5.2, refer to Coexistent Upgrades From iPlanet Messaging Server 5.2 for additional information. You may want to read this article as it also provides good general information for any upgrade.

This document describes the three Messaging Server upgrade strategies used to upgrade individual hosts within a deployment. This document assumes 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:

Overview

Messaging Server may 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 1 Installation Guide for details on deploying Sun Convergence into your current deployment. In addition, although you may 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 Sun Java Communications Suite 5 Deployment Planning Guide for details.

• Select the sequence of upgrading Individual Messaging Server Hosts. This includes upgrading things like message store servers, proxies, webmail servers, 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. Strategies are chosen for each host, and different strategies can be used on different hosts within a Messaging Server deployment.

Technical Features Supporting Messaging Server Upgrade

The following features support Messaging Server Upgrade:

• Mailbox migration is done using imsbackup/imsrestore. 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 32bit to Messaging Server 64bit). They also support moving mailboxes from new message store versions to old ones for back out purposes.
• In-place Upgrade (see below) 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 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 using the utility [migrate-config
• Alternative Root install is supported. See Performing Multiple Installations with an Alternate Root
• In-place server upgrade is done using commpkg upgrade.

Messaging Server Upgrade Strategies

Messaging Server supports three upgrade strategies for individual hosts that provide a balance between downtime, risk of extended downtime, complexity, and potential hardware costs. The three upgrade strategies are:

• 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 machine as the old version in a different directory. After the software configuration is migrated to the new version, you switch the deployment over to the new version.
• Coexistent Upgrade. Existing services remain online while a new host on separate hardware is constructed.

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

Warning: 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 will also depend upon the version you currently have installed and whether you are using 32 or 64-bit Messaging Server product. The issues and compatibilities are described below.

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

Table 2. Upgrading to Messaging Server 7 Upgrade 1 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 very 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.

• Since the new system is built alongside a functional old one, there is no 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 may require that you backup 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 may 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.

• User data, such mailboxes, must be moved from one host to another.

• May require extra hardware to set up a parallel system. (This may 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 your hardware is installed as per the deployment plan created from the Convergence Deployment Planning and Sun Java Communications Suite 5 Deployment Planning Guide . See also the Requirements for Communications Suite 6 Update 1.

2) Install new version of Messaging Server in the proper sequence on new machine, using commpkg install.

3) Configure the Messaging Server. This must be done 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, the new software version is installed on the same machine as the old version. After the configuration is migrated 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:

• Install Messaging Server 7 Update 1 side-by-side on the same machine with your earlier version of Messaging Server using the commpkg install command.
• 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 an imsbackup.
• Migrate the configuration from Messaging Server to 7 Update 1 using the migrate-config utility.
• Startup Messaging Server 7 Update 1

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

• Second best minimal downtime.
• Second best in backout.
• Doesn't require extra machine
• Does require different directory location for fresh install. (Don't 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 don't 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. Backup the message store. This can be done using volume snapshot of the file system, or doing 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 /opt/sun/comms/messaging7.0/sbin/patch-config.
5. Run /opt/sun/comms/messaging7.0/sbin/install-newconfig.
6. To back out the migration, run /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 their 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 won't work. To back out, you need to restore of the message store. This can be done by reinstalling the volume snapshot of the file system, or doing 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. Back outs 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 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 may 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
  • it 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's is a commpkg upgrade sample session.