test

Sun Java System Messaging Server 6 2005Q4 Administration Guide

Chapter 2 Upgrading to Sun Java System Messaging Server

This chapter describes how to upgrade from Messaging Server 5.2 to the current version of Messaging Server.

Before You Begin

Prior to performing the upgrade, ensure the following:

Note –

Unlike previous versions of Messaging Server, you cannot upgrade your existing Messaging Server without first installing and configuring the current version of Messaging Server.

Also, you cannot use this upgrade program with Messaging Server versions older than version 5.2. Therefore, you must first migrate or upgrade to Messaging Server 5.2, install Messaging Server 6 2005Q4 and then run this upgrade program. See the iPlanet Messaging Server 5.2 Migration Guide for more information on migrating to Messaging Server 5.2.

Overview of the Upgrade Process

The following topics outline the steps to upgrade from Messaging Server 5.2 to the current version of Messaging Server.

Creating Upgrade Files to Update your Configuration

This section describes how special upgrade files are created in order to update the configuration on your Messaging Server:

About Upgrade Files

Prior to running an upgrade utility to move from Messaging Server 5.2 to 6, you first need to run the UpgradeMsg5toMsg6.pl Perl script (located in msg_svr_base/sbin).

UpgradeMsg5toMsg6.pl compares your 5.2 configuration files with your Messaging Server 6 configuration files and creates two sets of files for each configuration file: *.CHANGES files and *.MERGED files.

The *.CHANGES files and *.MERGED files are generated in the work space directory, /var/tmp/UpgradeMsg5toMsg6.ScratchDir.

The *.CHANGES files show critical configuration file differences between Messaging Server 5.2 and the current version of Messaging Server. These files highlight the configuration entities that are only found in Messaging Server, the configuration entities from Messaging Server 5.2 that are obsolete in this current version of Messaging Server, and the configuration entities that are only found in the Messaging Server 5.2. Not all *.CHANGES files will show differences between the versions of configuration files, and not all configuration files will generate *.CHANGES files.

The *.MERGED files are a consolidation of Messaging Server 5.2 and the current version of Messaging Server configuration values and settings. In general, configuration parameter values from Messaging Server 5.2 are retained over the current version of Messaging Serverif:

Table 2–1 lists the configuration files that generate *.MERGED or *.CHANGES files.

Table 2–1 Messaging Server Configuration Files that Generate *.MERGED or *.CHANGES files

Configuration Information  

Description 

Generates *.MERGED File

Generates *.CHANGES File

job_controller.cnf

Job Controller File 

X

X

conversions

Conversions File 

X

 

channel_option, where channel is an SMTP channel

SMTP channel option files 

X

 

native_option

Native channel option file (exception to channel_option)

X

X

channel_headers.opt, where channel is an SMTP channel

Header option files 

X

 

dispatcher.cnf

Dispatcher File 

X

X

imta_tailor

Tailor File 

X

X

option.dat

Global MTA Option File 

X

X

aliases

Aliases File 

X

 

imta.cnf

MTA Configuration File. Only the include references (like file directory locations) are changed. Rewrite rule and channel settings are retained from your 5.2 configuration. To include LMTP in your imta.cnf, copy the LMTP information from your Messaging Server 6 imta.cnf file.

X

In some instances, a *.CHANGES file may be generated.

mappings

Mappings File 

X

 

mappings.locale

Localized Mappings File 

X

 

internet.rules

Internet Rule Configuration File 

X

 

backup-groups.conf

Backup Group Definitions 

X

X

configutil

Changes of configuration parameters in local.conf and msg.conf configuration files.

 

X

ProcedureTo Run the UpgradeMsg5toMsg6.pl Perl Script

To run the UpgradeMsg5toMsg6.pl to create sets of files by which you’ll be able to update your configuration, follow these steps:

Before You Begin

Both your 5.2 and current version of Messaging Server can be running at this point.

