Moving a GroupWise Post Office – Windows

Wikis > Caledonia Private Wiki > Moving GroupWise > Moving GroupWise to or on Windows > Moving a GroupWise Post Office – Windows
For most administrators, moving the post office from one location to another is unsettling.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.

You should always look at moving all but the very smallest of post offices as a two stage process. The first stage involves 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.

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 message 4KB 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 4KB is package up in a BLOB file (binary large object) and placed in the offiles directory structure. And 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. And 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 “moving 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, thus even avoiding much of the checking against timestamps and file size. So, for example, if you were to make your first copy on August 30, 2009, and on September 5, 2009 you are doing the actual move, you could put the “/i 08-30-2009” switch to prevent DBCopy from trying to copy files older than your last copy. And notice that we say “older than your last copy” here. You could technically run DBCopy multiple times prior to your final move. For example, run DBCopy on August 30, 2009, then again on September 2, 2009, September 4, 2009, and on the 5th when it is time for the actual move, only one day’s worth of data would need to be copied again.

Before we begin the actual moving tasks, make sure that you have accomplished all of the tasks in the chapter on “Preparing your New Windows Server”. That will have assisted you in installing the GroupWise Agents and DBCopy on your server. So now we can get down to business.

In this section, we are moving a post office that does not use Document Management external storage locations to a new Windows server. If you use document management and store all of your documents in the post office structure, you can follow these instructions in their entirety. If you have external document storage locations, then we will need to deal with them separately. Please see the section below on “Moving External Document Storage Locations” before you proceed. If you are not moving external document storage locations, continue on with this chapter.

DBCopy is available as a Windows application. You can find the DBCopy Windows application in the /admin/utility directory structure of your GroupWise software distribution. You will need to attach to both the source and the destination server from your Windows workstation to run DBCopy.

The steps we will take are as follows:

  • Stage One – Stage “One” can be done as many times prior to your actual moving day as you choose.
    • Perform our first pass DBCopy of our post office.
    • Install the POA on the new server and test a connection to see that the data is copying properly.
  • Stage Two – Moving Day
    • 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.
    • Load ConsoleOne and edit the post office location, agent address and link information if necessary.
    • Load the POA for the relocated post office.
    • 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.
    • Verify that the POA is communicating with its domain’s MTA and force the new MTP settings through the HTTP Monitor if necessary.
    • 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.


Copying our Post Office – Stage One

Because our post office data store is large, and because we cannot afford to have our email system down for two or three days while we move 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 move, 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 September 1, 2009, and then don’t do your actual move until September 30, 2009, 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. And we all know (at least those of us who have been around for any time at all know!) how difficult it is to get rid of old orphaned files in the offiles directories. Thus, it is best to try to have your users clean up before you do your first pass with DBCopy.

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


Performing Our First Pass DBCopy of the Post Office.

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

In our example, our current Windows volume is mapped to f: at f:\pos\cal2. Our new location for our data will be in d:\pos\cal2.

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

From a command prompt on your Windows workstation, change to the location where you can copied the DBCopy directory. Run the command as follows:

dbcopy.exe /p <source> <destination>

so for our situation it would be

dbcopy.exe /p f:\pos\cal2 e:\pos\cal2

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 copying a 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.

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 workstation and connection between the workstation and the two servers, the better. Once your first copy has completed, you can install and configure the POA and test the first copy.

Installing the GroupWise Agents, and Configuring the POA on Your New Windows Server

To install the software for your agent, you can use your GroupWise CD, Software Distribution Directory, or simply download new software from the Novell downloads site (

In the root of the location of your GroupWise software, you will see the setup.exe program that will be used for this installation. Our installation here is using GroupWise 8.0. Your agent installation may vary slightly. When you run this program, you see the Window in Figure 7-1.

    1. install1.tiffThe main installation screen

  • Click on Install GroupWise System.
  • Click Yes on the next screen to accept the license agreement.
    1. Click Next on the next screen to do a standard install. You will see the window in Figure 7-2.
    2. Install GroupWise AgentsFigureN2.tiff


  • “Install Individual Components”.
  • Choose GroupWise Agents as an option to install.
  • At the next screen you will be prompted if you wish to install on NetWare or Windows. Of course we will choose Windows here.
  • The next screen will give you the option of where to install your files on your Windows server, and options for the installation.
    • Install and configure SNMP for GroupWise Agents: If SNMP is available and installed on your Windows server, you can configure your agents here for SNMP.
    • Install as Windows services: Most Windows sites will configure GroupWise agents as services. Otherwise the server would need to remain logged in in order for the agents to run.
    1. After you choose the options on this screen you will click next and be presented with the window in Figure 7-3.
      1. configure1.tiffConfiguring the GroupWise Agents

While we are looking at this screen, we should explain its usage so that it’s more easily understood the next time you encounter it. There are a few misconceptions about what is done here, and what you need to put in this location, so we will try to clear those up.

First, this screen is a template for creating new agent startup files (for example the caledoni.poa file), and for configuring your grpwise.ncf file. Let’s take the example of our groupwise system. Our domain is called CNC. If we want to create a new startup file for the Caledonia POA, and place it in our grpwise.ncf (provided that we checked the option above to “Launch the GroupWise agents on system startup”), we would click the Add button as shown in Figure 7-3 and enter the information for our post office.

  1. Adding a post ofice for configurationFigureN7.tiff

By entering this information, we are instructing the installation routine to create us a startup file called caledoni.poa with a /home switch of “d:\pos\caledoni and create Windows services or icons for the post office agent.

The installation does not validate the “name” you put here and indeed, you can name things here anything you like. For example, rather than naming my startup file “caledoni.poa” as shown above, I could just as easily type “cal” in the name field, and the name of the file would instead be cal.poa. If you put in a name that has more than eight characters (for example Caledonia), the file name will be truncated to eight characters.

  1. Next you will be presented with a summary screen showing your choices for the install, and the installation will proceed.
  2. When the installation has completed, choose to launch your agent now. We can log in to the POA via IP address and just verify that the first copy worked as expected. To do so, run grpwise.exe with the /@u-? switch. This will allow you to change the IP address for the POA to log in and check.

For example:

  1. Figurel-p3.tiffThe GroupWise Startup Screen

Then you can see whether or not the mail looks the same as on the live server at the time of the copy.

  1. Figurel-p4.tiffLogged in to the copied post office


Once you are satisfied that your initial copy was successful and that you can access your post office with the new startup switch, exit GroupWise and stop the POA in the Services applet.

It is best to try to avoid restarting this server between now and moving day. It would not be a critical problem, except of course that we have configured the server at this point to automatically load the POA on startup. This should not pose any great problems if it were to load unattended, but it would be best to not have to worry about the POA running when it comes time to do our final copy.

As mentioned earlier, you can do a “first run” copy any time you choose between now and the final moving day. It’s usually not that important to do though, unless you want to incrementally reduce the amount of time the copy takes on the final day.

Moving our Post Office to Windows – Moving Day

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

  • Unload the source server POA for the post office
  • Rename the domain post office directory to avoid any accidental access while we are relocating the post office.
  • Perform our final DBCopy pass.
  • Load ConsoleOne and edit the post office location, agent address and link information if necessary.
  • Load the POA for the relocated post office.
  • Change the ngwnameserver entries in our local DNS if applicable
  • 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.
  • Verify that the POA is communicating with its domain’s MTA and force the new MTP settings through the HTTP Monitor if necessary.
  • 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.


It seems like a lot of work, but some of it can be done while the post office is doing its final copy.


Unload the POA

First of all, go to the source server where your POA is loaded for the domain that you are moving, and press F7 at the agent console to unload the agent on NetWare. On 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. If your POA is running on Linux, you can stop it with the rcgrpwise command. Typically you would type:

rcgrpwise stop POName.DomainName

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 POA and then issue the stop command for your POA.

At this point we will also make sure that the POA that we configured above on our destination server did not get left loaded, or in the case of a server reboot, get loaded again before we continue. Go to the new Windows server and verify that the POA is not loaded. If it is, stop it from the Services applet.

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 /i 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.

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 September 3, 2009. Our command would be

dbcopy.exe /p /i 09-02-2009 f:\pos\caledoni d:\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 move 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.

Additional Move Tasks to Do While the Final Copy Continues

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

Edit the Details of the Post Office in ConsoleOne

Load ConsoleOne and if possible connect to the domain that owns this post office. While the changes could be done from any domain location, being connected to the domain that owns the post office aids in getting the changes propagated more efficiently.

  • 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 Windows
    • On the Agent Settings screen (click the triangle on the GroupWise tab to change to this screen), notice the HTTP Monitor settings. If you have never enabled the HTTP monitors for your agents, you will need to decide on a good userid and password for the HTTP monitors. Please note that this is neither an eDirectory user nor a GroupWise user. This is an entirely made up user and password solely for the use of the HTTP monitors. If all administrators in your organization will have rights to use the HTTP monitors, then it is a good idea to have the same userid and password for all agents. If you need to limit rights to some agents to various groups, set up a userid and password for each group of agents that will be monitored. Enter the userid and password that you have decided on here in this screen. We may need the HTTP monitor later to fix the communication between our POA and MTA.
    • On the Network Address screen, change the IP address of your POA to reflect the IP address of the new server. Make sure that a valid port number is listed in the HTTP Monitor field, and note what that port is.
    • On the Log Settings tab, remove any custom log locations and leave the logging to the default location
    • Click OK to save all of the changes.



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 move.


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

Additional Move Tasks to Do After the Final Copy is Complete

Loading the POA

Once the copy has completed, it’s time to load up the POA and see if everything is working. We verified earlier that the POA loads properly, so just run

load grpwise.ncf


Checking the MTP Link

Frequently when moving a post office, the message transfer link between the MTA and the POA is broken. For those of you who have never used the HTTP monitors for the agents before, this will be a really good example of “learning to love the HTTP monitor”. Because even though it’s something you have to get used to do since we are not loading the GUI Consoles for our agents except in testing situations, the solution that we will show now is not available in any of the GUI Consoles! So the HTTP monitor wins our love and devotion in one simple command.

The first thing we are going to do is log into our POA’s HTTP monitor. Using your favorite browser (we prefer Firefox, but Internet Explorer works as well), go to the IP address and port of your POA’s HTTP monitor. Our location is – and unless you changed the default port for your POA, you will also go to 7181. When we enter this address, we are first asked for a userid and password. This is the userid and password we assigned to the HTTP above.

After authenticating, we are presented with the following screen:


At this point we want to click on the link for MTP Status, and we will see this screen:


You will notice that the Receive Status shows as Closed, and that the Inbound TCP/IP address shows our old IP address. This is due to the simple fact that our POA doesn’t know that it has moved! This is easily rectified. Simply click on the Closed link under the word Received, change the IP address to the current IP address of the POA on Windows, click the Start MTP Receive radio button, and click Submit. Now click the MTP Status link again and you will see that the Receive thread shows Open. Your MTA and POA are talking to each other again, and mail can begin flowing.

Log into the POA on the New Windows Server

It’s now time to log into your new POA and verify that everything is working as desired. If you use the ngwnameserver listing as described above, your GroupWise client will initially try to go to the old server, timeout and then ask for the new entry in DNS. If you do not use ngwnameserver, you will likely need to enter the new IP address manually when the login times out.

Once you have logged into your mailbox, there are a few tasks that you should perform to ensure that everything is working properly

  • Send a message to yourself. This should pop into your mailbox almost immediately.
  • 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 use GroupWise Document Management and your documents are all stored under the Post Office directory structure, open an existing document and verify that you are able to access it properly.
  • Create a new document in GroupWise DMS and verify that it creates and saves properly.


Once all of these tasks are performed successfully, you are DONE. Well, that is unless you have external document storage locations. If you have external document storage locations there is still a little work to be done. Let’s move on to that task.



Moving External Document Storage Locations

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 server you wish to have the Document Storage Location. You could technically leave the storage locations where they are and have your new Windows server access it from the POA, but it is really much better to have the documents on the same server as the POA.

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.


Technically, it is not required that we use DBCopy for this process. You could really use any copy mechanism you like but DBCopy works well for this.


Once our documents have been copied over to the new server, we will load ConsoleOne and do some magic.


  1. In ConsoleOne, select the Library involved in the storage move.
  2. Right click and select Properties.
  3. Select the Storage Area page of the Library.
  4. Select the Storage Area that you have moved.
  5. Click the Edit button.
  6. Change the UNC path on the Edit the Document Storage Area page.
  7. Select OK.
  8. Select Apply.
  9. Select OK, to close the Library Properties window.
  10. Verify the change took effect. Close ConsoleOne, then load ConsoleOne again and view the properties of the Library and its Storage Area.
  11. Load the POA manually, with the following switches:
    • /ll-verbose – logging switch which sets the log level to verbose to enable you to better track the configuration changes (if your POA is already set to verbose logging, you can skip this switch)
    • /noconfig – this switch will prevent the POA from reading its own configuration file. Instead it will load with “defaults” and simply receive information from the MTA about the change.


  1. Let the POA run like this for a few minutes until you see that the configuration settings have propagated.
  2. Unload the POA and reload it with its regular startup file.
  3. Test the new storage area by opening a document in the library. Close the document, and look at the activity log for the document. To view the activity log go the Properties of the document, select the Activity Log tab. From here you can see the Filename column which will display the exact path to where the document is stored in your GroupWise library. If you do not see the Filename column, simply right click on the column heading and click the word Filename when it appears. This will add this column to the view. You should now see that the document is showing located in the new volume.

Finally, create a new document in the library, then view its activity log to verify it was saved into the new storage area.