Environment
Situation
This document is intended to aid in the manual migration of GroupWise data from legacy NSBS 6.x to NOWS SBE with GroupWise 7.0 or GroupWise 8.0.
Available to administrators is the GroupWise Migration Wizard which may function to some effect, but may not have the functionality to migrate GroupWise to a non-NSS-based file system.
The manual migration performs all the same functions as the Migration Wizard with more granularity and control.
There are some general goals on which the administrator or consultant will need to focus in preparation for the migration.
* This entire procedure is covered in different detail in Section 20.0 Manually Migrating a Post Office and Its POA to Linux of GroupWise 7.0 Documentation. It is also covered in TID - 3407855 Moving a Post Office to Linux.
It is recommended that the administrator performing the procedure be versed in each set of documentation prior to moving forward.
* That the current production system remain in play until the new server is tested to full functionality.
* If the IP address of the production server is NAT'ed to the Internet, then this will require the NAT table to switch over to the NOWS IP.
If this is not the case, and the IP address of the NOWS server is going to be changed, it will require several steps to change-over GW and NOWS IP settings.
The server IP change will not be covered in this document.
Also, an IP change on the server will require that the GroupWise Internet Agent (GWIA) and WebAccess be installed after the IP change.
* That the DBCopy utility be tested and functional in order to make the pre- and per-migration work go smoothly.
This means that DBCopy can be configured to make several passes over the data in order to move most of the GW data in the first pass to test NOWS functionality.
Once the server is functioning satisfactorily, the 'final pass' of DBCopy will copy over the newest data to the NOWS box in preparation for the legacy server to be taken offline.
Resolution
* A new tree will require the creation of new rights associated with users.
* Installation to the old tree will require great care to be taken to prevent cross-talk between the servers.
If the domain database resides on two different servers within the same tree, this might cause ongoing problems with both management and functionality.
* Once noted, ensure that the server functions in other aspects with communicability.
* Check the status of GroupWise by typing the following command at a terminal prompt:
rcgrpwise status
Note the agents installed and that they should read as running. One or more may show as unused. Ignore this for the time being as it does not hamper the functionality of the agent, at least in this instance.
* Delete the new GroupWise system from the server by removing the packages and deleting the installed directory structures for the Domain and Post Office.
Sample Commands -
./etc/init.d/rcgrpwise stop
rpm -e novell-groupwise-gwmta (For the Message Transfer Agent)
rpm -e novell-groupwise-gwpoa (For the Post Office Agent)
rpm -e novell-groupwise-webaccess (For WebAccess Application)
rpm -e novell-groupwise-gwinter (For WebAccess Agent)
* Once these have been removed, check the status of GroupWise again by using the rcgrpwise status command at a terminal.
If nothing is shown, please type the following command at the terminal to see if any 'gw' function is still running.
ps -eaf | grep gw
If anything 'gw'-related is running, kill this process by noting the 'PID' (process ID) and using the command
kill -9 <pidnumber>
Use the grep function again to see if any 'gw' process is running.
Once this is clean, move on. If any process reads as defunct the only way to remove its presence is to reboot the server.
This does not need to be done for the purposes of the uninstall, however.
* Note that ConsoleOne has been installed. Ensure that it remains installed and that it functions properly.
Note also that the GroupWise snapins should be installed.
* The main gist here is to learn to use the copy utility in its function from either Windows or NetWare (or an earlier version of Linux) to copy to NOWS.
The basic commands can be 'batched' and may also be used in multiple passes.
* The function is to copy the 'upper case' directory structure and files over to a 'lower case' operating system (Linux).
EXAMPLE (as per the documentation)
./dbcopy -m -f /post_office_directory /destination_directory
Note that the GW 7 Documentation covers how to create a mount point on NOWS so as to be able to copy from NetWare/Windows to Linux.
* Keep in mind that the copy passes may run during production and should not greatly affect the users' ability to use the system.
Once the 'final pass' is ready to be performed prior to taking the NOWS server online, the old production system should probably be down so as to help ensure the best possible access to the files that may be copied.
4. Use ConsoleOne to connect to the copied domain and then graft the Domain and Post Office into the system.
* NOTE: If NOWS resides in a new tree, the graft is required. If NOWS resides in the same tree, the graft is not recommended outright.
Please see TID - 10084509 How to Graft GroupWise Objects for more details on the specific steps.
* NOTE: If the install requires that the schema be re-extended in order to graft, re-install the GW Administration piece which should extend the schema again.
See Section 3.2 Planning Your Basic GroupWise System in the GW 7 Documentation for information on how this works.
* The basic steps to use ConsoleOne include:
Connect to Domain
Graft Domain and PO
Change IP Addresses and other Properties
Rebuild Databases
Graft in Users and other Objects
* If NOWS resides in the same tree, it is recommended that the NOWS box be 'unplugged' from the network prior to changing the properties of the Domain and Post Office.
This will minimize the chance of 'cross-talk' where the two domains speak with each other across the network and become confused about their location and IP.
Any time the NOWS box is to have connectivity, the GW agents residing on the box should be inactive.
5. Use the standalone GWCheck utility to run the storelowercase function against the Post Office directory structure.
* This function will change the case of object names within databases such as ngwguard.db (Guardian Database) underneath the Post Office directory structure.
For information on how to perform this procedure, please see TID - 3407855 Moving a Post Office to Linux STEP 11.
* NOTE: The warning not to use GW 7.0 Shipping Code is still in effect. NOWS SBE uses a later version of GroupWise past 7.0.2; thus the storelowercase switch works well.
6. Use ConsoleOne to delete the GWIA object underneath GroupWise. ( If NOWS is in the same tree, do not perform this step until the migration is nearly complete)
* NOTE: To completely uninstall WebAccess prior to full migration, the eDir counterparts also have to be deleted.
Thus is it not recommended to perform this function fully until the NOWS box is ready to be launched into production.
* If NOWS, though, is in a new tree, connect to the domain and delete the GWIA and WebAccess objects in ConsoleOne both on the GroupWise and eDir sides.
GWIA will not have a standalone eDir counterpart. WebAccess will have four objects (two 'spellers' and two 'providers') that will need to be deleted.
* NOTE: Ensure that the following are present in the install files. (The NOWS box will allow the administrator to use the present install files to do this procedure.)
If the administrator wishes to use the latest version of GroupWise to install to NOWS, this will need to be downloaded from download.novell.com.
Required Files
Any directory structure that is to be designated as the Software Distribution Directory (SDD) will need to have the following files located within it to be considered as such by the install.
'domain' directory - wpdomain.dc, wphost.dc, gwdom.dc, gwpo.dc
'po' directory - wphost.dc, gwpo.dc, ngwguard.dc
If all these files are not present, the install script will consider the directory structure unsuitable as a Software Distribution Directory structure.
* GWMTA - Install the message transfer agent package against the copied domain.
* GWPOA - Install the post office agent package against the copied post office.
* GWIA - Pending the status of the rest of the system (new tree vs. same tree scenario) install the internet agent and configure it against the domain structure.
* GWWA - Pending the status of the rest of the system (IBID) install the webaccess application and agent against the domain structure and Apache.
NOTE: GroupWise WebAccess 7.x requires a modified setup against SLES10 systems. (Please see TID - 3659157 Installing WebAccess Application on OES2/SLES10SP1+OES2 Add-on)
* If other agents such as GWMonitor, TSAFSGW, or GWMessenger are required, please install these agents at the convenience of all involved parties. Their installation and configuration will not be covered in this document.
* Given the new versus old tree scenario, if only the MTA and POA are running, test their functionality and connectivity.
9. Once the NOWS server is functioning satisfactorily, perform the final migration steps and shut down the legacy production box.
* Ensure that GroupWise is not running on the production box.
* DBCopy the final pass to NOWS.
* Shut down the old production box.
* Bring up the NOWS box as production.
10. If NOWS is in the same tree ...
* Once GW is shut down on the legacy server, install GWIA and WebAccess as per the above instructions, remembering to delete the old objects.
* Ensure that the IP addresses are correct again. If needed, rebuild the databases on the NOWS server using ConsoleOne after changing their properties.
11. If NOWS is in a separate tree ...
* This would usually require a separate IP and thus the NAT table from the firewall will need to point to the new NOWS internal IP.
Once this is complete, nothing else needs be done other than to ensure that the users are aware of the new IP address.
Usually, this will require an install of the new client on all the workstations and a test for functionality to the new IP address.
If this is not possible, use ngwnameserver. The client will query the main DNS entry in its IP configuration for ngwnameserver by default if it is not aware where to reach its POA.
If it finds a DNS entry for ngwnameserver as the POA's new IP, it will route properly. See Section 36.2.2 Simplifying Client/Server Access with a GroupWise Name Server in documentation.
Additional Information
TROUBLESHOOTING PROBLEMS
Some of the most common issues associated with a migration of this nature are as follows, along with some suggestions for troubleshooting.
Please note that these are common issues and common troubleshooting steps and are not meant to be an all-encompassing guide for resolving issues associated with this type of procedure.
This error denotes a mismatch or lack of presence for the user in the Guardian Database (ngwguard.db). The storelowercase option of GWCheck usually pre-empts this.
If the gwcheck has not worked properly in all instances, the easiest way to resolve the issue is to 'Drop the User from the Guardian Database'.
Please see TID - 10062697 How to drop a user or message or other database from the guard.
b. Files missing from OFFILES
It is wise to note the size of the OFFILES directory structure prior to the migration and to compare the same after the first DBCopy.
If large portions of the directory structure or size are missing, it may indicate file or volume corruption on the legacy server.
At that time, it is recommended that a full backup is taken and that heavy GW and file system maintenance be run on the legacy GroupWise volume structure.
c. ConsoleOne fails to install on NOWS Linux
There are several TID's associated with this, the most common of which is a Cool Solution that suggests editing the ConsoleOne install script to mimic the version of eDirectory on the server.
Usually, though, in the instance of NOWS, ConsoleOne installs automatically.
d. GroupWise/Hylafax Integration
At the time of the writing of this TID, there were no supported methodologies to integrate and use GroupWise and Hylafax (NOWS package) in conjunction with each other.
Hylafax has a client which can be installed at a user's workstation which functions to send/receive facsimiles using the package.
When a database is moved or newly installed, it usually is going to be upgraded, especially with a move to NOWS.
The databases must come into contact with each other and be 'open' in order for the Post Office (and domain) to be fully successfully upgraded/changed.
If the database version reads 5.5 or the old version from the legacy server, even after the agents are running, ensure that the two are communicating.
If they are, run a database 'recovery' from the agent screen. Under normal circumstances, the recovery will automatically occur.
The recovery may be run from the web console for the MTA under the Configuration page at the Admin Task Processing link. Check the Perform DB Recovery box.
If performing these procedures does not upgrade the database version, then stop the agents, rebuild the database and then restart, ensuring that the agents are open to each other and communicating.
