Moving GroupWise Post Offices

This chapter assumes in great part that you are moving data from one server to another. We briefly discussed the idea of “Reusing an Existing Data Volume” on page 35, and have no doubt that many sites moving from like OSs will choose to do this. If so, your “migration” will more closely resemble an in-place upgrade than a migration. You will merely need to pay attention to changed file locations, and IP address changes. Skip the portions of this chapter that relate specifically to copying data, and concentrate on the other migration details. If you are moving from NetWare or Windows to SLES, or even Windows to OES, you will of course need to move data, as your existing volumes are not compatible with your new OS. You can technically reuse a NetWare NSS volume on OES, but please take the possible issues we raise in “NSS for OES” on page 31 before you decide to do this.

All GroupWise Post Office servers must have the GroupWise Administration Service loaded. Thus, if this server has not yet been prepared with the Administration Service, go to “Installing the GroupWise Administration Service” on page 25, and return here once that has been accomplished.

For most administrators, moving the post office to a new server is the most unsettling part of a move to a new server. While certainly having an MTA or GWIA or WebAccess down can be frustrating, the thought that something might “go wrong” during a post office move causes some sleepless nights.

We won’t say that there are no dangers in the move to a new server. Frankly, any time you do something as major as changing network operating systems there are difficulties. Learning the new operating system is generally the most work for a Linux move. Most NetWare administrators have at least a general knowledge of Windows networking. Getting everything “just right” is what we’re here to help you do!

Before you proceed with the steps in this chapter, please read “Upgrading GroupWise Post Offices” on page 135. After you have read the section on “Preparing the Post Office Database” on page 137, return to this chapter to complete the move of your data.

You should always look at moving all but the very smallest of post offices as a two stage process. The first stage involves preparing the server and making a first pass copy of the post office data. We are often asked why we do a first pass and second pass of the copy of data from the source server to the new server. It’s simple: time. Unless you can afford to have your post office down for the entire time it takes to copy every file in your post office to the new server, you need to do two passes.

To explain this better, we’ll look at how DBCopy works. DBCopy is optimized to only copy files that are new or have changed since the last run of the utility. When you run DBCopy with only the parameters required to do the job, and no additional switches, DBCopy looks at each file that it is asked to copy and checks to see if there is already a file by that name in the target directory. If the file does not exist in the target directory, DBCopy copies the file. If the filename already exists in the target directory, DBCopy checks the timestamp and only copies the file if the source file is newer. More importantly, DBCopy can successfully copy open GroupWise database files, and ensure a complete backup.

To understand this even better, we will briefly go over how GroupWise stores data. As you know, there are three data directories for a basic GroupWise post office (we aren’t counting document management directories here just yet). There is the ofuser directory, the ofmsg directory, and the offiles directory structure. When GroupWise delivers a piece of mail, a pointer is put into the ofuser directory that contains the header information for the message (sender, recipient, subject, message size, etc.). In theory then, the actual message is placed in the ofmsg database. This is true, of all messages 2KB and smaller. In practice of course, with the increased use of HTML messages, these small messages are becoming fewer and fewer. Any message or attachment that is larger than 2KB is packaged up in a BLOB file (binary large object) and placed in the offiles directory structure. There it sits, totally unchanged, until it is finally deleted and purged by the sender and all recipients and it can finally be removed from the system.

Thus, if you were to look at your GroupWise post office data, you would find that the vast majority (oftentimes over 90%) of the data in your post office is static information in the offiles directories. That information only needs to be copied once to your new server. If that takes 10 hours, 20 hours, even 40 hours, you can sit back and let it happen a few days or weeks before your final move. Then on the actual “migration day” only files that have been created or modified since the first pass will need to be copied. Novell has actually also added an “incremental” switch that allows you to enter a specific date for the copy, or even a relative date (for example, today minus three days) thus avoiding much of the checking against timestamps and file size. So, for example, if you were to make your first copy on March 31, 2014, and on April 7, 2014 you are performing the actual migration, you could put the “-i 03-31-2014” switch to prevent DBCopy from trying to copy files older than your last copy. Notice that we say “older than your last copy” here. You could technically run DBCopy multiple times prior to your final migration. For example, run DBCopy on March 31, 2014, April 4, 2014, then again on April 6, 2014, and on the 7th when it is time for the actual migration, only one day’s worth of data would need to be copied again.

  • Stage One – even though this is called “Stage One”, this stage can be done as many times prior to your actual migration day as you choose.
    • Create a mount point on Linux, or map a drive from Windows to the source server.
    • Perform our first pass DBCopy of our post office.
  • Stage Two – Migration Day
    • Change settings for the POA, Post Office location and External Storage locations if applicable.
    • Unload the POA for the post office
    • Rename the post office directory to avoid any accidental access while we are relocating the post office.
    • Perform our final DBCopy pass.
    • Launch the Administration Console to verify the post office location, agent address and link information if necessary.
    • Perform the upgrade steps.
    • Load the POA for the relocated post office.
    • Verify that the POA is communicating with its domain’s MTA and force the new MTP settings through the HTTP Monitor if necessary.
    • Log into the post office and verify that all prior data is present.
    • Send a message to a user on the same post office, and verify that it is received.
    • Send a message to a user on another post office if applicable and verify that it was received
    • Send a message to an external recipient through your GWIA and verify that it was received.
    • Send a message from an external sender to your user through the GWIA and verify that it was received.

If you have External Storage Locations for GroupWise Document Management, you should also see the section on “Moving External Document Storage Locations” on page 175 for additional tasks that must be done during your migration.

The following sections will be broken out according to the “target” server. If you are moving to Windows, whether that be from NetWare, Linux, or even an existing Windows server, follow the instructions for “Moving to Windows. Likewise, if you are moving your system to Linux, whether from NetWare, Windows or an existing Linux server, following the instructions for “Moving to Windows”.

Moving to Linux

Create a Mount Point for the NetWare Server

If you are moving from NetWare, you need to attach to the NetWare server from your new Linux server. To mount the NetWare volumes into your Linux file system, perform the following steps:

  1. On the new Linux server, open up a terminal window.
  2. su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our NetWare server that is named gw1. It is suggested that you replace gw1 with the actual name of your NetWare server for ease of recognition later.
  4. We have chosen to connect to our NetWare server via ncpfs. To mount the NetWare server via ncpfs, issue the following command

ncpmount -S server -A 123.123.123.123 -U userid -P password /mnt/gw1

replacing your server name for “server” and your server’s IP address for 123.123.123.123. For example

ncpmount -S gw1 -A 192.168.100.200 -U danita.cnc -P password /mnt/gw1

NOTE: You might wonder about the “user.context” vs. “.user.context” in this example. While “.user.context” works on some versions of Linux, it fails on others. In my testing, “user.context” has always worked on all versions. You might keep this in mind if you experience any problems authenticating with ncpmount.

This will actually mount all volumes from the NetWare server to this location. So, if we cd to /mnt/gw1 will will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.

Create a Mount Point for the Windows Server

If you are moving your domain from Windows, you need to attach to the Windows server from your new Linux server. To mount the Windows drives into your Linux file system, perform the following steps:

  1. On the new Linux server, open up a terminal window.
  2. ”su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our Windows server that is named gw1. It is suggested that you replace gw1 with the actual name of your Windows server for ease of recognition later.
  4. We have chosen to connect to our Windows server via cifs. To mount the Windows server via cifs, issue the following command:

mount -t cifs //server/d$ /mnt/name -o username=user,password=password,domain=domain or workgroup

This command is all one line, and there is no space between the comma following password and the word domain. You can use the entire drive (d$) or a specific share name. We like to use the drive (d$) when possible, but the share works as well. If for some reason you have difficulty mounting by by server name, you can substitute the IP address of the Windows server in the //server/d$ portion (i.e. //192.168.100.201/d$).

So, for example, our command would be

mount -t cifs //192.168.100.228/d$ /mnt/gw1 -o username=danita,password=pass,domain=caledonia

Copying from Linux to Linux

When moving from one Linux server to another, there is no real requirement or even advantage to using dbcopy. In fact, we generally recommend rsync over ssh to do the job. This requires no special mount points, or even any specialized setup to accomplish. It does require that the target server has ssh enabled.

Migrating our Post Office – Stage One

Because our post office data store is large, and because we cannot afford to have our e-mail system down for two or three days while we migrate the data, we will make an initial copy of the data while the post office is up and running. Other than some disk I/O increase, our users will not even know we are there!

