Page 1 of 3 123 LastLast
Results 1 to 10 of 29

Thread: [SOLVED] GroupWise 7.0.2 migration

  1. #1
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default [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.

    Process:

    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.
    Last edited by Rich Graves; 03-25-2008 at 10:56 AM.

  2. #2
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    Also, we bought advansyscorp.com's Archive2Go. We have instructed users with archives (equivalent of Microsoft Outlook OST's) to run that utility to convert their locally saved mail to a portable format.

  3. #3
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    We considered telling people to unarchive, but

    1) It's a pain. Unless you've found a better way (API?), the user needs to go into each and every folder, select all, go to a menu and uncheck Archive. So this is unlikely to happen with 100% fidelity.

    2) Old mail may have archived for a reason (other than GW's notrious fragility with large mailboxes).

    3) We have Atempo LiveBackup for desktop backups, and it works well, and it's just as cost-effective for us to back up archives that way as on the Zimbra server. (Obviously, if you omit old stuff, DR is faster.)

    4) Old mail is more likely to contain noncompliant garbage that causes Zimbra and/or the migration wizard to choke.

    5) We expect some migration failures. Archive2Go stores a complete copy of both live nad archived mailboxes, giving us a failsafe. Obviously this means more disk space (especially in LiveBackup), but for some business and VIP users, the $2K license cost is good insurance. A more cost-constrained environment (or one with a higher user-to-archive ratio, thanks to Archive2Go's license model) might decide differently.

  4. #4
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    Attached (I think) are the AutoIt3 scripts I'll be using this weekend to help save me some typing. Hope this helps someone (and me, if you notice something I haven't).

    We are getting excellent support right now (do a bugzilla search for things initiated by or Ccing me) and the migration wizards continue to get better, but I don't expect that we'll be able to simply feed a list of usernames to migrate and walk away. There will need to be some babysitting and manual restarts of failed jobs.
    Attached Files Attached Files

  5. #5
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    Eeeeeek!!!

    Yes, we are seeing bug 25709 as well. I'll try to escalate as well, but I think we're going to be stuck migrating some users with known errors... we will encourage them to run Archive2Go as a fallback.

    Bug 25711 may happen because an appointment was created, then changed.

  6. #6
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    Quote Originally Posted by Rich Graves View Post
    Yes, we are seeing bug 25709 as well.
    But only on some users. Most users are actually fine.

    The same limited set of users affected by 25709 also appear to be affected by 25711. I can't immediately find any difference between the sets of users.

  7. #7
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

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

    Code:
     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.gwpo.gwdm@foo.example.com = 43
            518 GENERIC_RECORD check- ACCESS_RECORD
         Access granted for user RRoe = 764
         Access granted for user RRoe.gwpo.gwdm@goo.example.com = 42
    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?
    Attached Files Attached Files

  8. #8
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    nrc, have you run into Bug 25828 - GroupWise: Shared addressbooks get migrated to user's Contacts ?

    The more I look at it, the more worried I get. Picture two users each of whom has aliases or contact groups like "Mom," "Friends," "Advisees," "Family," "Clients," "Prospects." In the GW addressbook, it is clear whose is whose, but when migrated to Zimbra, it's a crapshoot.

  9. #9
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    What do you mean by "lack of group calendars"?

    GW resources will carry over as Zimbra resources. Only caveat is that you have to find them by the OU Browser button, not the Object Picker button.

    If I were in this for the long haul, I'd probably file an RFE for a more command-line-friendly wizard, or at least an option to import a list of DNs rather than search-and-add.

  10. #10
    Rich Graves is offline Outstanding Member
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    717
    Rep Power
    9

    Default

    Looks like we have a variant of Bug 25709 - Groupwise:Mismatch in Appointment time after migration. that's different than originally reported. Reproducibly, appointments for a set date migrate correctly. Reproducibly, recurring appointments migrate 1 hour early.

    Our migration is scheduled to start in 1 hour. So, I did test migrations of every account (restricting to calendar items created in the last month) and figured out which of the accounts have the fewest items:

    for i in `zmprov gaa not.example.com`; do printf "sm $i\ngaf\n"; done | zmmailbox -z | egrep '^mbox .*@not.example.com>.*Path|10 appo .* /Calendar$'|perl -pe 'BEGIN {$/ = " /Calendar\n"}; s/\n//g; s/mbox (.*)\@not.example.com.* ([0-9]+)\s+\/Calendar$/$2 $1\n/'|sort -n|head -60

    ...and I am hoping that when the engineers in India wake up, we'll have a better tool.

    Fun!

Page 1 of 3 123 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Groupwise Migration Problems.
    By SurrealSystems in forum Migration
    Replies: 6
    Last Post: 09-14-2007, 03:13 PM
  2. No mail imported by Groupwise Migration Wizard?
    By SteveNolan in forum Migration
    Replies: 0
    Last Post: 09-13-2007, 10:51 AM
  3. Groupwise migration tool fails with CONNECT_ERROR
    By lustenbe in forum Migration
    Replies: 1
    Last Post: 08-23-2007, 07:59 AM
  4. GroupWise Migration stops on message ten
    By stuartg.orion in forum Migration
    Replies: 2
    Last Post: 06-24-2007, 09:08 PM
  5. My migration from GroupWise - any suggestions?
    By stuartg.orion in forum Migration
    Replies: 3
    Last Post: 06-11-2007, 05:34 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •