[SOLVED] GroupWise 7.0.2 migration

[Rich Graves]

See http://www.zimbra.com/forums/adminis...-exorcism.html

I've reduced the breakage by deleting all sub-calendars with zero items. Remaining sub-calendars break lots of things.

[alexkelly]

Rich,
Please forward any of the gwcheck details you have. I asked our Novell admin for the output of gwcheck...and got a csv file that looks nothing like the output in your previous post w/ the perl script.

Thanks,
Alex

[snissen]

Here's how I generated the proxy report:

1. Run a GWCheck Analyze/Fix Databases, Contents (only, no Structure, no fix), User databases (only), Verbose logging ON. It doesn't matter whether you run this from a PC with GWCheck.exe, or from the Post Office using Mailbox/Library Maintenance, but you must know where the multi-MB output file can be found. This may take more than a day to run.

2. Using a command-line text editor, or an interactive editor capable of handling a 200MB file, do a simple string replace: Change every instance of:
Checking user =
to:
Checking access on user =
In other words, you're sticking the keyword "access" into that line.

3. Using a grep-like utility, search for all the lines containing the word "access" in any case, and output them all to a new file. This new file will be about 0.1% the size of that first one.

4. (Optional) Cleanup: Remove any "Checking access on user = " lines that are not followed by any ACCESS_RECORD lines. Remove any invalid duplicate "Access granted for user" lines.

5. For interpretation of the numeric codes, see Novell TID # 10050654 . Never mind the versions of GroupWise listed at the top; the codes are still the same.

[Rich Graves]

The second weekend's batch of 200 accounts was much less stressful. ZCSGroupwiseMigrationWizard-5.0.3_GA_2113.exe addressed most of the issues we've had.

To last weekend's process I added a (cygwin) perl script that automatically parsed and recorded outcomes for individual accounts based on m2l.log, and a server-side zmmailbox script to deal with renaming /Calendar/SubCalendar and to delete some empty nuisance folders like /Documents.

Our final batch of 40-some accounts will be done Wednesday. I'll attach some more scripts to this thread on Thursday or Friday.

[Rich Graves]

There's not a lot here, but some of it is possibly useful to others:

https://apps.carleton.edu/campus/its...dar/gw2zimbra/

[nrc]

We have started training. So far there has not been an uprising but there has been a lot of grumbling about the lack of these features.

Bug 7257 - Support read receipts and delivery reports in webmail
Bug 22014 - Recall message from Outlook/ZWC.
Bug 7524 - Delayed delivery of mail

We're hopeful that we'll win people over the first time they do a search or tag a message but people tend to remember when you're taking a feature away even if everything else is better.

Are you still seeing appointment duplication? We still have it in build 2095 and the bug is showing as still open.

[Rich Graves]

Another in similar vein is "I want to be able to look at Properties to see if someone has read my message." Commonly known around here as "snooping." People mourn and celebrate the loss of the "snooping" feature in equal numbers here.

With the possible exception of delayed delivery, these are all examples of "stupid legacy features of pre-Internet workgroup mail." They only work in an environment disconnected from the Internet where it is only possible to use one particular proprietary email client.

I'm not sure about appointment duplication. The user who noticed it was migrated weeks ago, and we didn't try re-migrating.

We are seeing a fair amount of Bug 17509 - duplicate appointment created, as we deployed Outlook connector 5.0.2 on all desktops (over my objections).

[snissen]

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

[nrc]

I think the bottom line is that there are certain features that business users expect. On some of those features Zimbra has had a bit of a blind spot just as a result of their innovative, non-traditional nature.

For GroupWise shops the ability to snoop on read status is one of them. It's perfectly reasonable for a business to expect transparency on message delivery within their domain. People tend to sour on it when it is used against them. That's a cultural problem in my view.

The message status view in GW is good in concept although I'd be reluctant to say that they've done much of anything right when it comes to calendaring. The good news is that the read receipts and delivery status reports RFE is targeted for 5.5. The key for us is to make sure it is delivered as a full-blown message status view and not just basic Internet delivery and read receipts.

[mmorse]

Originally Posted by nrc

The key for us is to make sure it is delivered as a full-blown message status view and not just basic Internet delivery and read receipts.

Similar to Comment #27 : Bug 7257 - Support read receipts and delivery reports in webmail might want to add this one to your list: Bug 12852 - Track and show status of email
(Someday they'll probably be combined-depends on how much is put in the first pass of read-receipts, but extra votes can't hurt.)