Stage One can be started quite a long time before the actual migration, but there are a couple of things to keep in mind. The longer in advance you do your first DBCopy, the more “junk” you will have in your offiles directories to try to clean up later. As we noted above when we discussed how DBCopy works, the utility only copies new or newer files to the target location. However, DBCopy does no “reconciliation” of files on the servers. In other words, if you do a first pass copy of your post office on March 31, 2014, and then don’t do your actual migration until April 30, 2014, anything in the offiles structure that has been deleted from the live post office in the meantime will still exist on the Linux server. It would be unwise, therefore, to do a first pass copy before instructing users to clean our their mailboxes and purge their trash! In that case, you would have cleaner databases, but you would still have old files in the offiles directories. There are GWCheck routines that will delete the orphaned offiles, but we prefer to try to avoid weeks worth of deleted files in the offiles directory during a migration.

Once you have your server prepared and ready for your migration, and you are within your reasonable “migration window” for starting your first pass DBCopy run, it’s time to get down to business.

DBCopy First Pass

Decide where you wish to have your post office located on your server (local partition, SAN, etc.) and make sure that your location is ready to receive your data. It is not necessary to have actually created the post office directory on this partition, as the DBCopy utility will create it for you.

In our example, our NetWare volume is mounted at /mnt/gw1/GWDATA/pos/caledoni. Our new location for our data will be in /grpwise/pos/caledoni.

The absolutely most important thing to remember when performing your DBCopy from NetWare or Windows to Linux is the -m switch. This is the “migrate” switch, and it changes the case for all of the data to lowercase. We can’t stress enough how critical this is. We have been involved in migrations where this switch was forgotten. Especially if you plan on doing more than one “first pass” you must be extremely careful. There is nothing more frustrating than having a DBCopy run for 20 hours the first time, all files dutifully converted to lowercase, and then come back for another pass, forgetting the -m switch, and having duplicates of all file names in two different cases! In fact, some of our customers have been so wary of this, that they simply run the Change Case utility that we discussed back in our preparation chapter prior to beginning their migration first pass just to lessen the damage that would be incurred by forgetting the -m switch!

If you have an older version of GroupWise, and your ngwguard.db file on the NetWare or Windows server is not all lowercase, it is advisable to change that prior to starting the DBCopy. You must take down your POA in order to change the case for this file of course. While newer versions of DBCopy should do okay with an uppercase ngwguard.db file, we have seen issues with the -m switch failing, and it’s just better to be safe than sorry!

So, getting down to business, here’s how we will copy our data.

You will find that DBCopy on the Linux server does not run well from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location to run the utility. Run DBCopy to copy your files from the source server to the Linux location like this:

./dbcopy -m -p -f <source> <destination>

so for our situation it would be

./dbcopy -m -p -f /mnt/gw1/GWDATA/pos/caledoni /grpwise/pos/caledoni

This will copy all needed data from the current post office directory into the directory structure that we have indicated for the destination. In our case, we have chosen to location our post office in /grpwise/pos/caledoni. Our post office is named “Caledonia”. While in theory we should be able to have a post office directory of more than 8 characters on Linux, we do not do this for compatibility and consistency sake.

The -m switch copies the files over in all lower case. The -p switch tells DBCopy that it is migrating a post office. The -f switch indicates that this is a “first pass” and omits certain queue directories to prevent coping files waiting to be delivered to the post office. If you are extremely curious and just love watching screens fly by to prove that something is happening (don’t be shy – Danita is just like that herself!), you can also include the -w switch. This writes all of the data to the “window” so that you can see each file as it is copied. If you DO enable this switch though, do not expect to be able to really tell where you are in the copy. DBCopy launches multiple threads (by default 5) to do the copying, and does not seem to always follow any particular order in the directory structure.

Rsync First Pass

When moving from Linux to Linux, you could mount your existing Linux volume into your new Linux server’s file system and also use dbopy for the job. It is actually much faster to use rsync. Since you are copying from Linux to Linux, we assume that you have no file case issues to contend with! In our dbcopy examples above, we started from the target server, and mounted the source servers into our file system. Using rsync, you could actually go either way, but we prefer to start at the source (existing) server. The following command is an example:

  • At the existing GroupWise server, change to the directory above your post office. For example

cd /grpwise/pos

  • run an rsync command to copy the post office folder (in our case caledoni) to the new server

rsync -avz -e ssh caledoni gwadmin@192.168.110.222:/grpwise/pos

this command accomplishes a couple of things. The -a switch is for “archive” which would actually compare the file dates and sizes were you to run this multiple times. The -v switch is for “verbose” so you can see what is happening. The -z switch is for “compress”, which will speed up the process.

We are also using the “-e ssh” switch, which instructs rsync to use ssh as the remote shell for connection.

Notice that both the folder “caledoni” and the target folder “/grpwise/pos” have no final slash. This is important to ensure that the folders end up where you desire.

