Moving a Domain

This chapter will help you move any domain from your existing GroupWise server to a new server. As a practical note, we are not actually moving files, we are copyng them. When we refer to “move” in this chapter, we are really addressing the ultimate relocation of services from one server to another. The actual files will remain on your current GroupWise server, and can be deleted after the relocation has occurred and you are happy with the results.

Remember that since we are also upgrading at the same time, you must move/upgrade your primary domain before you move any secondary domains. Before you proceed with the steps in this chapter, please read “Upgrading GroupWise Domains” on page 43. After you have read the section on “The Domain Upgrade Overview” on page 45, return to this chapter to complete the move of your data.

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.

If the post office is on the same server as the domain, you could choose to move it at the same time, or complete the domain move/upgrade first and then return to the post office. We prefer to this one step at a time in a simultaneous move/upgrade, so we will move our domain first, and post offices after the domain upgrade has been completed.

If you have post offices that reside on your existing domain server, those post offices can continue to be accessible after you move the domain. We just need to do some preparation for communications between the post office and the domain prior to the move.

The domain directory is typically so small that we can unload the MTA, copy the data and upgrade quickly enough to see no great benefit in doing a “pre-copy” prior to migration day. Thus, this chapter will concentrate on a single step copy of the domain directory with the agents unloaded to perform our upgrade.

In the previous chapter, we installed the GroupWise Administration Service, that also installed the DBCopy utility. DBCopy is used to migrate the data from the source server to the new Linux or Windows server. If you are moving to Linux from NetWare or Windows, we recommend that you use DBCopy. If you are moving from Linux to Linux, Windows to Windows, or even Linux to Windows, you can use other copy methods if you desire.

If you are migrating from NetWare, during the setup of your Linux server, we requested that you install ncpfs, which allows us to attach to a NetWare server via NCP copy the data. If you are migrating from Windows to Linux, you will use CIFS for attaching the volumes.

The steps we will take are as follows:

  • Attach your new GroupWise Server to your existing GroupWise server.
  • Unload the existing Message Transfer Agent (MTA) for the domain you are moving. We will need exclusive access to the domain database, so no gateways should be loaded.
  • Unload any gateways associated with this domain.
  • Rename the domain directory to avoid any accidental access while we are relocating the domain.
  • Ensure that all file and directory names for the domain are lowercase if you are moving to Linux.
  • Copy the domain directory structure from it’s current location to the new Linux or Windows server using DBCopy.

After these steps, we will proceed to the chapter on “Upgrading GroupWise Domains” on page 43.

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

Change the IP Address of the MTA

Immediately prior to moving your domain, if possible it is a good idea to change the IP address of the MTA to the new location. This will allow the change to propagate to other domains and post offices in your system, and avoid the necessity of repairing post office connectivity after the fact. This is not easily done if your MTA is set to bind exclusively to a specific IP address. You can turn that setting off in most situations to effectuate this change. However, if you run multiple MTAs on the same server, this is not as practical, and you may need to fix the issues after the move. Here are the steps to change for the MTA to ensure a smooth move.

Edit the properties of the MTA object, and change the following:

  • On the Identification screen, change the Platform to the new server OS if necessary.
  • 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.
  • On the Network Address screen, change the IP address of your MTA 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. Uncheck the box that says “Bind Exclusively to this address”. You can always reenable this later.
    1. linuxinstall224.tifChange the MTA IP address and verify settings
  • On the Log Settings tab, remove any custom log locations and leave the logging to the default location (which is blank). Best to make sure the log is also set to verbose!
  • Click OK to save all of the changes.

These changes will be saved for the MTA, and the MTAs will begin to replicate the changes throughout the system. Unless you had the MTA set to “bind exclusive” and there are conflicts by removing that setting, the POAs should receive the changes before communication ceases. Since you have changed the MTA IP address, but the MTA is not actually running at that new location, and thus the POAs and other MTAs will eventually show this MTA as closed once the changes have properly propagated through the system. That is okay. Once moved, that means the other agents will be able to find the MTA at its new home.

Change the Path of the Domain Object

Prior to your copy, you can also change the path of the Domain in ConsoleOne. Edit the properties of the Domain object and change the path there to the path from the perspective of the new server.

  1. linuxinstall223.tifChanging the domain path

Cleaning Up Extraneous Files

Check the log directories and the problem directories to see if there are files that do not need to be moved to the new server. Look to see if there are any non-GroupWise folders under the domain directory that are not required.

If this domain hosts a GWIA, you should check to see that the gwprob directory is not overflowing! Also, check log location for the GWIA to remove any custom log file location defined.

Moving to Linux

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.

Unload the MTA

First of all, go to the server where your MTA is loaded for the domain 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 DomainName

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

rcgrpwise status

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

Also make sure that no administrators are accessing the domain database through ConsoleOne.

Unload Gateways

If this domain also owns a GWIA and/or WebAccess Agent (GroupWise 8 or earlier), these must be loaded prior to moving the domain. The instructions are the same as for the MTA. Press F7 where appropriate to unload the gateways, shut down the services on Windows, or stop the daemons on Linux. Make sure all gateways have been shut down before you proceed.

Rename Your Domain Directory

To avoid any accidental access to the domain during the copy, we recommend you rename your domain directory to something like domain.old. If you are unable to rename the directory, it is likely that something still has the wpdomain.db file open. Double check that all administrators have shut down ConsoleOne, and that the MTA and all gateways have been unloaded.

