[SOLVED] GroupWise 7.0.2 migration

[nrc]

Originally Posted by Rich Graves

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

We haven't encountered this but I doubt that any of our test cases have used the feature. I've asked our GW admin to determine whether we have users using shared address books. Hopefully we can find some test cases. Thanks for the heads up.

Meanwhile, our latest crisis is lack of group calendars. :/

Thank you for the perl script. We were going to have to create that ourselves. I'll check to see how our GW admin intended to identify shared folders. He produced the proxy rights report with a tool called DSrazor which I guess just wraps gwcheck.

[Rich Graves]

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.

[nrc]

What we're missing is the ability to group shared calendars to allow a quick view of a group of calendars. Our call center schedules appointments for students with student services associates. They need to be able to quickly view the calendars for groups of associates according to their specialty. If there are three Computer Science associates they need to see all three of their calendars at once to find an available appointment and then quickly select a different group on the next call.

There's a grouping function discussed in this thread that could form the basis for what we need. Aside from the lack of a client interface it also doesn't do quite what we need. It should enable and disable all of the child folders when you select or deselect the parent folder.

[Rich Graves]

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!

[nrc]

Any updates? Are you able to share how many POs and users you're migrating?

[Rich Graves]

we're a small school. only 1 zimbra, 1 clustered active/passive gw po. 400 users and resources total over next week and a half, 150 users this weekend... including 1 president, 3+ vice presidents, deans, etc. with complex interlocking calendar shares.

rough start. with help of zimbrans in india (highly recommended), determined my strategy of parallelism was wrong. ended up causing lots of errors due to mysql and attachment text extractor/indexer contention. actual best strategy is careful watching of only 2 parallel tasks - each runs faster, giving optimal overall throughput.

daylight savings bug on repeating appointments was *not* fixed in time for us. we hope, but are not certain, that we will be able to zmmailbox ef /Calendar and re-import just calendars. else, we will have to ask dept assistants to correct our VIPs' calendars manually.

[nrc]

Many thanks for sharing your planning and experience so far. It's good to know that someone else is working through the same issues.

We're about 1200 faculty and staff across three POs. We're three weeks out if we don't delay over issues. Our intent was to migrate the majority of our mail prior to the actual cutover and then migrate only the most recent content on the go live weekend. We were hoping that one migration task per post office would avoid problems with running in parallel but it sounds like we'll have to limit ourselves to two.

I'm not sure our users will tolerate either the duplicates or the DST error in their calendars so we'll probably have to talk with Zimbra about when we can expect those to be fixed.

[Rich Graves]

Bug 25709 - Groupwise:Mismatch in Appointment time after migration. is fixed. And zmmailbox ef/re-migrating just calendars works. :-)

No sane IT organization would have gone forward with this migration. But that's why I work at a .edu. And Zimbra has been *crazy* supportive.

[nrc]

Originally Posted by Rich Graves

Bug 25709 - Groupwise:Mismatch in Appointment time after migration. is fixed. And zmmailbox ef/re-migrating just calendars works. :-)

No sane IT organization would have gone forward with this migration. But that's why I work at a .edu. And Zimbra has been *crazy* supportive.

Hmm. All these references to mental illness are not inspiring confidence.

We definitely have some issues to work out here. We'll see what we can get knocked out in the next few weeks.

[Rich Graves]

Things got pretty crazy, but it all came through in the end. Users are satisfied thus far. Heck, I've got time to eat lunch and post here.

We definitely should have started with a smaller batch than 132 accounts (more than a dozen of them > 1GB). A pilot migration of 26 accounts in February (before the DST bug came up) gave me what turned out to be a false sense of confidence. Also, while it fixed a huge number of things over 4.5.10 and 5.0.1, ZCS 5.0.2 seems to have made some convertd attachment indexing behavior (hence migration import speed) worse. Some of the convertd changes are being changed/rolled back for the upcoming 5.0.3.

Next weekend's batch of 100-some accounts, and your experience a few weeks hence, should be much more pleasant.

If you have the means to hire professional services to take the graveyard shift, I *highly* recommend it. It's really nice to be able to let a qualified person whose normal waking hours exactly match your normal sleeping hours take over. I'm really thankful that this isn't the weekend that the undersea cables to India broke.