Go get a cup of coffee. Or dinner. Or watch a movie. Or just go home for the weekend! This can take a long time, and there is almost no way to calculate it for you. The time it takes you to do current backups of your full post office is a start at an estimation. The faster the connection between your new Linux server and the source server the better. Of course, if you are migrating from an ncp server, ncp isn’t necessarily the fastest of protocols out there, but it requires no special configuration on your NetWare server, and is Novell’s recommended way to copy the data from NetWare to Linux. While on some versions of NetWare you could serve up the post office via CIFS, it probably isn’t worth the effort to try to configure this solely for the purpose of this migration. Under no circumstances should you attempt to do any type of NFS mount to your source server. For the vast majority of sites, you will find it easier and safer to just follow the instructions outlined here for using ncpfs for NetWare or cifs for Windows and having the data copy over via DBCopy that way.

Remember that as long as you remember the -m switch for dbcopy, you can run your first pass copies (even with rsync) as many times as you choose between the first pass and migration day.

Linux Migration Day

Today’s the day, and we will complete our migration of the post office to our new server. Users have been alerted that the e-mail system will be unavailable for the duration, and we are ready to proceed. Here are the tasks that we will complete in order to accomplish our migration:

  • In the Administration Console, edit the details of the Post Office Agent and change the IP address to the new GroupWise server.
  • Check additional POA settings prior to migration, including External Storage Locations if appicable.
  • Unload the source server POA for the post office
  • Rename the post office directory to avoid any accidental access while we are relocating the post office.
  • Perform our final DBCopy or rsync pass.
  • Change the ngwnameserver entries in our local DNS if applicable
  • Complete the Upgrade procedures in “Upgrading GroupWise Post Offices” on page 135
  • Verify that the POA is communicating with its domain’s MTA and force the new MTP settings through the HTTP Monitor if necessary.
  • Log into the post office and verify that all prior data is present.
  • Send a message to a user on the same post office, and verify that it is received.
  • Send a message to a user on another post office if applicable and verify that it was received
  • Send a message to an external recipient through your GWIA and verify that it was received.
  • Send a message from an external sender to your user through the GWIA and verify that it was received.

Change the POA IP Address and Other POA Settings

Changing the POA IP Address prior to unloading your POA will allow the MTA to know immediately that the POA has moved when the upgrade procedure begins.

  1. Load the Administration Console as shown in “Accessing the GroupWise Installation Console” on page 36.
  2. Click on Post Office Agents in the Left Column
  3. Find the POA in question and click on the object to open it.
  4. Click on Agent Settings. Here you can change the IP address and IP Ports if necessary.
  5. Check the HTTP settings to verify that the user and password settings were properly changed as discussed in “Enabling the HTTP Monitor for Your Agent” on page 11.
  6. Verify that SOAP is enabled for this Post Office.
  7. Click on the Log Settings tab and remove any custom path that might exist in the Log File Path field.
  8. Turn your log file settings to verbose, if that is not already the setting.

Change the Path of the Post Office Object

Prior to your final copy, you can also change the path of the Post Office in the Administration Console. Edit the Post Office object and change the path there to the path from the perspective of the new server.

Unload the POA

Next, go to the server where your POA is loaded for the post office that you are moving:

  • NetWare: press F7 at the agent console to unload the agent
  • Windows: if the agent is running as an Application, you can also press F7, or use the File Menu and Exit. If the agent is running as a Service, you must stop the agent from the services applet.
  • Linux: use rcgrpwise command. For example:

rcgrpwise stop domain.po

If you are not certain of the name that is defined for your post office in the rcgrpwise script, first run:

rcgrpwise status

This will show you all agents that the rcgrpwise script controls. Find the name for your post office and then issue the stop command for your POA.

Rename the post office directory

Just to be safe, we always rename the post office directory on the source server to ensure that no one (or no utility) can access the post office while we are making our final copy.

Perform our final DBCopy pass.

Our final DBCopy pass will be very similar to the first. The big differences here are that we will use the “interval” switch to limit what work DBCopy must do, and we will alter the source directory to reflect that we have renamed our post office directory.

You will find that DBCopy does not run well on the Linux server from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location on the destination server to run the utility. Run DBCopy to copy your files from the source server to the destination Linux server location like this:

./dbcopy -m -p -i mm-dd-yyyy <source> <destination>

so let’s assume that we did our last DBCopy to the Linux server on April 6, 2014. Our command would be

