| When moving domains, you are going to move a domain from one physical UNC location to another. Generally, the move is from one file server to another. This discussion assumes that the domain will be moved from one file server to another, typically of the same server type (NetWare to NetWare, or Windows to Windows). This chapter does not cover moving a domain or post office from NetWare or Windows to Linux. Here is the scenario: The domain to be moved is DOMAINX. DOMAINX is a secondary domain. DOMAINA is the primary domain in this system. The file server where DOMAINX originally resided is called FS1. The file server where DOMAINX will reside is called FS2. The old location of DOMAINX is \\FS1\EMAIL\DOMAIN. The new location of DOMAINX is \\FS2\EMAIL\DOMAIN.
That's the scenario; the next few sections talk about important preparatory steps to take. Connectivity to the Primary Domain One of the biggest concerns when moving a domain is the manner in which the new location for DOMAINX will be communicated to the rest of the system. Suppose that DOMAINX communicates to the rest of the GroupWise system via TCP/IP. The new file server, FS2, will have a different IP address than FS1. This needs to be communicated to the rest of the system before DOMAINX is moved. So the message transfer agent (MTA) object for DOMAINX must be edited, and the network address field should indicate the IP address for FS2. Just as soon as the IP address for DOMAINX's MTA has been changed, the rest of the system expects to communicate with DOMAINX at the new IP address. Any changes made to the IP address for the MTA on DOMAINX should be done with ConsoleOne physically connected to the WPDOMAIN.DB for DOMAINX. If you were to change the IP address for the MTA on DOMAINX while connected to the primary domain, your primary domain MTA would immediately restart but would not be able to communicate the change to DOMAINX's MTA if DOMAINX was not running on the new file server. Communication between DOMAINX and the primary domain is the most important communications link. If the primary domain cannot communicate with DOMAINX in order to get the information about DOMAINX's new MTA IP address, no one is going to get the change. Make sure that DOMAINX can communicate with the primary domain. Connectivity to Post Offices When a domain is moved to a new IP address, its post offices must be informed of the change to the MTA's IP address in order for the post office agent (POA) to be able to communicate with the MTA. Moving a Domain to a New Server The following is a sample task list for moving DOMAINX. The discussion can help you apply these concepts to your own domain moves. Warning If the domain you want to move houses a GroupWise WebAccess gateway, you must delete the GroupWise WebAccess gateway first before moving the domain. A GroupWise WebAccess gateway cannot be moved along with its domain. You must reinstall and reconfigure the GroupWise WebAccess gateway.
DOMAINX is being moved from the file server called FS1 to the file server called FS2. DOMAINX has two post offices that it communicates with via TCP/IP. Another name for TCP/IP connectivity to a POA is MTP connectivity. As a precautionary step, you'll want to sync DOMAINX with the primary domain. Following are the steps for syncing a secondary domain with the primary domain: 1. | In ConsoleOne, connect to WPDOMAIN.DB for the primary domain, highlight DOMAINX, and choose Tools, GroupWise Utilities, System Maintenance.
| 2. | Select Sync Primary with Secondary and then click Run.
Next, you'll want to install the GroupWise agents to FS2 (explained in step 3).
| 3. | Install the GroupWise Agent software:
NetWare/Windows:
Go to the Software Distribution Directory\AGENTS directory and run INSTALL.EXE. Run all the way through the installation.
Linux:
Go to the Software Distribution Directory and run the install script.
Tip When you perform the agent install, you will be prompted to enter the domains or post offices you are installing the agents for. If you do not enter or define any domains or post offices for the agent install, the installation process installs only the agent files. This is exactly what you want in this situation. In the next step, you will be copying the MTA's startup file. When you define the path to domains or post offices during the install routine of the agents, a new startup file is built by the install routine. | 4. | Copy the startup file for the GroupWise MTA from \\FS1\SYS\SYSTEM to \\FS2\SYS\SYSTEM.
| 5. | Edit the MTA startup file in \\FS2\SYS\SYSTEM and make sure that the home switch points to the new domain directory. Also see whether the /log switch is enabled. If it is, make sure that the path indicates a location on FS2.
| 6. | If you intend to load the GroupWise MTA from the AUTOEXEC.NCF file of your NetWare file server, make sure you have a reference to this (for example, a reference within the file to GRPWISE.NCF). Make sure that GRPWISE.NCF loads the GroupWise MTA in conjunction with the startup file you have configured for the MTA.
| 7. | Load ConsoleOne and connect to DOMAINX in the GroupWise system view. This is done by going to Tools, GroupWise System Operations. Select Domain and then select the path to DOMAINX.
Even though you haven't moved the domain, make sure that DOMAINX and the primary domain can communicate. You can use steps 8 through 11 to confirm that this is the case.
| 8. | Edit DOMAINX's MTA, and on the Agent Settings property page increment the Attach Retry option by one second. Usually this setting is 600; set it to 601.
| 9. | Connect to the primary domain in ConsoleOne, edit DOMAINX's MTA, and find out whether the Attach Retry value changed on DOMAINX's MTA object.
Tip The purpose behind incrementing the Attach Retry option specifically is that this value is not held in eDirectory. When you confirm that the change to this setting has actually replicated, you know that GroupWise directory replication is working. Do not proceed to the next step until you confirm that this change has been replicated to the primary domain. Get in and out of the MTA object to verify the change.
Note If you're moving the primary domain, you don't have to worry about whether there is communication with the primary domain, of course. | 10. | In ConsoleOne, connect back to DOMAINX's WPDOMAIN.DB file.
| 11. | Edit DOMAINX's MTA and change the TCP/IP address in the network address option to reflect FS2's IP address (see Figure 21.1).
Figure 21.1. Change the network address on the MTA to reflect the new file server 
It might sound strange to change the IP address of an MTA to reflect the IP address on a server on which the MTA is not running; but don't worry, it will work. The whole idea is that the MTA that is currently running on FS1 will communicate the change in the IP address before the MTA goes down. DOMAINX's MTA will be able to connect with the rest of the MTAs in the system, but they will lose connectivity to DOMAINX's MTA. This condition is just fine. Wait for about five minutes for this information to replicate before going to the next steps.
| 12. | Exit ConsoleOne.
| 13. | Bring down DOMAINX's MTA and any gateways running for DOMAINX.
| 14. | Make sure that no one is accessing WPDOMAIN.DB.
Here is a simple test: Try to rename the WPDOMAIN.DB file to WPDOMAIN.REN and then back to WPDOMAIN.DB. If you can't rename the file, do not proceed until you can. NetWare server administrators can check file/open lock activity on the server monitor program to see which users still have a connection to the domain database. You then know who still has the domain database open. If the connection to the WPDOMAIN.DB happens to be 0, there is a process on the server that is holding the WPDOMAIN.DB file open.
| 15. | Copy the domain directory from the old location to the new location.
Copy the \\FS1\EMAIL\DOMAIN\ directory to \\FS2\EMAIL\DOMAIN using one of the following options (in preferred order):
Use a backup of the domain from FS1 and then restore it to FS2. This is most often the fastest method, and this way you will also make sure once again that your restore procedure works as designed; after all, what's the use of a backup if you never test your restore? Use NCOPY *.* /S /E. (NCOPY is superior to COPY or XCOPY because it performs a server-to-server copy, which is faster.) Use XCOPY *.* /S /E. Use Windows Explorer to copy and paste the directory, and then watch the flying pages!
| 16. | Rename the WPDOMAIN.DB file on FS1 to WPDOMAIN.BAK.
| 17. | Load ConsoleOne. You should get an error stating that the domain database for DOMAINX cannot be found. This is okay.
| 18. | Connect to the now-relocated DOMAINX domain's WPDOMAIN.DB file, and when ConsoleOne asks you for the path to the domain, browse to the domain's new UNC location.
| 19. | Edit DOMAINX's object as shown in Figure 21.2, and change the domain's UNC path to reflect the new path for DOMAINX.
Figure 21.2. Changing the UNC path to reflect the newly moved domain 
| 20. | Edit DOMAINX's MTA. Go to the Log Settings property page. If you have specified a path, make sure that it reflects the UNC path where the domain is located. You should also check the Message Log setting and update this path if you have entered a path here.
| 21. | Bring up the MTA for DOMAINX on FS2.
| 22. | Get the POAs and the MTA talking via TCP/IP.
You might have to restart the POA's MTP threads that service post offices that are in DOMAINX. Although the IP address for the MTA might have been communicated to the POA, the POA might not restart the MTP process to use the new address. The MTP process might show the domain being closed. The GroupWise POA allows you to restart just the MTP threads. This is done through F10, Actions, Restart MTP threads.
After restarting the MTP threads, see whether it shows the new MTA's IP address. To do this, press F10 and choose Message Transfer Status.
If the IP address is incorrect, you need to become a little bit more forceful with the POA. One option is to rebuild the WPHOST.DB file to force the information down to the post office. You can also use the information in the following tip for another resolution to this problem.
Tip If you cannot get your POA to understand that the MTA has a new IP address, or you do not want to rebuild the WPHOST.DB file, you might want to just use the HTTP interface of the POA to edit the IP address and port. This can be done by accessing the POA's HTTP interface. Click the Configuration tab, and then scroll down and click the Message Transfer Protocol link. This will take you to a screen where you can edit the in- and outbound IP address and port on which the POA listens. Edit the IP address you need here, and then make sure you click the Restart MTP option and click Submit. If you do not select the option to restart MTP, the change will not take effect. If you are not using the HTTP interface option to the POA, you can also use the following switches in the POA's startup file to force the POA to cooperate: /MTPINIPADDR-IP address of the POA /MTPINPORT-MTP port of the POA /MTPOUTIPADDR-IP address of the MTA /MTPOUTPORT-IP port of the MTA
For example: /mtpinipaddr-137.65.55.210 /mtpinport-7101 /mtpoutipaddr-137.65.55.213 /mtpoutport-7100
| 23. | If the server is a NetWare server, configure the NetWare server to run more efficiently with the new GroupWise domain by setting the following directories, and the subdirectories off of these directories, for immediate purge of deleted files:
\\FS2\EMAIL\DOMAIN\WPCSIN \\FS2\EMAIL\DOMAIN\WPCSOUT \\FS2\EMAIL\DOMAIN\MSLOCAL \\FS2\EMAIL\DOMAIN\WPGATE\gateway\WPCSIN \\FS2\EMAIL\DOMAIN\WPGATE\gateway\WPCSOUT
| 24. | Finally, you must regraft the domain object. This will ensure that the domain's new UNC path is reflected in eDirectory. To do this, go to the eDirectory browser view (not the GroupWise view) and follow these steps:
Highlight the eDirectory Organizational Unit (OU) that houses DOMAINX.
Select Tools, GroupWise Utilities, GW/eDirectory Association, Graft GroupWise Objects.
Select domains, post offices, and gateways.
Proceed through the grafting wizard, and make sure to graft DOMAINX; you do not need to graft the users associated with DOMAINX.
|
Your domain should now be successfully moved. To test whether it is, make sure that you can connect to the domain in ConsoleOne, and that all other MTAs show this domain as open. You should also make sure that all post offices off of this domain show the domain as open. Final Notes on Moving a Domain The example in the preceding section is not a perfect fit for every situation. For example, some sites have implemented domain name service (DNS) names for their MTAs rather than IP addresses. The DNS name simplifies the IP address change, because the only IP address that needs to change is in the DNS's translation table. Also, if you have a gateway below a domain that needs to be moved, you will need to see that the gateway is configured for new changes to the IP address or the new UNC path for the domain. Consider, for example, a domain with a GWIA. If you are moving the domain that a GWIA is associated with, you have to do the following: 1. | Copy the GWIA's executable code to the new server.
To install the GWIA code to a new server without using the wizard to install a new GWIA, go to the Software Distribution Directory and run the INSTALL.EXE file from the Software Distribution Directory with the /COPYONLY switch. Here's the exact syntax:
SDD UNC PATH\INTERNET\GWIA\install.exe /copyonly
| 2. | Copy the GWIA.CFG file to the new file serverthis file is typically in the SYS:SYSTEM directory on a NetWare serverand then modify the GWIA.CFG file so that it reflects the correct paths to the domain. On a Linux server, the GWIA.CFG file is generally located at the path /opt/novell/groupwise/agents/share.
| 3. | Modify the EXEPATH.CFG file to reflect the new path to the GWIA.CFG file.
The EXEPATH.CFG file is in DOMAIN THAT OWNS THE GWIA\WPGATE\GWIA DIRECTORY.
Note For more information on what's in the GWIA.CFG and EXEPATH.CFG files, see Chapter 10, "Installing and Configuring the GroupWise Internet Agent." | 4. | Edit the GWIA. Go to the Log Settings property page and make sure that the log path does not reflect the old UNC path.
| 5. | Edit the GWIA. Go to the Network Address page, and make sure that the new network address for the GWIA is indicated.
|
|
