How to Migrate a Post Office While In Disaster Recovery Mode (All Steps)

An administrator wants to move (migrate) a post office from one server to another; however, rather than following a standard migration plan, Reload's disaster recovery mode is going to be used in order to free up the post office server days in advance.  The post office server is going to be rebuilt / re-imaged and then the users will be moved back to it.

Or, the post office server crashed, which forced the organization into DR mode and they have to either rebuild the server or move the uses to a new one.  Either way, the users will be on the disaster recovery post office before being migrated.

While the steps are similar to a standard migration (where the users remain on the live post office while the new post office server gets set up), there are some differences.  For example, the standard migration has 4 steps whereas migrating while in disaster recovery has 3.  The order in which things are done vary as well.

Reload has a very powerful yet easy-to-use migration tool.  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 customer is already successfully in Disaster Recovery mode and it is working.  If planning for it, it is recommended to read "How to Set Up Reload Disaster Recovery".
• 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 final 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.  (Optional) Estimate the time it might take to perform the migration and post migration steps.

a)  Run "Step #3" 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 if migrating to a new or re-imaged server.

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 KB article, "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 if this is a new or re-imaged server.

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 if copying to a new or re-imaged server, especially for large post offices; or, if there was heavy email activity and the users were in DR mode for a long period of time.  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.  Since you've been in DR mode, you'll 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.  Give them plenty of advance notice.

2.  Launch the Reload administration console.

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

4.  Press "2" for "Step #2" and press ENTER.  This opens up the "Reload Disaster Recovery POA Configuration Main Menu".

5.  Press "U"  (Unload the Disaster Recovery POA) and press ENTER.

6.  Select "Yes"  and press ENTER to stop the currently running GroupWise POA.  Wait while it unloads it in the background.

7.  Press ENTER again on the confirmation dialogue, "GroupWise POA Stopped".  This takes you back to the "Reload Disaster Recovery POA Configuration Main Menu".

8.  Select "Back" to exit that menu and "Back" again to get to the "Configure Post Office Profile Disaster Recovery Mode" menu.

9.  Select "M" (Migrate) and press ENTER.

10.  Press "3" for "Step #3" and press ENTER.  This starts the final migration wizard.

a)  Select the backup.  Since you've been in DR mode, you'll 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.

10.  Turn off Disaster Recovery (click on the ambulance button from the web interface).

11.  Verify that Reload has properly re-enabled your backup schedules and that the DR POA has unloaded.

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