Copy the Domain Files to New Server

DBcopy

If you will be using DBcopy, after the MTA is unloaded, we will prepare to copy the domain structure to the new server. Let’s look at the current directory structure of our domain. Figure 5-3 shows the domain directory for our domain. On NetWare and Windows most files and directories are in all uppercase (this is also dependent on your GroupWise version and more recent versions create everything lowercase to avoid problems down the road).

  1. FigureL-D5.tiffDomain Directory Structure

All files and directories for the domain and post office on Linux must be lowercase, otherwise the agents will simply not see the “proper” file and will fail to load, or give errors trying to access specific files. Prior to loading the MTA on our new Linux server, we will need to change the case of all files and directories for the domain. We will use DBCopy for this purpose.

DBCopy makes no changes to the original files in the domain directory. If needed, you could simply rename your domain directory back to its original name and load your MTA back up on the source server.

When running dbcopy, 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. After ensuring that you have mounted your NetWare or Linux server properly as outlined in the sections above, run DBCopy to copy your files from the source server to the Linux location like this:

./dbcopy -m -d

so for our situation it might be

./dbcopy -m -d /mnt/gw1/GWDATA/domains/cnc.old /grpwise/domains/cnc

This will copy all needed data from the old domain directory into the directory structure that we’ve indicated for the destination. In our case, we have chosen to locate our domain in /grpwise/domains/cnc.

The -m switch copies the files over in all lower case. The -d switch tells DBCopy that it is migrating a domain. Generally this will not take long at all to perform the copy. Unless you have many files in your existing MTA queues (or old errant folders like long forgotten gwava directories), there is not really much to copy!


NOTE: It’s a good idea to look through your domain directory structure for old log files, files in the problem directories, etc. to clean up prior to copying the directory structure. This will ensure that you don’t needlessly copy unnecessary information to the new server.


Rsync

While you could mount your existing Linux volume into your new Linux server’s file system and also use dbopy for the job, it really is faster and easier to use rsync. Since you are copying from Linux to Linux, we assume that you have no file case issues to contend with! Rsync is very simple to use, and for a domain copy, which only needs one pass, it should be very quick. 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 domain. For example

cd /grpwise/domains

  • run an rsync command to copy the domain folder (in our case cnc) to the new server

rsync -avz -e ssh cnc gwadmin@192.168.110.222:/grpwise/domains

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 “cnc” and the target folder “/grpwise/domains” have no final slash. This is important to ensure that the folders end up where you desire.

Now that your files have been copied to your new server, you can continue with “Upgrading GroupWise Domains” on page 43.

Moving to Windows

Moving your Domain to Windows is not as complicated as moving to Linux, as there are really no issues with case sensitivity. Since we are doing a single pass copy of our domain (i.e., we are taking the MTA down, copying the files and immediately upgrading), there is also no reason to worry about changed files or any other complications. Because of this, there is no particular reason why you need to use dbcopy as the copy mechanism. You can use any copy program you choose. From NetWare to Windows or Windows to Windows you might prefer something like RoboCopy. From Linux to Windows, once your mount point has been created, you could simply use cp -r to copy all files recursively.

The first step in moving your data to your new Windows server is deciding your copy direction. When moving from NetWare, we typically suggest that you map a drive directly from your Windows server to the NetWare server, rather than using a workstation “in the middle”. This does, however, require that your Windows server have the Novell Client for Windows installed. If you choose to use a “middle-man” workstation, the copy times will be greatly increased.

If you are moving from Linux to Windows, we suggest that you start from the Linux server, and create a mount point using CIFS to access the Windows server.

From Windows to Windows, you will of course simply map a drive from one server to another, and it is really your preferences as to whether you begin the copy from the target or the source server. Following are instructions for each of these scenarios.

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

We discussed the idea of using rsync between two Linux servers. There are indeed some rsync equivalents for Windows. We will not get into the details of those here, but if you are familiar with applications such as cwRsync, you could copy your data from your Linux server to Windows by that method.

Unload the MTA

First of all, go to the server where your MTA is loaded for the domain 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 DomainName

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

rcgrpwise status

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

Also make sure that no administrators are accessing the domain database through ConsoleOne.

Unload Gateways

If this domain also owns a GWIA and/or WebAccess Agent, these must be loaded prior to moving the domain. The instructions are the same as for the MTA. Press F7 where appropriate to unload the gateways, shut down the services on Windows, or stop the daemons on Linux. Make sure all gateways have been shut down before you proceed.

Rename Your Domain Directory

To avoid any accidental access to the domain during the copy, we recommend you rename your domain directory to something like domain.old. If you are unable to rename the directory, it is likely that something still has the wpdomain.db file open. Double check that all administrators have shut down ConsoleOne, and that the MTA and all gateways have been unloaded.

Copy the Domain Files to New Server

As mentioned, since this is a domain, and really does not benefit in our situation from using dbcopy, simply copy the files with your preferred copy method. This could be as basic as copying the files from one location to another in Windows Explorer, or executing “cp -r” on the Linux server, copying from the current GroupWise datastore to the new Windows server mount point.


NOTE: It’s a good idea to look through your domain directory structure for old log files, files in the problem directories, etc. to clean up prior to copying the directory structure. This will ensure that you don’t needlessly copy unnecessary information to the new server.


When your copy has finished and your domain files are located on the new server, continue on with the instructions in “Upgrading GroupWise Domains” on page 43.