How to Migrate (Move) a Post Office From One Server to Another (All Steps)

An administrator wants to move (migrate) a post office from one server to another.  Can Reload assist with this?

Yes, Reload has a very powerful yet easy-to-use migration tool.  This guide is for standard migration situations where the users remain on the live post office during the migration process.  If your users are on the Reload disaster recovery post office (the profile is in disaster recovery mode and the clients are connecting to the DR POA), see "How to Migrate a Post Office While In Disaster Recovery Mode (All Steps)".

While this guide addresses moving a post office to another server, the Reload migration tool can also be used to move a domain.  This is a comprehensive guide of the migration process, which means it provides all of the major phases and their steps:

• Planning
• Setup / Pre-Migration
  
• Migration
• Post Migration

This guide makes some assumptions:

• The new server has already been connected to the network
• The OS has been installed and properly patched and configured, including assigning an IP address and hostname. 
  
• The Reload server can see the new server and communicate with it (including disabling the server's firewall or opening up the necessary ports to allow proper communication).
• The administrator or someone in the organization knows how to export directories (Linux) or share folders (Windows).  If the new server is NetWare, then exports and shares do not apply.
• If NetWare, NCPFS has been installed on the Reload server.
• The administrator has a proficient working knowledge of GroupWise, including agent installation and administration through ConsoleOne.

PLANNING

1.  Set aside a day to run the pre-migration process days in advance of the final migration.

The BLOBS (a.k.a., "offiles" or "attachments" directory) constitutes 85 - 90% of the size of most post offices.  For large post offices, it can take several days to copy the BLOBS to the new server.  Reload provides a pre-migration process that only copies the BLOBS (see Step 5 in the "Setup" section).  Plan on doing this several days before the final migration.

2.  Set aside a day that is least disruptive for your users.

Users will not be able to use GroupWise during the migration phase, which could last several hours or more.  This is typically done on a weekend.  Depending on the size of the post office, Friday night or Saturday morning might be the best time to begin the final migration (again, this assumes the pre-migration process has already completed).

3.  Plan disk space needs for the new server.

Obviously, you will be considering the size of your current post office and room for future growth; however, if you follow planning step 4 (estimate migration time) and run the full migration before the actual final migration, it is important to understand that this takes up additional space - at least temporarily until you determine it is safe to remove renamed directories.

The full migration process  will be copy over all of the backed up contents of your post office directory, which includes user and message databases.  When you run the full migration process for the final time, it will rename the current OFUSER, OFMSG and other existing directories from the first run of the full migration, and will create those directories and copy their contents anew.  See "Duplicate Directories and Files After Multiple Final (Full) Migration Jobs".

4.  Estimate the time it might take to perform the migration and post migration steps.

a)  Run "Step #4" in the Reload migration tool (after completing the "Step #1" pre-migration process).

Since it is very hard to predict how long the final migration will take (due to varied sizes of post offices), you may want to consider running "Step #4" in the Reload migration tool (full migration) a couple of days in advance just to get an idea of how long your post office will take to migrate.  This has no impact on production users as it will involve the Reload server and the new server not yet in production.

b)  Note how long your last backup for that post office took to complete.

In the Reload web interface, hover the mouse over the backup date under the "Status" column (i.e., [TUEMAY28]).  That will provide a popup that gives the backup stats.

c)  Estimate the time it might take to complete the post migration activities (see the "Post Migration" section).

d)  Add the times in A, B, and C.  This is your estimated migration time.

EXAMPLE:

• The full migration time (step "a" above) = 2 hours
• Post office backup time (step "b" above) = 1.5 hours
• Post migration steps time (step "c" above) = 1.5 hours
• TOTAL MIGRATION TIME (step "d" above) = 5 hours

You should probably add some buffer time to your estimate to allow for unexpected issues.

SETUP / PRE-MIGRATION

1.  Create the post office directory.

On the new server, create the new post office directory (e.g., po1).  You are only creating the directory that will hold all the subdirectories and files that the migration tool will copy over.

2.  Export / share the post office directory (Linux/Windows only)

Linux

Export the new post office directory that you created in step 1.  An "export" is analogous to "sharing" a folder on a Windows server.  You are making it available so that Reload can "mount" to it (analogous to creating a drive mapping in Windows). 

This is done in the Linux YaST utility:  Network Services | NFS Server | Add Directory:

Directory to Export:  This would be the new post office directory (i.e., /groupwise/po1).

Host Wild Card:  *

Leaving the asterisk is fine - it is a wild card that means all hosts have access to this directory if they mount to it.  This simplifies the process and increases the likelihood of success but decreases security.  To make it more secure, the IP address or hostname of the Reload server could be entered here so only it has access.

Options:  rw,no_root_squash,sync

Windows

Right-click on the post office folder and go through the steps to share it.  As the steps vary depending on the version of Windows (and because this is more commonly known then creating Linux exports), more specific steps are not given here.