./dbcopy -m -p -i 04-05-201r /mnt/gw1/GWDATA/pos/caledoni.old /grpwise/pos/caledoni

We always make the -i switch the day before our last copy just to be safe!

If you have ever looked at the help screen for dbcopy, you will know that -f is listed as first pass for the migration, and -s is for the second pass. We are indeed doing a “second” pass here, but we are not using this switch. The -s was originally created for the migration utility. We have found that the final dbcopy is more reliable when we omit this switch, and let dbcopy do a “standard” final copy.

StoreLowerCase on Linux

If all goes well with your DBCopy, a gwcheck with a “storelowercase” option will be issued by the utility at the very end. This tells the ngwguard.db that all files in the GroupWise system are now lowercase. The only time you should ever have to run a gwcheck with a “storelowercase” option yourself if if you do not use DBCopy with an -m and -p switch. We bring this up, because there are still some TIDs floating about that recommend that you DO run a “storelowercase”. While there are instances where you indeed might need to do this manually, it CANNOT BE STRESSED ENOUGH that you should NEVER run a gwcheck with a “storelowercase” while the POA is loaded. Please do not do this.

Rsync Final Pass

If you used rsync to copy your data from your existing Linux server to your new Linux server, you will do a final rsync now to finalize the copy.

Since we have renamed our post office directory the command will need to reflect this change.

  • At the existing GroupWise server, change to the directory above your post office. For example

cd /grpwise/pos

  • run an rsync command to copy the post office folder (in our case caledoni.old) to the new server

rsync -avz -e ssh caledoni.old/ gwadmin@192.168.110.222:/grpwise/pos

this command accomplishes a couple of things. The -a switch is for “archive” which would actually compare the file dates and sizes were you to run this multiple times. The -v switch is for “verbose” so you can see what is happening. The -z switch is for “compress”, which will speed up the process.

We are also using the “-e ssh” switch, which instructs rsync to use ssh as the remote shell for connection.

Notice that unlike our original command, the folder “caledoni.old” now has a final slash, but the /grpwise/pos folder does not. This is important to ensure that the folders end up where you desire.

Moving to Windows

Map a Drive to Your NetWare Server

If you are moving from NetWare to Windows, it is faster and more efficient to copy the files directly from NetWare to the Windows Server. It may be that your login script will automatically map a drive for you from your new Windows server to your NetWare server. Otherwise, map a drive by finding the volume in Windows Explorer, right-clicking the volume, and choosing Map Network Drive. If you choose to use a workstation in the middle, map drives to both the NetWare volume and the Windows Server share.

Map a Drive to Your Windows Server

If you are copying your existing data from one Windows server to another, simply map a drive from one server to another. We suggest mapping from the source server to the target, but you can go either way.

Create a Mount Point for the Windows Server

If you are moving your domain from Linux to Windows, you need to attach to the new Windows server from your existing Linux server. To mount the Windows drives into your Linux file system, perform the following steps:

  1. On the new Linux server, open up a terminal window.
  2. ”su root” to become root for this session.
  3. Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our Windows server that is named gw1. It is suggested that you replace gw1 with the actual name of your Windows server for ease of recognition later.
  4. We have chosen to connect to our Windows server via cifs. To mount the Windows server via cifs, issue the following command:

mount -t cifs //server/d$ /mnt/name -o username=user,password=password,domain=domain or workgroup

This command is all one line, and there is no space between the comma following password and the word domain. You can use the entire drive (d$) or a specific share name. We like to use the drive (d$) when possible, but the share works as well. If for some reason you have difficulty mounting by by server name, you can substitute the IP address of the Windows server in the //server/d$ portion (i.e. //192.168.100.201/d$).

So, for example, our command would be

mount -t cifs //192.168.100.228/d$ /mnt/gw1 -o username=danita,password=pass,domain=caledonia

Migrating our Post Office – Stage One

Moving GroupWise files to Windows is not as complex as moving to Linux, simply because there are no case issues to contend with. Thus, while dbcopy is a tried and true method, it is not entirely necessary. We will show the steps below to explain how to use dbcopy for the migraiton. That said, if you have other copy methods that can skip existing, unchanged files in the final copy, you can feel free to use that method for your post office copy.

Because our post office data store is large, and because we cannot afford to have our e-mail system down for two or three days while we migrate the data, we will make an initial copy of the data while the post office is up and running. Other than some disk I/O increase, our users will not even know we are there!