If your Messaging Server 5.2 and 6 versions are on the same machine, start with Step 2.

Steps

  1. If your Messaging Server 5.2 and 6 versions are not on the same machine, transfer, extract and copy the Messaging Server 5.2 server-root directory to the current version of Messaging Server.

    If your server versions are installed on the same machine, you can skip this step.

    If your Message Store is too large to transfer from one system to another, you can transfer just the essential portions of the server instance to the new system. There are comments inside of the UpgradeMsg5toMsg6.pl which cover this in detail.

    You don't have to copy the Messaging Server 5.2 store data to the Messaging Server 6 2005Q4 system, however, you must ensure that the Messaging Server 5.2 mboxlist directory is accessible during the upgrade process.

  2. Run the UpgradeMsg5toMsg6.pl upgrade script.

    By default, this script is located in msg_svr_base/sbin.

    Run the script against the msg-instance of 5.2 version and the msg_svr_base of the current version of Messaging Server. For example:


    perl UpgradeMsg5toMsg6.pl /usr/sunone/server5/msg-budgie \
  /opt/SUNWmsgsr

    where /usr/sunone/server5/msg-budgie is the msg-instance of the 5.2 Messaging Server and /opt/SUNWmsgsr is the msg_svr_base of the current version of Messaging Server.

    The process creates *.MERGED and *.CHANGES files (as described in About Upgrade Files).

  3. Carefully review the *.MERGED files to determine if you need to adjust the settings.

    If you don’t want to use the suggested recommendations, you must manually adjust the settings.

    This utility does not update the Messenger Express customization files. Therefore, you need to manually change these files in order to keep the relevant information from Messaging Server 5.2 and add any new information from the current version of Messaging Server installation.

Running the Upgrade Utility

This section describes the do_the_upgrade.sh utility (located in /var/tmp/UpgradeMsg5toMsg6.ScratchDir), a shell script that is made up of four sub-scripts. The following topics are covered in this section:

Overview of the Upgrade Utility

The do_the_upgrade.sh utility is made up of four shell scripts that, with your *.MERGED files, update the configuration and file directory locations of your MTAconfiguration, your configutil parameters, backup parameters, and your mboxlist database in your current version of Messaging Server system.

You can either run the do_the_upgrade.sh utility, or you can individually run one or more of the scripts that make up the do_the_upgrade.sh utility (make_mta_config_changes.sh, make_configutil_changes.sh, make_backup_config_changes.sh, and make_mboxlistdb_changes.sh).

If you want to upgrade an MTA relay machine from Messaging Server 5.2 to current version of Messaging Server, you only need to run the make_mta_config_changes.sh and the make_backup_config_changes.sh (described in Backup Configuration).

When executing either the do_the_upgrade.sh utility or any of the sub-scripts, be sure that neither Messaging Server 5.2 nor 6 2005Q4 is up and running.

ProcedureTo Run the do_the_upgrade.sh Utility

Steps

  1. Shut down both the 5.2 and the current version of Messaging Servers.

  2. Run the utility:


    # sh /var/tmp/UpgradeMsg5toMsg6.ScratchDir/do_the_upgrade.sh

    After running the do_the_upgrade.sh script, you can either continue to reference your 5.2 partition paths (though you will not be able to remove your Messaging Server 5.2 server-root directory) or you can manually move the 5.2 store partitions to the appropriate current version of Messaging Server directory location. You should perform this step prior to restarting Messaging Server.

MTA Configuration

The MTA upgrade configuration sub-script that makes up of part of the do_the_upgrade.sh utility is called make_mta_config_changes.sh (located in /var/tmp/UpgradeMsg5toMsg6.ScratchDir).

The make_mta_config_changes.sh script backs up, renames, and moves the *.MERGED server configuration files to their original names and locations within the current version of Messaging Server file directory structure.

Once the script has finished renaming and moving the files, it automatically runs the imsimta cnbuild command to recompile the MTA configuration.

Note –

