[SOLVED] GroupWise 7.0.2 migration
There have been some changes to this process based on later experience. Be sure to read all 3+ pages of the thread. Most importantly, at least prior to ZCS version 5.0.3, it is important not to attempt more than 2 simultaneous migration threads, because they will overwhelm convertd and cause errors.
We are going to attempt to migrate 100+ GroupWise users, some of them with >1GB mailboxes, the weekend of March 15 (beware!). Source system is GW 7.0.2 on NetWare 6.5, more or less fully patched; destination is ZCS NE 5.0.2 or peraps 5.0.3 if done yet.
Configuration of migration workstations:
- Recent Novell and GroupWise clients
- ConsoleOne with GW snapins, just in case manual intervention is needed
- Firewalled off from the Internet; can only get to GW and Zimbra servers
- Remote Desktop enabled (and VNC for good measure).
- Auto-It 3 (partially automates some GUI tasks)
- cygwin (various utilities)
- *no* antivirus
- JRBUtils from jrbsoftware.com -- automates some GW provisioning tasks that fail to work through the NDS LDAP interface, but are too damn slow under ConsoleOne
- ZCSGroupwiseMigrationWizard-5.0.3_GA_137.exe ZCSGroupwiseMigrationWizard-5.0.3_GA_2113.exe or later (not distributed with ZCS; must contact sales/support, due to potential licensing issues with a shared library)
- Configured for auto-logon to both Windows and NDS
- Automount GW domain directory and another share at login. Execute a DOS batch file upon login, with the meat of the script stored on a share so that we have a single point of control.
1) Set up a split-domain MX configuration that allows you to forward mail to either Zimbra or GW as appropriate. Details are site-dependent.
2) Before migration, run gwcheck. Among the copious output is a report of proxy rights. Later, we will use that report as input to a perl script that outputs zmmailbox commands for folder grants. GW proxy rights do not map one-to-one to Zimbra folder grants, but we can give our users a head start on productivity.
3) Prevent any external access to GroupWise while the migration is running. This is necessary because we have not been able to find a reliable and scriptable way to queue or forward messages on a per-user basis. To prevent users from emailing accounts in the process of being moved, we're taking the whole system down. Effectively taking the system offline also helps with performance and file locking issues.
a) Shut down GW WebAccess and GWIA services.
b) On the workstations to be used for migration, install a later version of the GroupWise client than real users have. Then, using ConsoleOne with the GW7 snapins, under GroupWise System, get Properties on the PostOffice; on the GroupWise tab, under Client Access Settings set the Minimum Client Release Version/Date. We are restarting the PostOffice processes after making this change. We're not sure that the restart is really necessary, but figure it will clear any memory leaks, etc.
4) On each migration workstation:
a) For want of adequate command-line options, an Auto-It script executes zcsgwmigwiz, performs GUI screen-scrape to prefill login information and common options. Script turns over control of the machine to a human, who simply needs to enter a username and click OK. We only do one user per machine at a time, because parallel invocations seem unreliable.
b) If the migration completes with only warnings, with zero errors (this is rare), check off that username as completed and enter another. Upon error, reboot the machine and try again. The wizard is very unreliable on larger mailboxes and often needs repeated invocations; see Bug 23460 - GroupWise: Exception and stall after "Unable to resolve GroupWise Recipients"
5) Once all accounts have either been migrated (or given up), change mail forwarding for the migrated accounts. Mail originally queued for delivery to GW starts flowing into Zimbra.
6) Run the folder grants and create mountpoints script (hack available, in return for useful feedback on this process).
7) For each account, run \progra~1\jrbutils v14\jrb32\gwusers.exe gwpo.gwdomain /e="con,append,migrate.txt" /i=4 /m="01-jan-2008 00:00" which has the effect of hiding the user from the GroupWise system addressbook (GAL equivalent) and causing internally sourced (GW-to-GW) mail to bounce with an "account has expired" error. Users remaining in GW must be instructed to use an alternate form of address for ex-GW users for the remainder of the migration period. This is not a problem for mail coming from the Internet; it will be routed appropriately by split-domain rules. I would prefer to forward mail transparently from GW to Zimbra, but incredibly, there appears to be no reasonable way to set forwards in GW, and we have observed mail getting corrupted while passing through GWIA (this is one of the reasons that we are migrating from GW to Zimbra).
8) Run a bunch of zmprov commands to set fullname and default signature and stuff for each migrated users. The zcsgwmigwiz correctly copies fullname information from GW, but that information was often wrong, so we are resetting it based on ERP information. I'm also taking this opportunity to predefine signatures for everyone based on ERP info. (The new ZCS 5.0 normalized signatures/accounts concept and UI has proven too counterintuitive for our users, but if we predefine a signature, they are able to figure out how to edit it.)
9) Undo the client version restrictions on the GW PostOffice, and restart it.
10) Start GWIA and GW WebAccess.
Script to transfer GW proxy rights to Zimbra shared folders
Hack attached. Might also be a vaguely useful example for people transitioning from other systems, and stuff.
The input file is the output of GWCHECK. If your GW sysadmin can't figure out how to generate this data, I can dig up more details.
In addition to "proxy" rights, recent versions of GW added folder sharing, which works pretty much like Zimbra folder sharing. But we have not figured out any way to get that information out of GW. Anyone else?
Checking access on user = JSchmoe (01c) 758784 bytes, 02/19/08 22:26 (Joseph Schmoe [Joe's OU])
Access granted for user JDoe = 1788
Access granted for user JDoe.firstname.lastname@example.org = 43
518 GENERIC_RECORD check- ACCESS_RECORD
Access granted for user RRoe = 764
Access granted for user RRoe.email@example.com = 42