Stage One can be started quite a long time before the actual migration, but there are a couple of things to keep in mind. The longer in advance you do your first DBCopy, the more “junk” you will have in your offiles directories to try to clean up later. As we noted above when we discussed how DBCopy works, the utility only copies new or newer files to the target location. However, DBCopy does no “reconciliation” of files on the servers. In other words, if you do a first pass copy of your post office on March 31, 2014, and then don’t do your actual migration until April 30, 2014, anything in the offiles structure that has been deleted from the live post office in the meantime will still exist on the new Windows server. It would be unwise, therefore, to do a first pass copy before instructing users to clean our their mailboxes and purge their trash! In that case, you would have cleaner databases, but you would still have old files in the offiles directories. There are GWCheck routines that will delete the orphaned offiles, but we prefer to try to avoid weeks worth of deleted files in the offiles directory during a migration.

Once you have your server prepared and ready for your migration, and you are within your reasonable “migration window” for starting your first pass DBCopy run, it’s time to get down to business.

DBCopy First Pass – Windows Mapped Drive

Decide where you wish to have your post office located on your Windows server (local partition, SAN, etc.) and make sure that your location is ready to receive your data. It is not necessary to have actually created the post office directory on this partition, as the DBCopy utility will create it for you.

In our example, our NetWare volume is mapped as g:/pos/caledoni. Our new location for our data will be in h:/pos/caledoni.

Change to <serverfles>\agents\ and run the following command:

dbcopy.exe /p /f <source> <destination>

so for our situation it would be

dbcopy.exe /p /f g:\pos\caledonia h:\pos\caledoni

This will copy all needed data from the current post office directory into the directory structure that we have indicated for the destination. In our case, we have chosen to location our post office in g:\pos\caledoni. Our post office is named “Caledonia”. While in theory we should be able to have a post office directory of more than 8 characters on Windows, we do not do this for compatibility and consistency sake.

The /p switch tells DBCopy that it is copying a post office. The /f switch indicates that this is a “first pass” and omits certain queue directories to prevent coping files waiting to be delivered to the post office. If you are extremely curious and just love watching screens fly by to prove that something is happening (don’t be shy – Danita is just like that herself!), you can also include the /w switch. This writes all of the data to the “window” so that you can see each file as it is copied. If you DO enable this switch though, do not expect to be able to really tell where you are in the copy. DBCopy launches multiple threads (by default 5) to do the copying, and does not seem to always follow any particular order in the directory structure.

DBCopy First Pass – from Linux to Windows

If you are moving from Linux to Windows, you could have enabled SAMBA and copied from the Windows server with the Mapped Drive option above. If you have decided instead to mount the Windows server into your Linux file system and run dbcopy from Linux, you will follow these instructions.

Decide where you wish to have your post office located on your server (local partition, SAN, etc.) and make sure that your location is ready to receive your data. It is not necessary to have actually created the post office directory on this partition, as the DBCopy utility will create it for you.

In our example, our Windows volume is mounted at /mnt/gw1/pos/caledoni. Our existing GroupWise data is at /grpwise/pos/caledoni.

So, getting down to business, here’s how we will copy our data.

You will find that DBCopy on the Linux server does not run well from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location to run the utility. Run DBCopy to copy your files from the source server to the Linux location like this:

./dbcopy -p -f <source> <destination>

so for our situation it would be

./dbcopy -p -f /grpwise/pos/caledoni /mnt/gw1/pos/caledoni

This will copy all needed data from the current post office directory into the directory structure that we have indicated for the destination.

The -p switch tells DBCopy that it is migrating a post office. The -f switch indicates that this is a “first pass” and omits certain queue directories to prevent coping files waiting to be delivered to the post office. If you are extremely curious and just love watching screens fly by to prove that something is happening (don’t be shy – Danita is just like that herself!), you can also include the -w switch. This writes all of the data to the “window” so that you can see each file as it is copied. If you DO enable this switch though, do not expect to be able to really tell where you are in the copy. DBCopy launches multiple threads (by default 5) to do the copying, and does not seem to always follow any particular order in the directory structure.

Using Other Copy Methods

Since there is no need to worry about case with a GroupWise Windows server, you are free to copy your data by any means you desire. There is just one thing to remember. As we discussed, items in OFFILES that are deleted between the first copies until the final copy remain in the target offiles directories. If you are using copying methods that can compare file structures, you can have this utility delete files in the target that no longer remain in the source. This will also prevent having extraneous files in the queues that might be delivered twice if you are using these methods, unless you explicitly skip copying the queue directories on your initial copies.

