Page 1 of 2 12 LastLast
Results 1 to 10 of 29

Thread: [SOLVED] GroupWise 7.0.2 migration

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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 11:56 AM.

  2. #2
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Jan 2007
    Location
    Minnesota
    Posts
    719
    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
    Join Date
    Nov 2007
    Posts
    23
    Rep Power
    8

    Default

    Re: snooping -- A divergent view here, from a colleague of Rich Graves.

    Let's split this complaint up into its component parts. I believe it's absolutely justified to support delivery receipts; that is, telling the sender whether or not his mail was delivered to the destination mailbox. Given how unreliable Internet mail has been at times, this feature makes sense, and is analogous to asking the US Postal Service to send registered mail.

    As for read receipts (or deletion receipts), I can understand an argument that those violate privacy rights of the recipient. However, is this not an Internet standard in the IMAP protocols? If it's a standard, then it should be supported, regardless of our feelings about it.

    Now let's get practical: It helps work flow to know whether a message you sent was read, deleted, accepted, or declined. If paper mail had the ability to notify you of its read status, that would have been offered by the USPS long ago. Yes, you're learning something about a private action by the recipient: what they did with the message you sent. But this is someone with whom you have a relationship, so the "privacy violation" of knowing what they did with your message, is offset by the benefit of knowing the status of the relationship. I think this is justified as long as it's optional on both ends: the sender has to explicitly request read status for this message, and the recipient has to choose to respond to read status requests (an automatic setting, not an explicit action for every message).

    And the interface that works best is for the sender to return to the original message he sent and look at its status. That's exactly the GroupWise interface, and I think they got it right. The Zimbra (iCal?) approach of sending separate meeting accept/decline notices is very awkward to manage.

    Just my two cents worth... Sande

  9. #9
    Join Date
    Aug 2007
    Location
    outside Philadelphia
    Posts
    214
    Rep Power
    8

    Default GroupWise migration - storage goes up how much?

    Thanks, this is helpful stuff. We'll be trying a GW6.5 migration in the next few weeks - about 110 gig of mailboxes and attachments.

    Once quick question - when you migrate from GroupWise, you lose the SIS (single instance store) or whatever you want to call it - where an email with large attachments to multiple people includes just 1 copy of the attachment with multiple pointers - so of course on migration your storage requirements increase. Were you able to quantify (for your shop) what percentage jump it was?

    thanks,
    greg

  10. #10
    phoenix is offline Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,587
    Rep Power
    58

    Default

    Quote Originally Posted by gnyce View Post
    Once quick question - when you migrate from GroupWise, you lose the SIS (single instance store) or whatever you want to call it - where an email with large attachments to multiple people includes just 1 copy of the attachment with multiple pointers - so of course on migration your storage requirements increase.
    What makes you think that's not the case in Zimbra? Where an email to multiple users has an attachment we only store one copy of that attachment.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

Similar Threads

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