If you want to upgrade an MTA relay machine from Messaging Server 5.2 to the current version of Messaging Server, you only need to run the make_mta_config_changes.sh and the make_backup_config_changes.sh (described in Backup Configuration).

configutil Parameters

The configutil upgrade configuration sub-script that makes up part of the do_the_upgrade.sh utility is called make_configutil_changes.sh script (located in /var/tmp/UpgradeMsg5toMsg6.ScratchDir).

The make_configutil_changes.sh script incorporates new or updated parameters in the msg.conf and local.conf files. If default values are not specified in configutil parameters in the current version of Messaging Server, any Messaging Server 5.2 values are carried forward to the current version of Messaging Server version.

Backup Configuration

The backup upgrade configuration sub-script that makes up part of the do_the_upgrade.sh utility is called make_backup_config_changes.sh script (located in /var/tmp/UpgradeMsg5toMsg6.ScratchDir).

The make_backup_config_changes.sh script upgrades the configuration of your backup services such as those in your backup-groups.conf file.

mboxlist Database

The mboxlist database upgrade configuration sub-script that makes up part of the do_the_upgrade.sh utility is called make_mboxlistdb_changes.sh script (located in /var/tmp/UpgradeMsg5toMsg6.ScratchDir).

The make_mboxlistdb_changes.sh script transfers and upgrades your 5.2 mboxlist database and upgrades it to the current version of Messaging Server directory structure. The script copies the four *.db files (folder.db, quota.db, peruser.db, and subscr.db) from server-root/msg-instance/store/mboxlist on your Messaging Server 5.2 system to msg_svr_base/data/store/mboxlist on your current version of Messaging Server system.

Migrating User Mailboxes

This section describes how to migrate user mailboxes from one Messaging Server to another Messaging Server. While this section focuses on migrating Messaging Server 5.2 to your Messaging Server 6 2005Q4 system, the online migration process can apply to any post–5.2 Messaging Servers . The online migration is probably the most convenient, but alternative migration methods are also described.

If you are upgrading Messaging Server 5.2 to Messaging Server 6 and upgrading the entire message store database, you do not need to follow these migration procedures. The make_mboxlistdb_changes.sh script described in the previous section can be used to upgrade your database more efficiently.

You only need to perform these procedures if:

If you choose to migrate mailboxes using these procedures, do not map the partition paths to the Messaging Server 5.2 partitions and also do not run the make_mboxlist_changes.sh script.

The make_configutil_changes.sh script generated by the upgrade script automatically sets the partition path to map to the Messaging Server 5.2 partitions. You need to alter this manually. In addition, you should remove the invocation of the make_mboxlistdb_changes.sh script from your do_the_upgrade.sh script.

To move user mailbox data from Messaging Server 5.2 to the current version of Messaging Server in an online method, follow the steps described in the following section. You should not need to bring the Messaging Server down while you move data.

The following procedures are provided:

Migrating User Mailboxes to Another Messaging Server While Online

You can use this procedure to migrate the message store from an older version of Messaging Server to a newer version or to move mailboxes from one Sun Messaging Server message store to another. This procedure should work for iPlanet Messaging Server 5.0 and later. It cannot be used to move messages from earlier versions of Messaging Server or a non-Sun Microsystems message store.

The advantages of moving mailboxes using this procedure are as follows:

The disadvantages of moving mailboxes using this procedure are as follows:

Incremental Mailbox Migration

Incremental migration provides numerous advantages for safely and effectively moving your message store to a different system or upgrading to a new system, Incremental migration allows you to build a new back-end message store system alongside the old back-end message store. You can then test the new system, migrate a few friendly users, then test the new system again. Once you are comfortable with the new system and configuration, and you are comfortable with the migration procedure, you can start migrating real commercial users. These users can be split into discrete backup groups so that during migration, only members of this group are offline, and only for a short time.