Go get a cup of coffee. Or dinner. Or watch a movie. Or just go home for the weekend! This can take a long time, and there is almost no way to calculate it for you. The time it takes you to do current backups of your full post office is a start at an estimation. The faster the connection between your new Linux server and the source server the better. Of course, if you are migrating from an ncp server, ncp isn’t necessarily the fastest of protocols out there, but it requires no special configuration on your NetWare server, and is Novell’s recommended way to copy the data from NetWare to Linux. While on some versions of NetWare you could serve up the post office via CIFS, it probably isn’t worth the effort to try to configure this solely for the purpose of this migration. Under no circumstances should you attempt to do any type of NFS mount to your source server. For the vast majority of sites, you will find it easier and safer to just follow the instructions outlined here for using ncpfs for NetWare or cifs for Windows and having the data copy over via DBCopy that way.

Remember, you can run your first pass copies as many times as you choose between the first pass and migration day.

Windows Migration Day

Today’s the day, and we will complete our migration of the post office to our new server. Users have been alerted that the e-mail system will be unavailable for the duration, and we are ready to proceed. Here are the tasks that we will complete in order to accomplish our migration:

  • In the Administration Console, edit the details of the Post Office Agent and change the IP address to the new GroupWise server.
  • Check additional POA settings prior to migration, including External Storage Locations if applicable.
  • Unload the source server POA for the post office
  • Rename the post office directory to avoid any accidental access while we are relocating the post office.
  • Perform our final DBCopy or rsync pass.
  • Change the ngwnameserver entries in our local DNS if applicable
  • Complete the Upgrade procedures in “Upgrading GroupWise Post Offices” on page 135
  • Verify that the POA is communicating with its domain’s MTA and force the new MTP settings through the HTTP Monitor if necessary.
  • Log into the post office and verify that all prior data is present.
  • Send a message to a user on the same post office, and verify that it is received.
  • Send a message to a user on another post office if applicable and verify that it was received
  • Send a message to an external recipient through your GWIA and verify that it was received.
  • Send a message from an external sender to your user through the GWIA and verify that it was received.

Change the POA IP Address and Other POA Settings

Changing the POA IP Address prior to unloading your POA will allow the MTA to know immediately that the POA has moved when the upgrade procedure begins.

  1. Load the Administration Console as shown in “Accessing the GroupWise Installation Console” on page 36.
  2. Click on Post Office Agents in the Left Column
  3. Find the POA in question and click on the object to open it.
  4. Click on Agent Settings. Here you can change the IP address and IP Ports if necessary.
  5. Check the HTTP settings to verify that the user and password settings were properly changed as discussed in “Enabling the HTTP Monitor for Your Agent” on page 11.

linuxinstall226.tif

  1. Scroll down this screen to verify that SOAP is enabled for this Post Office.

linuxinstall227.tif

  1. Click on the Log Settings tab and remove any custom path that might exist in the Log File Path field.
  2. Turn your log file settings to verbose, if that is not already the setting.

Change the Path of the Post Office Object

Prior to your final copy, you can also change the path of the Post Office in the Administration Console. Edit the Post Office object and change the path there to the path from the perspective of the new server.

  1. linuxinstall225.tifChange the Post Office Path

Unload the POA

Next, go to the server where your POA is loaded for the post office that you are moving:

  • NetWare: press F7 at the agent console to unload the agent
  • Windows: if the agent is running as an Application, you can also press F7, or use the File Menu and Exit. If the agent is running as a Service, you must stop the agent from the services applet.
  • Linux: use rcgrpwise command. For example:

rcgrpwise stop domain.po

If you are not certain of the name that is defined for your post office in the rcgrpwise script, first run:

rcgrpwise status

This will show you all agents that the rcgrpwise script controls. Find the name for your post office and then issue the stop command for your POA.

Rename the post office directory

Just to be safe, we always rename the post office directory on the source server to ensure that no one (or no utility) can access the post office while we are making our final copy.

Perform our final DBCopy pass.

Our final DBCopy pass will be very similar to the first. The big differences here are that we will use the “interval” switch to limit what work DBCopy must do, and we will alter the source directory to reflect that we have renamed our post office directory.

If you have ever looked at the help screen for dbcopy, you will know that -f is listed as first pass for the migration, and -s is for the second pass. We are indeed doing a “second” pass here, but we are not using this switch. The -s was originally created for the migration utility. We have found that the final dbcopy is more reliable when we omit this switch, and let dbcopy do a “standard” final copy.