User Rights:  Modify, Read & Execute, Write, List Folder Contents, Read

3.  Test the connection.

Mount:  Test the Reload access to the new post office server and directory.   This will require the use of the Linux "mount" command from a command prompt.  See "Troubleshooting Reload Connectivity/Mounting Issues" for instructions on how to mount based on the post office OS.

Create Directory/File:  From the Reload server, change to the mounted directory:  cd /mnt/[mount point you set up under the "mount" procedure].

1.  Create a directory:  mkdir testdir

2.  Delete the directory:  rm -r testdir

3.  Create a file:  touch test

4.  Do a directory listing:  ls -l  (the file "test" should be listed).

5.  Delete the file:  rm test

4.  Install the GroupWise agents.

Run the GroupWise installation program to install the agents.  This can be done after the migration, but we give it as a pre-migration step.

5.  Run the "pre-migration" procedure in the Reload migration tool. 

This should be done days in advance of the migration, especially for large post offices.  It copies the BLOBS (a.k.a., "offiles" or "attachments" directory).  The BLOBS constitute 85 - 90% of the size of the post office.

a. Launch the Reload administration console.

b.  Go to:  Recovery | POST OFFICE PROFILE | [profile] | 2 [MIGRATE]

c.  Press "1" for "Step #1" and press ENTER.

1)  Select the backup.  Typically customers would want to migrate from the most current backup.

2)  Select the server platform for the new post office server. 

NOTE:  This is just for the migration job.  Reload does not update the existing profile (pointing to the existing post office server) with this information.  Updating the profile to the new path is discussed in the "POST MIGRATION" section.

3)  Input the requested information in the following dialogs as they are presented.  As these prompts differ depending on the platform selected, the administrator just needs to read them closely and provide the information.

4)  The pre-migration job begins and the Active Migration Log is presented.

MIGRATION

The pre-migration job must finish before completing the following migration steps.  These steps are done on the day you've set aside for the actual move, typically on a weekend or during other non-production hours.

1.  Warn all post office users to exit GroupWise.

2.  Launch the Reload administration console.

3.  Go to:  Recovery | POST OFFICE PROFILE | [profile] | 2 [MIGRATE].

4.  Press "2" for "Step #2" but do not press ENTER.  This is informational only.  Unload the production post office POA.

5.  Press "3" for "Step #3" and press ENTER.  This launches a back up of your post office.  Proceed to Step #4 when the backup has completed.

6.  Press "4" for "Step #4" and press ENTER.

a)  Select the backup.  Typically customers would want to migrate from the most current backup.

b)  Select the server platform for the new post office server. 

NOTE:  This is just for the migration job.  Reload does not update the existing profile (pointing to the existing post office server) with this information.  Updating the profile to the new path is discussed in the "POST MIGRATION" section.

c)  Input the requested information in the following dialogs as they are presented.  As these prompts are differ depending on the platform selected, the administrator just needs to read them closely and provide the information.

d)  The final migration job begins and the Active Migration Log is presented.

POST MIGRATION

Once the final migration job has completed successfully (check the /opt/beginfinite/reload/logs/[profile].migrate.log), there are some final tasks that need to be completed.

1.  Verify the new post office contents.

Go to the new post office directory and compare its contents to the old post office, especially paying attention to OFUSER and OFMSG.  If those directories are empty, you do NOT want to proceed.

2.  Launch ConsoleOne and update the Post Office and POA objects (if needed).

a)  The post office object's UNC path may need to be updated if it is different on the new server.

b)  If the POA's "TCP/IP Address" setting reflects an IP address rather than a DNS name (not recommended due to disaster recovery reasons), then its IP address needs to be updated.

3.  Edit the A record in DNS for the POA, giving it the new IP address of the server.

4.  Load the POA on the new post office.

5.  Connect the GroupWise client as one of the post office users. 

a)  Verify that items are there and that they can be opened. 

b)  Verify that mail can be sent and received.

6.  Notify users that GroupWise is now available.

7.  Update the Reload profile for the post office, changing its connectivity settings.

a)  Launch the Reload administration console.

b)  Select:  Profiles | POST OFFICE PROFILE | [profile] | Advanced | Connectivity

8.  Re-configure Restore Mode (if necessary).

If your post office moved from Windows or NetWare to SLES, you'll need to re-configure Restore Mode.  Likewise if you did just the opposite, moving from SLES to NetWare or Windows.

9.  Delete the duplicate OFUSER (etc) directories on the new post office server.

If you performed the full migration process more than one time (see the "Planning" section, step 3), then the new post office will have duplicate directories.  Once you've determined it is safe to do so, delete these duplicate directories.  See "Duplicate Directories and Files After Multiple Final (Full) Migration Jobs".

If you have plenty of available disk space on the new server after the migration, this step can be performed on a later day and time.

This article was originally published in the GWAVA knowledgebase as article ID 2154.