Another advantage of on-line incremental migration is that you do not have to plan for a system-wide backoff in case the your upgrade fails. A backoff is a procedure for reverting changes you have made to a system to return the system to the original working state. When doing a migration, you have to plan for failure, which means that for every step in the migration requires a plan to return your system back to its previous operational state.

The problem with offline migrations is that you can't be sure your migration is successful until you've completed all the migration steps and switched the service back on. If the system doesn't work and cannot be quickly fixed, you'll need a backoff procedure for all the steps performed. This can be stressful and take some time, during which your users will remain offline.

With an on-line incremental migration you perform the following basic steps:

1. Build the new system alongside the old one so that both can operate independently.

2. Configure the old system for the coexistence with the new.

3. Migrate a group of friendly users and test the new system and its coexistence with the old system.

4. Divide the users on the old system into groups and migrate group by group to the new one as desired.

5. Disassemble the old system.

Because both systems will co-exist, you will have time to test and get comfortable with the new system before migrating to it. If you do have to perform a backoff procedure--which should be very unlikely--you only have to plan for steps 2 and 4. Step 2 is easy to revert since you don't ever touch user's data. In step 4, the backoff is to revert the user's state back to active and their mailhost attribute back to the old host. No system-wide backoff is required.

On-line Migration Overview

Migrating mailboxes while remaining online is a straightforward process. Complications arise when you try to ensure that messages in transit to the mailbox (sitting in an MTA channel queue waiting for delivery) are not lost in the migration process. One solution is to hold messages sent during the migration process in a held state and wait for the messages in the various channel queues to be delivered. However, messages can get stuck in queues because of system problems or because a particular user is over quota. In this case, you must address this situation before migrating the mailboxes.

You can take various measures to reduce the likelihood of lost messages and to verify that messages are not stuck in a channel queue, but at a cost of increased complexity of the procedure.

The order and necessity of steps in the procedure vary depending upon your deployment and whether every message addressed to every mailbox must not be lost. This section describes the theory and concepts behind the steps. It is incumbent on you to understand each step and decide which to take and in which order, given your specific deployment. Following is an overview of the process of moving mailboxes. This process might vary depending upon your deployment.

  1. Block user access to the mailboxes being moved.

  2. Temporarily hold messages addressed to the mailbox being moved.

  3. Verify that messages are not stuck in the channel queues.

  4. Change the user's mailhost attribute to the new mailbox location.

  5. Move the mailboxes to the new location.

  6. Release held mail to be delivered to the new mailbox and enable incoming messages to be delivered to the migrated mailboxes.

  7. Examine the old message store to see if any messages were delivered after the migration.

ProcedureTo Migrate User Mailboxes from One Messaging Server to Another While Online

Before You Begin

The requirements for this type of migration are as follows:

Note –

Some steps apply only if you are upgrading the messaging server from an earlier version to a later version. These steps might not apply if you are only migrating mailboxes from one message store to another. The steps that apply to migrating entire systems are noted.

