This chapter describes the three Messaging Server upgrade strategies and procedures to upgrade from Messaging Server 7.x, 8.0, or 8.0.1, to Messaging Server 8.0.2. It assumes that you have chosen a target deployment, and have developed an architectural design and deployment plan.
Messaging Server 8.0.2 provides a redesigned message store that is based on DataStax Cassandra Database. However, you cannot upgrade to the Cassandra message store. You must perform a migration. To migrate mailboxes from classic message store to Cassandra message store, you must perform a number of steps, including installing message access layer hosts, configuring store affinity groups, installing Cassandra database, rehosting users, and so on. For more information, see Messaging Server Installation and Configuration Guide for Cassandra Message Store.
Note:
You cannot install both classic message store and Cassandra message store in the same Messaging Server deployment.You can upgrade Messaging Server 7.x, 8.0, and 8.0.1 back-end message stores, MTA, MMP, and mshttp components to Messaging Server 8.0.2.
Note:
Prior to this release, once you upgraded to Oracle Communications Messaging Server 7.0.5 or greater, from a version prior to Messaging Server 7.0.5, you could not downgrade by ”backing out” the upgrade. This was because of database incompatibilities with prior versions starting in Messaging Server 7.0.5. This situation does not apply Messaging Server 8.0.2 and Cassandra message store, as you cannot upgrade a Messaging Server 7.x, 8.0, or 8.01 classic message store to 8.0.2 and Cassandra message store; and so, the previous "backing out" scenario no longer applies in that situation.The requirements for upgrading to Messaging Server 8.0.2 are:
You must be running at least Messaging Server 7.x to upgrade to Messaging Server 8.0.2.
You cannot upgrade from Messaging Server 5.x or 6.x directly to Messaging Server 8.0.2. You first must upgrade to Messaging Server 7.x, then upgrade to Messaging Server 8.0.2.
Contact Oracle Consulting to upgrade directly from Messaging Server 5.x or 6.x to Messaging Server 8.0.2.
Linux platforms: Messaging Server supports Oracle Linux/ Red Hat Enterprise. See "Supported Operating Systems" for version information.
Note:
This document uses the side-by-side installation method to be consistent between Solaris and Linux platforms. In general, you should avoid using the alternate root method when upgrading Messaging Server, because Solaris now uses alternative root for its Live Upgrade feature.This Messaging Server upgrade includes the following features, which simplify the side-by-side upgrade method:
Messaging Server package scripts and preupgrade and postupgrade scripts no longer alter the data and configuration in any way. In addition, the upgrade no longer automatically runs the stop-msg command when uninstalling.
For side-by-side migrations, this feature enables you to install two separate Messaging Server versions, such as 7.0.5 and 8.0.2, on the same host, that point to the same data and configuration, and activate a version by running that version's specific start-msg command. The Messaging Server data and configuration are ”upgraded” when the start-msg script invokes the updateCfgVersion script after detecting that a new Messaging Server version is used for the first time.
Note:
When you upgrade from a version of Messaging Server prior to 7.0.5, the restricted.cnf file is not created until you start Messaging Server services after the upgrade. If you attempt to run any Messaging Server commands before starting Messaging Server, you receive an error message that the restricted.cnf file does not exist. Thus, if you want to make configuration changes after upgrading, and before starting Messaging Server services, you must first manually run the updateCfgVersion script.Messaging Server upgrade no longer runs the stored -r command prior to uninstalling the previous version's binaries.
Messaging Server SVR4 style patches are no longer available on Solaris. Instead, you use Automated Release Update (ARU) patches. ARU patches treat each Messaging Server release and subsequent versions as a different package version. For example, Messaging Server 8.0.2 would have a different package version than Messaging Server 8.0.3. Because of this versioning, you can install two copies of the same version of Messaging Server on the same host. Thus, for upgrades, you no longer need to use the alternate root (ALTROOT) install method.
Beginning with Messaging Server 7 Update 5, Messaging Server has the capability to create a Unified Configuration. Unified Configuration provides an improved, streamlined process to configure and administer Messaging Server. Unlike in legacy configurations (Messaging Server 7 Update 4 and prior releases), Unified Configuration uses validation to verify configuration accuracy, and employs a single tool to configure the entire Messaging Server configuration (with a few exceptions). Thus, moving your deployment to Unified Configuration simplifies administration and reduces configuration mistakes.
After upgrading to Messaging Server 7 Update 5 and later, you can decide to migrate your legacy configuration to Unified Configuration. When you convert to Unified Configuration, Messaging Server saves your old legacy configuration in the ConfigRoot/legacy-config directory. If necessary, you can restore a saved legacy configuration at the time you converted, however, all changes made to your configuration after converting to United Configuration are lost. You can migrate to Unified Configuration after you have completed the upgrade. You are not required to migrate to Unified Configuration during the upgrade process.
To help you decide to migrate to Unified Configuration, see Messaging Server System Administrator's Guide for more information about Unified Configuration capabilities and tools.
A Messaging Server deployment can consist of multiple back-end message stores, multiple webmail servers, front-end MMPs, and MTA relays. Like all upgrades, you proceed on a host-by-host basis.
Note:
If you want to use the Cassandra message store in Messaging Server 8.0.2, you must perform a migration of the classic message store to Cassandra messages store. For more information, see Messaging Server Installation and Configuration Guide for Cassandra Message Store.Upgrading a Messaging Server deployment includes the following high-level steps:
Backing up the Messaging Server data
Upgrading and running comm_dssetup.pl to the latest version before upgrading Messaging Server
Messaging Server 8.0.2 requires you to apply at least comm_dssetup.pl version 6.4.0.28.0 against Directory Server. The Messaging Server 8.0.2 media pack includes comm_dssetup.pl version 6.4.0.28.0.
Defining your upgrade target and the required products and components for that target
Reviewing your Messaging Server architecture and topology
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. See "Developing a Messaging Server Architecture" and "Planning a Messaging Server Sizing Strategy" for more information.
Selecting the upgrade sequence of individual Messaging Server hosts
This includes upgrading components such as message store servers, proxies, webmail servers, and front-end relays.
Choosing 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.
Upgrading the Messaging Server software
Use Messaging Server 8.0.2 or the current patch.
(Optional) Migrating to Unified Configuration
Use the configtoxml command to migrate from legacy configuration to Unified Configuration.
For more information, see the discussion on the configtoxml command in Messaging Server System Administrator's Guide.
The following features support Messaging Server upgrade:
You migrate mailboxes by using the imsbackup and imsrestore commands. See the discussion on migrating mailboxes to a new system in the Messaging Server System Administrator's Guide. 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 commands also support moving mailboxes from new message store versions to old ones for back-out purposes.
Note:
You cannot upgrade a classic message store machine (imapd/popd/stored) directly to 8.0.2/Cassandra message store. You must use the rehostuser command to migrate mailboxes from Messaging Server 7.x, 8.0, and 8.0.1 to Messaging Server 8.0.2 and Cassandra message store. For more information, see Messaging Server Installation and Configuration Guide for Cassandra Message Store.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. In-place server upgrade is by done using commpkg upgrade.
Alternate root (ALTROOT) install is supported on Oracle Solaris. For more information, see the discussion on using the ALTROOT command-line argument in "commpkg Reference".
Note:
In general, you should avoid using the alternate root method when upgrading Messaging Server, because Solaris now uses alternate root for its Live Upgrade feature.Messaging Servers 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.
Coexistent Upgrade: You keep existing services online while you construct a new host on separate hardware.
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.
In-place Upgrade: The binaries of the old version are replaced with the binaries of the new version on the same host. That is, you use commpkg upgrade.
The strategy chosen for any particular host might differ. For example, you might want to use an in-place 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 in Messaging Server 8.0.1 (see the discussion on upgrading the Message Store in the Messaging Server System Administrator's Guide). Coexistent upgrade is recommended to facilitate backing out from an upgrade. See also "Downgrading from Messaging Server 8.0.2" for additional information.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.
Note:
When upgrading/migrating between SPARC and x86 hardware, you need to use the Online/Coexistence strategy. For more information, see the discussion on migrating from x86 to SPARC in Messaging Server System Administrator's Guide.Coexistent upgrade is also required when upgrading classic message store machines (imapd/popd/stored for 7.x, 8.0, and 8.0.1) to Cassandra message store.
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 Oracle Solaris whole root zone on the existing hardware. After the new host and environment are 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.
In this model of upgrading Messaging Server, you construct a new target host on a new hardware or in an Oracle Solaris whole root zone on the existing software. After the new host and environment are established, you can migrate users to the new system and decommission your legacy deployment.
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 as mailboxes, from one host to another. On classis message store, you typically use the imsbackup and imsrestore commands. To migrate to Cassandra message store, you must use the rehostuser command.
Might require extra hardware to set up a parallel system. (This can be mitigated by upgrading legacy machines after they are no longer used.)
The steps to upgrade Messaging Server using the Coexistence Model are as follows:
Make sure that your hardware is installed as per your Messaging Server deployment plan. For more information, refer to the previous chapters, or to Messaging Server Installation and Configuration Guide for Cassandra Message Store for Cassandra requirements.
Install a new version of Messaging Server in the proper sequence on a new machine, by using the commpkg install command.
Configure Messaging Server.
You must do so manually. Basically, you must clone the relevant parts of the old machine's configuration to this new machine.
If you are doing a coexistent migration on a message store, migrate user mailboxes (a few at a time) to the new machine. For classic message store use the imsbackup and imsrestore commands. For Cassandra message store, use the rehostuser command. See Messaging Server System Administrator's Guide for more information.
Details on classic message store internals can be found in the Messaging Server System Administrator's Guide.
Note:
To migrate mailboxes from classic message store to Cassandra message store, you must perform a number of steps, including installing message access layer hosts, configuring store affinity groups, installing Cassandra database, rehosting users, and so on. For more information, see Messaging Server Installation and Configuration Guide for Cassandra Message Store.Note:
You cannot use the side-by-side strategy to upgrade a classic message store to Cassandra message store. Instead, you must perform a migration. See Messaging Server Installation and Configuration Guide for Cassandra Message Store for more information.In this model of upgrading Messaging Server, you install the new software on the same machine as the old version. The basic steps are as follows:
Back up configuration data (simply back up the configuration directory).
For classic message store mailbox data, use the imsbackup command.
Install Messaging Server 8.0.2 side-by-side on the same machine with your earlier version of Messaging Server by using the commpkg install command.
Create a symbolic link for a level of indirection that you will use to point to the active Messaging Server installation.
Stop the currently running Messaging Server.
Point to the symbolic link to the Messaging Server 8.0.2 installation.
Start Messaging Server 8.0.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. Any custom scripts that reference the install location must be modified.
Does not involve moving the classic store mailboxes. New version just ”points” to the mailboxes and mailbox conversion to the new version is automatic and transparent.
Backout is complicated and time consuming. See "Downgrading from Messaging Server 8.0.2."
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 backout.
Note:
You cannot use the side-by-side strategy to upgrade a classic message store to Cassandra message store. Instead, you must perform a migration. See Messaging Server Installation and Configuration Guide for Cassandra Message Store for more information.This example describes how to upgrade from Messaging Server 7.0.5.31.0 to Messaging Server 8.0.2 by using the side-by-side method.
This section includes:
This example describes how to install both Messaging Server versions on the same host in separate directories, create a symbolic link to the active installation, then point the symbolic link at the single configuration and data location.
Note:
Upgrading to Messaging Server 8.0.2 in a side-by-side installation works on both Solaris and Oracle Linux. This is not an alternate root installation as described in the discussion on ALTROOT command-line argument in "commpkg Reference". Due to package version changes starting with Messaging Server 8.0.1, you can use the method described in this information rather than the alternate root method, to simplify the upgrade process.This example uses the following directories:
/opt/sun/comms/messaging64: Directory in which Messaging Server 7.0.5.31.0 is installed (default location)
/var/opt/sun/comms/messaging64: Directory containing the Messaging Server 7.0.5.31.0 data and configuration (default location)
/opt/ucs1/messaging64: Directory in which Messaging Server 8.0.2 is installed (non-default location)
Additionally, this example uses the following symbolic link:
/opt/ucs/msg: Symbolic link to either /opt/sun/comms/messaging64 or /opt/ucs1/messaging64
This section includes:
Creating the Symbolic Link for the Active Message Server Installation
Changing Over from Messaging Server 7.0.5.31.0 to Messaging Server 8.0.2
Before performing the upgrade, back up the system. See the following documentation for more information:
See the discussion on best practices for Messaging Server and ZFS in Messaging Server System Administrator's Guide
See the discussion on backing up and restoring the classic message store in Messaging Server System Administrator's Guide
Creating the Symbolic Link for the Active Message Server Installation
This example assumes that you have already installed and configured Messaging Server 7.0.5.31.0 in the default directory (/opt/sun/comms/messaging64), and that the Messaging Server is currently running.
Create a symbolic link for a level of indirection that you will use to point to the active Messaging Server installation.
mkdir -p /opt/ucs cd /opt/ucs ln -s /opt/sun/comms/messaging64 msg
Ensure that external programs or plugins that refer to the Messaging Server installation use this symbolic link. Also, if you use Solaris Management Facility (SMF), ensure that you configure XML settings that start and stop Messaging Server to use this symbolic link.
Installing and Configuring Messaging Server 8.0.2
Change to the directory in which you have extracted the Messaging Server 8.0.2 media pack ZIP file.
Install Messaging Server 8.0.2 into its own directory, /opt/ucs1, by using the following commpkg install command.
commpkg install --comp=MS64 --installroot /opt/ucs1 --silent=NONE
Configure Messaging Server 8.0.2 to point to the existing (Messaging Server 7.0.5.31.0) data and configuration location.
cd /opt/ucs1/messaging64bin/useconfig /var/opt/sun/comms/messaging64/config
Changing Over from Messaging Server 7.0.5.31.0 to Messaging Server 8.0.2
Stop the currently running Messaging Server 7.0.5.31.0 processes.
/opt/ucs/msg/bin/stop-msg
Note that this command actually uses the symbolic link to /opt/sun/comms/messaging64.
Change the symbolic link created previously to point to the Messaging Server 8.0.2 installation.
cd /opt/ucs mv msg msg-old ln -s /opt/ucs1/messaging64 msg
Start the Messaging Server 8.0.2 processes.
/opt/ucs/msg/bin/start-msg
Note that this command actually uses the symbolic link to /opt/ucs1/messaging64.
Your deployment is now upgraded to Messaging Server 8.0.2
After completing the upgrade, remove the symbolic links (data, config, and log) in the previous Messaging Server installation. This is not a requirement, but a recommendation to protect against inadvertently using them.
cd /opt/sun/comms/messaging64 rm data config log
On the next upgrade, now that the two locations are populated, you can simply upgrade the inactive location. Following the preceding example, Messaging Server 8.0.2, installed in /opt/ucs1 is active, and Messaging Server 7.0.5.31.0, installed in /opt/sun/comms is inactive.
Change to the directory in which you have extracted the latest Messaging Server version media pack ZIP file.
If you are upgrading from a Messaging Server version prior to 8.0.2, for example, 7.0.5.31.0, you must remove the symbolic links to the configuration and data, otherwise the uninstall stops the messaging services.
cd /opt/sun/comms/messaging64 rm config data log
Upgrade the inactive Messaging Server installation.
commpkg upgrade --comp=MS64
The upgrade prompts you to select the version that you want to upgrade. Specify the inactive version.
Change the symbolic link created previously to point to the new Messaging Server installation.
cd /opt/sun/comms/messaging64bin/useconfig /var/opt/sun/comms/messaging64/config
Stop the running Messaging Server processes.
/opt/ucs/msg/bin/stop-msg
Note that this command actually uses the symbolic link to /opt/ucs1/messaging64.
Change the symbolic link created previously to point to the new Messaging Server 8.0.2 installation.
Depending on which installation you are upgrading, use one of the following ln commands.
cd /opt/ucs rm msg ln -s /opt/sun/comms/messaging64 msg <or, depending on which installation is upgraded> ln -s /opt/ucs1/messaging64 msg
Start the Messaging services using the new, upgraded version.
/opt/ucs/msg/bin/start-msg
You should remove the symbolic links in the inactive installation, otherwise you might inadvertently use the inactive installation.
Note:
You cannot use the in-place strategy to upgrade a classic message store to Cassandra message store. Instead, you must perform a migration. See Messaging Server Installation and Configuration Guide for Cassandra Message Store for more information.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 more information about this command, see the discussion on the commpkg upgrade command in "commpkg Reference".
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 (no tweaking of custom scripts).
Has the most downtime.
Back out is complicated and time consuming. See "Downgrading from Messaging Server 8.0.2."
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.
The following steps show how to upgrade Messaging Server using In-place Upgrade:
Run commpkg upgrade and select Messaging Server. This command:
Stops the servers
Removes the old version of Messaging Server
Installs the new version of Messaging Server
Performs a migration of configuration and classic store mailbox data
For information about using the commpkg upgrade command, see "commpkg Reference".
If you upgrade using a coexistence migration strategy, you do not need to downgrade or back out a patch because you always have the system with the previous version of Messaging Server still running. Simply uninstall or decommission the newly installed version of Messaging Server on the new system and continue using the previous version on the old system. However, if you upgrade using a side-by-side or an in-place upgrade strategy, then you need to read the following information.
You cannot just back out the upgrade by using commpkg uninstall and then commpkg install from the previous release to reinstall the previous version. Instead, you must back up your Messaging Server data, back out the upgrade, then restore the Messaging Server data. For more information on the commpkg uninstall command, see "commpkg Reference".
These downgrade instructions apply to both the in-place or side-by-side upgrade methods.
Read this section before upgrading to Messaging Server 8.0.2.
You cannot directly upgrade a classic message store to Cassandra message store. Instead, you must perform a migration. See Messaging Server Installation and Configuration Guide for Cassandra Message Store for more information.
You cannot simply back out the Messaging Server 8.0.1 upgrade to a previous version once it is applied.
Because you cannot directly upgrade a classic message store to Cassandra message store, the previous releases' downgrade instructions no longer apply.
Although the system does permit you to back out the upgrade (for example, by running commpkg uninstall and then commpkg install from the previous release to reinstall the previous version, afterwards Messaging Server services may not properly start. Additionally, the stored process may not start properly, and any mailbox accessed prior to backing out the upgrade may report that it is corrupted with an invalid format. Furthermore, even if you could manage to start Messaging Server services and manually fix the mailbox corruption, the mailbox owner flags (for example, seen and deleted flags) are all reset.
Before upgrading to Messaging 8.0.2, make sure that you back up the Messaging Server data. If you do need to downgrade the classic message store after upgrading to Messaging Server 8.0.2, you need to restore the Messaging Server data to its state prior to upgrading.
Before upgrading to Messaging Server 8.0.2, it is highly recommended that you test it on a non-production system prior to actual deployment to production systems.
Backing out from Messaging Server 8.0.2 is considered an avenue of last resort. If you need to downgrade, you must follow the steps described later in this information to return your system to a working state. (Backing out is not relevant to a coexistence migration.)
You need the previous version's software. For example, if you use the installer to upgrade from Messaging Server 7 Update 5, the installer removes the old software, and so to revert to that version, you would need the old product's installer to do so. Note that for scenarios other than classic store to Cassandra store migration, if you do a backup prior to downgrading, and restore from that backup, you do not lose messages that arrived since that backup when you restore.
To back out the upgrade on a host configured without a classic message store such as an MTA host, an MMP host, or a Webmail host, run commpkg uninstall and then commpkg install from the previous release to reinstall the previous version. On a host configured with a classic message store that uses a ZFS file system, you can use the following procedure to back out the upgrade without having to do a full imsbackup/imsrestore thereby taking advantage of the near instantaneous ZFS snapshot and roll back capability.
Create a ZFS snapshot of the message store data including the mboxlist database, index, and message partitions before upgrading.
Once you upgrade, you can back out by:
Performing an incremental imsbackup of the message store since the snapshot time
Using commpkg uninstall and then commpkg install from the previous release to reinstall the previous version
Rolling back to the ZFS snapshot
Restoring the incremental imsbackup
Note however, that if you are backing out to a version prior to Messaging Server 7.0.5.29.0, those versions do not restore message flags from the incremental backup.
Prior to upgrading, stop the services and create a ZFS snapshot of the classic message store. Note that in a subsequent step where a ZFS rollback is done to restore this snapshot, only the store area should be restored. In particular, you should not rollback the MTA queues. For additional information, see the discussion of ZFS best practices in Messaging Server System Administrator's Guide. Note the timestamp when you create the ZFS snapshot. We recommend using the timestamp in the name of the snapshot. The following example assumes that the store area is in the rpool/export/comms-data ZFS partition.
stop-msg zfs list zfs snapshot rpool/export/comms-data@20150601232600
Upgrade and start services.
commpkg upgradestart-msg
If you decide for whatever reason to downgrade, note that this decision should not be taken lightly. This should only be done if there is no other recourse.
Stop services.
stop-msg
Start Message Store services.
start-msg store
Do an incremental imsbackup from the time the ZFS snapshot was taken in Step 1 (timestamp 2015-Jun-01 11:26 pm).
imsbackup -x -v -f - -d 20150601:232600 / > /var/tmp/backup
Note:
It is better if the incremental backup is relatively small.Stop services.
stop-msg
It would seem prudent to do another ZFS snapshot prior to starting the downgrade, but ZFS snapshots do not allow you to rollback to more than the previous snapshot.
Uninstall the Messaging Server.
commpkg uninstall
Reinstall the previous Messaging Server version by running its installer.
commpkg install
Roll back to the ZFS snapshot you created previously.
zfs rollback rpool/export/comms-data@20150601232600
Start the message store services.
start-msg store
Restore the backup you made previously using imsbackup by running imsrestore with the -E switch.
imsrestore -E -f /var/tmp/backup
Start services.
start-msg
Use this procedure if you have upgraded to Messaging Server 8.0.2 and need to return to previous version.
To Downgrade from Messaging Server 8.0.2:
Prior to downgrading, perform a full backup of the classic message store by using the imsbackup command.
For example:
stop-msg start-msg store imsbackup -v -f - / > backup
Uninstall the Messaging Server.
commpkg uninstall
Reinstall the previous Messaging Server version by running its installer.
commpkg isntall
Move the store directory to a different location.
For example:
mv data/store data/store.old
Start the message store to perform the restore:
start-msg store
Perform the restore:
imsrestore -f backup
Start Messaging Server.
For example:
start-msg
To back out the upgrade on a host configured without a classic message store, such as an MTA host, an MMP host, or a Webmail host, run commpkg uninstall and then commpkg install from the previous release to reinstall the previous version.
Upgrading Messaging Server in a highly-available (HA) environment consists of upgrading the Messaging Server software then upgrading the Messaging Server Oracle Solaris Cluster Agent.
This section includes the following topics:
Upgrade strategies, each of which require different procedures, include the follow:
Coexistent upgrade: This is similar to a fresh HA installation. See "Configuring Messaging Server for High Availability" for more information.
Side-by-side upgrade
In-place HA upgrade
Go to resource group online node.
Disable Messaging Server resource.
scswitch -n -j msg_svr_resource
Upgrade Messaging Server by using the side-by-side strategy. See "Using the Side-by-Side Upgrade on Messaging Server" for more information. Perform this step only on the Messaging Server resource group online node. Do not start Messaging Server yet.
Run the ha_ip_config command on the Messaging Server resource group online node.
MessagingServer_home/bin/ha_ip_config
This command is needed only if the currently installed Messaging Server is prior to version 7.0.
Start the watcher process once on the Messaging Server resource group online node.
start-msg watcher
Switch over to other node:
scswitch -z -g msg_svr_resource_group -h node-name
Run the useconfig command.
This is needed if you are upgrading Messaging Server from 32-bit to 64-bit, to update the trusted library path for 64-bit applications to include Messaging Server /bin/crle -s -64 new_MessagingServer_home/lib').
MessagingServer_home/bin/useconfig MessagingServer_home/config
Change IMS_serverroot path for Messaging Server resource if new Messaging Server base directory is different from old installation.
scrgadm -cj msg_svr_resource -x IMS_serverroot=new_MessagingServer_home
If Messaging Server Oracle Solaris Cluster agent (MS_SCHA) is old (not from Communications Suite 6 or later), then it does not work with upgraded Messaging Server and you need to perform the MS_SCHA upgrade procedure.
Enable Messaging Server resource.
scswitch -e -j msg_svr_resource
An in-place upgrade is done by using the commpkg upgrade command.
Disable Messaging Server resource:
scswitch -n -j msg_svr_resource
Run the commpkg upgrade command on all nodes of the cluster
Run the ha_ip_config command on the Messaging Server resource group online node.
MessagingServer_home/bin/ha_ip_config
This command is needed only if the currently installed Messaging Server is prior to version 7.0.
Start the watcher process once on the Messaging Server resource group online node.
start-msg watcher
Enable Messaging Server resource:
scswitch -e -j msg_svr_resource
This section provides instructions for the Oracle Solaris Cluster Agent upgrade. It consists of the following sections:
Run commpkg upgrade on all nodes on the cluster.
Messaging Server should be upgraded to 8.0.q before upgrading Messaging Server Oracle Solaris Cluster Agent.
Enable Messaging Server resource:
scswitch -e -j msg_svr_resource
If a machine that has non-global zones participates in a cluster, all zones on that machine must be in the cluster. The Oracle Solaris Cluster software and HA agents should be installed in all zones, and MS_SCHA should be installed in the global zone and automatically propagated into all non-global zones (that is, don't use the -G switch to pkgadd). The Messaging Server Installer treats HA agents like MS_SCHA as a product that should be propagated to all non-global zones when it is installed in the global zone. In the rare case where you have managed to install the pre-version 7 MS_SCHA agent in the non-global zones, then an upgrade consists of first uninstalling the older agent from all non-global zones, followed by installing the new 7 MS_SCHA agent in the global zone.
To check if the older pre-version 7 agent was installed in the global zone and automatically propagated to all non-global zones, verify that SUNWscims is listed in /var/sadm/install/gz-only-packages. If it is, then run commpkg upgrade in the global zone. If it is not listed, then SUNWscims is either not installed, or is installed so that it is propagated to non-global zones. If this is this case, use the following procedure:
Run commpkg uninstall and uninstall MS_SCHA in every non-global zone (do not uninstall it in the global zone).
In the global zone, run commpkg upgrade and upgrade MS_SCHA.
Upgrade Messaging Server to Version 8.0.2 before upgrading the Messaging Server Oracle Solaris Cluster Agent.
Make sure that the Messaging Server installation location is accessible from both nodes.
This is required because a resource type upgrade command validates accessibility. For the first instance in a Symmetric Cluster setup, Messaging Server installation is done on first node only (on a shared storage mount point). For the second instance, Messaging Server installation is done on second node only.
Follow the steps mentioned in "To Upgrade to the Messaging Server Oracle Solaris Cluster Agent (MS_SCHA)."
Note:
If you prefer to upgrade Oracle Solaris Cluster Agent (MS_SCHA) for only one instance, then follow the prior steps and correct the resource type version using Oracle Solaris Cluster commands.When you run the installer to upgrade in silent mode, you are running a non-interactive session. The upgrade inputs are taken from the following sources:
A silent installation file (also known as a state file)
Command-line arguments
Default settings
You can use silent mode to upgrade multiple instances of the same software and configuration without having to manually run an interactive upgrade for each instance.
To run a Messaging Server silent upgrade:
Obtain the state file by one of the following two means:
Run an interactive upgrade session and use the state file that is created in the /var/opt/CommsInstaller/logs/ directory. The state file name is similar to silent_CommsInstaller_20070501135358. A state file is automatically created for every run of the installation.
Create a silent state file without actually installing the software during the interactive session by using the --dry-run option, then modifying the state file.
For example:
commpkg upgrade --dry-run
Copy the state file to each host and edit the file as needed. See Silent Mode File Format.
Run the silent installation on each host.
For example:
commpkg upgrade --silent Input_File
where Input_File is the path and name of the silent state file, for example /var/opt/CommsInstaller/logs/silent_CommsInstaller_20070501135358.
For details about the --silent option, see the discussion on the silent installation usage in "commpkg Reference".
Note:
Command-line arguments override the values and arguments in the state file.Note:
If you specify None for the silent file, then defaults are used for the property values.The silent mode file (also known as a state file) is formatted like a property file: comment lines begin with a number sign (#) and properties are key/value pairs separated by an equals (=) sign. Table 13-1 displays the changes you can make to the following options. For more information on the commpkg upgrade options, see the discussion on commpkg upgrade options in "commpkg Reference".
Table 13-1 Silent Mode File Options
| Option | Description | Example |
|---|---|---|
|
VERB |
Indicates which function to perform. You can add CLI arguments described in "commpkg Reference," however the ---dry-run argument cannot be added to the install function in the state file. |
VERB=upgrade |
|
USEPKGUPGRADE |
Indicate whether to perform upgrade by using pkgrm and pkgadd commands. |
USEPKGUPGRADE=no |
|
UPGRADESC |
Indicates whether all shared components should or should not be upgraded without prompting. |
UPGRADESC=no |
|
PKGOVERWRITE |
Forces the overwriting of the existing installation packages even if patches are available to do the upgrade. |
PKGOVERWRITE=YES |
|
INSTALLROOT |
Specifies installation root. |
INSTALLROOT=/opt/sun/comms |
|
EXCLUDESC |
Specifies to exclude shared component patches. |
EXCLUDESC=no |
|
EXCLUDEOS |
Specifies to not upgrade operating system patches. |
EXCLUDEOS=YES |
|
COMPONENT_VERSIONS |
unused |
COMPONENT_VERSIONS= 7.4 6.4 7.2 8.3 2.0 1.3 7.0 |
|
COMPONENTS |
Lists the components you want to upgrade. |
COMPONENTS=MS64 to specify 64-bit Messaging Server |
|
ALTROOT |
Specifies an alternate root. |
ALTROOT=yes |
|
ALTDISTROPATH |
Indicates an alternate distro path if --distro is not specified. |
ALTDISTROPATH=SunOS5.10_i86pc_DBG.OBJ/release |