From Linux

You will find that DBCopy does not run well on the Linux server from any directory other than /opt/novell/groupwise/agents/bin so we will cd to that location on the destination server to run the utility. Run DBCopy to copy your files from the source server to the destination Linux server location like this:

./dbcopy -p -i mm-dd-yyyy <source> <destination>

so let’s assume that we did our last DBCopy to the Linux server on April 6, 2014. Our command would be

./dbcopy -p -i 04-05-2014 /grpwise/pos/caledoni /mnt/gw1/pos/caledoni.old /grpwise/pos/caledoni

We always make the -i switch the day before our last copy just to be safe!

Windows

dbcopy.exe /p /i mm-dd-yyyy <source> <destination>

so let’s assume that we did our last DBCopy to the new Windows server on January 6, 2012. Our command would be

dbcopy.exe /p /i 01-05-2012 f:\pos\caledoni.old g:\pos\caledoni

We always make the /i switch the day before our last copy just to be safe!

Again, this will take some time. It’s difficult to say how long exactly. However, in a recent migration we did, the initial DBCopy of all of the post office files took about 20 hours, and the final DBCopy took two hours.

While this is processing we can continue to do a bit of work that needs completing.

Unless of course you need to move an External Storage Area. In that case, continue on with the next section.

Moving External Document Storage Locations

First Pass

If you use GroupWise Document Management and have external Document Storage Locations defined, these must be moved separately from the main post office move.

The procedure is simple, but it is indeed extra, and must be done individually for each Document Storage Location that you have defined.

First, decide where on your new Windows or Linux server you wish to have the Document Storage Location. Once you have decided on your location, we will do a new DBCopy. This time we will use the -/b (BLOB) switch, which essentially tells the DBCopy utility to not check the ngwguard.db file while it is running and simply copies everything it finds in the source directories.

First we will unload our new Windows POA just to avoid issues. In our situation, the documents are on h:\docs\caledoni. Our documents will reside on the new server on a new volume that has been mapped from our workstation as i:\docs\caledoni. Thus, our DBCopy command would look like this:

dbcopy.exe /b h:\docs\caledoni i:\docs\caledoni.

On Linux, this might be

./dbcopy -b -m /grpwise/docs/caledoni /mnt/gw1/docs/caledoni

Technically, it is not required that we use DBCopy for this process unless we are moving TO Linux, necessitating the -m for migrating to lowercase. You could really use any copy mechanism you like but DBCopy works well for this.

Final Pass

Before you take down the POA for the final copy of both the Post Office files and the External Storage locations, you should edit the Library Storage Locations information and change the path to the new server. This can be done after the upgrade, but it is best to have this change propogate to the Post Office while the Post Office is still on the existing server.

  1. In ConsoleOne, select the Library involved in the storage move.
  2. Click on the drop-down triangle and choose the Storage Area tab of the Library.
  3. Select the Storage Area that you have moved.
  4. Click the Edit button.
  5. Change the path on the Edit the Document Storage Area page to be correct from the perspective of the Post Office Agent. If you are moving to Linux, also include the Linux Path. This is extremely important, as the new Storage Location will not be recognized on Linux if the Linux Path is empty or incorrect.
  6. Select OK. You will probably be prompted to create the directory. Choose “no” since the directories are likely not accessible from this workstation, and have been created during the copy of the Storage Locations to the new server.
  7. Verify the change took effect by clicking on a different item in ConsoleOone and returning to the Library to view the storage area and confirm it has changed.

Additional Migration Tasks to Do While the Final Copy Continues

There are a few steps that need to be accomplished before we are finished with our migration.

Double-Check the Post Office Details in the Admin Console

Although we changed these settings during the procedures above, it’s a good idea to give them one last look:

  1. Load the Administration Console as shown in “Accessing the GroupWise Installation Console” on page 36.
  2. Click on Post Offices in the Left Column
    • Edit the properties of the post office and change the UNC path of the post office to point to the new location.
    • Edit the properties of the POA object, and change the following:
      • On the Identification screen, change the Platform to Linux or Windows
      • Click OK to save all of the changes.

NGWNameserver

If your site is using an ngwnameserver value in DNS to direct users to the POA, you should change this now to point to the new IP address for your POA. This will ensure that users have no disruption of service after the POA comes back up. The DNS server will simply redirect the users to the proper IP address after the migration.

Now we wait. There really isn’t much left to do until the copy is complete!

Once the copy is complete, you can continue on with the next chapter to upgrade your post office.