Steps

  1. On the source system, split your user entries to be moved into equal backup groups using the backup-groups.conf file.

    This step is in preparation for the mailbox migration, Step 8, that occurs later in this procedure. See To Create Backup Groups for detailed instructions.

    You can also place the user names into files and use the -u option in the imsbackup command.

  2. Notify users to be moved that until the move process is completed, they will not have access to their mailboxes until the move is completed.

    Ensure that users to be moved are logged out of their mail systems before the data move occurs. (See Monitoring User Access.)

  3. Set the authentication cache timeout to 0 on the back-end message store and MMP systems, and ALIAS_ENTRY_CACHE_TIMEOUToption to 0 on the MTAs.

    1. On the back end message stores containing the mailboxes to be moved, set the authentication cache timeout to 0.


      configutil -o service.authcachettl -v 0

      This step and Step 7 (changing mailUserStatus to hold) immediately prevents users from accessing their mailboxes during migration.

    2. On all MMPs, set the authentication cache timeout to 0.

      In ImpProxyAService.cfg and PopProxyAService.cfg set LdapCacheTTL to 0.

    3. On any Messaging Server that hosts an MTA that inserts messages into mailboxes that are to be migrated, set the ALIAS_ENTRY_CACHE_TIMEOUT option to 0.

      Messaging Servers hosting an MTA that inserts messages into the migrating mailboxes will typically be the back end message store. However, if the system is using LMTP, then that system will be the inbound MTAs. Check your configuration to make sure.

      Resetting ALIAS_ENTRY_CACHE_TIMEOUT in /msg_svr_base/config/option.dat forces the MTA to bypass the cache and look directly at the LDAP entry so that intermediate channel queues (for example, the conversion or reprocess channels) see the new mailUserStatus (hold) of the users being moved rather then the out-of-date cached information. ALIAS_ENTRY_CACHE_TIMEOUT is in option.dat.

    4. Restart the systems on which the caches were reset.

      You must restart the system for these changes to take place. See Starting and Stopping Services for instructions.

  4. Ensure that both your source Messaging Server and destination Messaging Server are up and running.

    The source Messaging Server must be able to route incoming messages to the new destination server.

  5. Change the LDAP attribute mailUserStatus on all user entries whose mailboxes will be moved from active to hold.

    Changing the attribute holds incoming messages in the hold queue and prevents access to the mailboxes over IMAP, POP, and HTTP. Typically, users will be moved in groups of users. If you are moving all the mailboxes of a single domain, you can use the mailDomainStatus attribute.

    For more information on mailUserStatus, see the mailUserStatus in Sun Java System Communications Services 6 2005Q4 Schema Reference.

  6. Make sure that messages addressed to mailboxes being migrated are not stuck in the ims-ms ortcp_lmtp* channel queues (if LMTP has been deployed) channel queues.

    Use the following commands to see if messages exist in the channel queue directory tree and in the held state (to see .HELD files) addressed to a user to be migrated:


    imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree

imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree

    If there are messages in the queue, run these same commands later to see if the MTA has dequeued them. If there are messages that are not being dequeued, then you must address this problem before migrating. This should be a rare occurrence, but possible causes are recipient mailboxes being over quota, mailboxes being locked perhaps because users are logged in and moving messages, the LMTP backend server is not responding, network or name server problems, and so on).

  7. Change the LDAP attribute mailHost in the user entries to be moved as well as in any mail group entries*.

    Use the ldapmodify command to change the entries to the new mail server. Use the ldapmodify that comes with Messaging or Directory Server. Do NOT use the Solaris OS ldapmodify command.

    * You only need to change the mailHost attribute in the mail group entry if the old mail host is being shut down. You can either change this attribute to the new mail host name or just eliminate the attribute altogether. It is optional for mail groups to have a mailHost. Having a mailHost means that only that host can do the group expansion; omitting a mailHost (which is the more common case) means all MTAs can do the group expansion. Note that mail group entries do not have mailboxes to be migrated and typically do not even have the mailhost attribute.

    For more information on mailhost, see the mailHost in Sun Java System Communications Services 6 2005Q4 Schema Reference.

  8. Move the mailbox data from the source Messaging Server message store to the destination Messaging Server message store and record the time when started.

    Back up the mailboxes with the imsbackup utility and restore them to the new Messaging Server with the imsrestore utility. For example, to migrate mailboxes from a Messaging Server 5.2 system called oldmail.siroe.com to newmail.siroe.com, run the following command on oldmail.siroe.com:


    /server-root/bin/msg/store/bin/imsbackup -f- /instance/group     \
| rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh   \
-f- -cy -v1

    You can run multiple concurrent backup and restore sessions (one per group) to maximize the transfer rate into the new message store. See the Command Descriptions in Sun Java System Messaging Server 6 2005Q4 Administration Reference for more information about the imsbackup and imsrestore utilities as well as Backing Up and Restoring the Message Store.

    Note –

    Record the timestamp of when imsbackup is run for later delivery validation.

  9. (Conditional Step for System Upgrades) If your mailbox migration is part of the process of upgrading from an earlier version of Messaging Server to the current version, set this current version of Messaging Server to be the new default Messaging Server for the system.

    Change the DNS A record of oldmail.siroe.com to point to newmail.siroe.com (the server responsible for domain(s) previously hosted on oldmail.siroe.com).

  10. Enable user access to the new message store.

    Set the LDAP attribute mailUserStatus or mailDomainStatus, if applicable, to whatever value it had been before it was changed to hold (for example,active).

  11. Release the messages in the held state on all source Messaging Servers.

    Any system that may be holding incoming messages needs to run the following command to release all the user messages:


    imsimta qm release -channel=hold -scope

    where scope can be all, which releases all messages; user, which is the user ID; or domain is the domain where the user resides.

  12. Reset the authentication cache timeout and the ALIAS_ENTRY_CACHE_TIMEOUT option to the default or desired values and restart the system.

    At this point, you've migrated all the user mailboxes that need to be migrated. Before proceeding, make sure that no new entries in LDAP have been created with the old system as the mailhost, and if some have, migrate them. Also, make sure that no such entries can be created by modifying the provisioning systems.

    You will also want to change the preferredmailhost attribute to the name of the new mail host.

    For back-end messages stores, set authentication cache timeout as follows:


    configutil -o service.authcachettl -v 900

    For the MMPs, in ImpProxyAService.cfg and PopProxyAService.cfg set the LdapCacheTTL option to 0.

    For MTAs, set the ALIAS_ENTRY_CACHE_TIMEOUT option to 600. ALIAS_ENTRY_CACHE_TIMEOUT is in option.dat.

    You must restart the system for these changes to take place. See Starting and Stopping Services for instructions.

  13. Ensure that the user clients are pointing to the new mail server.

    After the upgrade finishes, have the users point to the new server through their mail client program (in this example, users would point to newmail.siroe.com from oldmail.siroe.com).

    An alternative is to use a messaging multiplexor (MMP) which obviates the need to have users point their clients directly to the new mail server. The MMP gets that information from the mailHost attribute which is stored in the LDAP user entries and automatically redirects the client to the new server.

  14. After everything works, verify that no messages were delivered to the old message store after the migration.

    Go to the old message store and run mboxutil -l to list the mailboxes. Check the last message delivery timestamp. If a message was delivered after the migration timestamp (the date stamp when you ran the imsbackup command), then migrate those messages with a backup and restore command. Because of the preparatory steps provided, it would be exceedingly rare to see a message delivered after migration.

    Theoretically, a message could be stuck in a queue for the number of days or hours specified by the notices channel keywords (see To Set Notification Message Delivery Intervals).

  15. Remove duplicate messages on the new message store, run the relinker command.

    This command might free disk space on the new message store. See Reducing Message Store Size Due to Duplicate Storage of Identical Messages.

  16. Remove the old messages from the store you migrated from and delete users from the database on the old store.

    Run the mboxutil -d command. (See The mboxutil Utility).

ProcedureTo Move Mailboxes Using an IMAP client

This procedure can be used anytime messages need to be migrated from one messaging server to a different messaging server. Consider the advantages and disadvantages before moving mailboxes using this method.

The advantages of moving mailboxes using IMAP clients are as follows:

The disadvantages of moving mailboxes using IMAP clients are as follows:

Steps

  1. Install and configure the new Messaging Server.

  2. Set local.store.relinker to enable.

    This will reduce the message store size on the new system caused by duplicate storage of identical messages. See Reducing Message Store Size Due to Duplicate Storage of Identical Messages for more information.

  3. Provision users on the new Messaging Server.

    You can use Delegated Administrator to do this. As soon as users are provisioned on the new system, newly arriving mail will be delivered to the new INBOX.

  4. Have users configure their mail client to view both new and old Messaging Server mailboxes.

    This may involve setting up a new email account on the client. See mail client documentation for details.

  5. Instruct users to drag folders from their old Messaging Server to their new Messaging Server.

  6. Verify with users that all mailboxes are migrated to the new system, then shut down the user account on the old system.

ProcedureTo Move Mailboxes Using the moveuser Command

This procedure can be used anytime messages need to be migrated from one messaging server to a different messaging server. It is useful for migrating IMAP mailboxes from a non-Sun Messaging Server to the Sun Java System Messaging Server. Consider the advantages and disadvantages before moving mailboxes using this method.

The advantages of moving mailboxes using the moveuser command are as follows:

The disadvantages of moving mailboxes using the moveuser command are as follows:

Steps

  1. Install and configure the new Messaging Server.

  2. Set local.store.relinker to enable.

    This will reduce the message store size on the new system caused by duplicate storage of identical messages. See Reducing Message Store Size Due to Duplicate Storage of Identical Messages for more information.

  3. Halt incoming mail to the messaging servers.

    Set the user attribute mailUserStatus to hold .

  4. Provision users on the new Messaging Server if needed.

    If you are migrating from a previous version of messaging server, you can use the same LDAP directory and server. moveuser changes the mailhost attribute in each user entry.

  5. Run the moveuser command.

    To move all users from host1 to host2, based on account information in the Directory Server siroe.com:


    MoveUser -l \
"ldap://siroe.com:389/o=siroe.com???(mailhost=host1.domain.com)" \
-D "cn=Directory Manager" -w password -s host1 -x admin \
-p password -d host2 -a admin -v password

    See the MoveUser in Sun Java System Messaging Server 6 2005Q4 Administration Reference for details on the moveuser command.

  6. Enable user access to the new messaging store.

    1. Set the mailUserStatus LDAP attribute to active.

    2. Run the following command to set the authentication cache timeout value to 0 and immediately allow access to the message store.


      configutil -o service.authcachettl -v 0

  7. Shut down the old system.

ProcedureTo Move Mailboxes Using the imsimport Command

This procedure is specifically used to move mailboxes from UNIX /var/mail format folders into a Sun Java System Messaging Server message store. However, if the messaging server from which you are migrating can convert the IMAP message stores to UNIX /var/mail format, then you can use the imsimport command to migrate messages to the Sun Java System Messaging Server. Consider the advantages and disadvantages before moving mailboxes using this method.

The advantage of moving mailboxes using the imsimport command is as follows:

The disadvantages of moving mailboxes using the imsimport command are as follows:

Steps

  1. Install and configure the new Messaging Server.

  2. Set local.store.relinker to enable.

    This will reduce the message store size on the new system caused by duplicate storage of identical messages. See Reducing Message Store Size Due to Duplicate Storage of Identical Messages for more information.

  3. Provision users on the new Messaging Server if needed.

    You can use Delegated Administrator to do this. Do not switch over to the new system yet.

  4. Disable user access to both the new and old messaging store.

    Set the mailUserStatus LDAP attribute to hold. User’s mail is sent to the hold queue and access to the mailbox over IMAP, POP, and HTTP is disallowed. MTA and Message Access Servers on the store server must comply with this requirement. This setting overrides any other mailDeliveryOption settings.

  5. If the mail store from the existing mail server is not already in the /var/mail format, convert the mail store to /var/mail files.

    Refer to the third-party mail server documentation.

  6. Run the imsimport command.

    For example:


    imsimport -s /var/mail/joe -d INBOX -u joe

    See the imsimport in Sun Java System Messaging Server 6 2005Q4 Administration Reference for details on the imsimport command.

  7. Enable user access to the message store.

    1. Set the mailUserStatus LDAP attribute to active.

    2. Run the following command to set the authentication cache timeout value to 0 and immediately allow access to the message store.


      configutil -o service.authcachettl -v 0

  8. Enable user access to the new and old messaging store.

  9. Shut down the old system.