TSS Exchange Migration Paths

Gotta install Exchange!

• Hardware Requirements:
  • Five blades - 2 frontends, 2 backends, one development
    • Do we need this many?
• Initial Development
  • Four Optiplex GX260's have been setup as development for Exchange 2k3
• Exchange 2k3 or 2k7?

• Quota currently works by querying either Cyrus or the filesystem (depending on which user) and then adding a reject on the frontends. We want to continue to reject or defer at the frontends (accepting mail you can't deliver and producing backscatter is bad form and has gotten us on blacklists) so we need to find a way to query Exchange for this information reliably.
• Worth noting that calendars count against quotas apparently - I'd imagine they are small, but this is a training/user services issue.

• Exchange has its own vacation functionality - we either need our app to write to it and our current sysetm, or have our non-Exchange users be able to access the Exchange information.

• Both in terms of how to hook forwarding in to Exchange through our existing applications and how Exchange deals with Exchange users who are forwarding their mail (i.e., does calendaring break?)

Oh goody, calendaring does break. Here's one solution. For those too lazy to click it.. basically is using a combination of server-side and client-side rules to create a situation where mail is delivered to Exchange AND forwarded to another account (in their example, their non-Exchange system), but the mail in Exchange is auto-purged. At least, that's what it looks like. Since I'm going to elect to not put my personal mail in Exchange, I'll be a great guinea pig. — Matthew Elson 2007/01/31 07:35

• How to keep virus/spam filtering in and route mail to Exchange in some cases, Cyrus to others, the moon in others.
• How to keep user experience smooth (i.e do we want webmail.wesleyan.edu to go to squirrelmail for some, Outlook's Web Thingy for others?
• Unless we get an imapproxy (like perdition) in place, we're going to have to keep the username.mail.wesleyan.edu structure since some users will be in system A, and some in system B. I'd really rather not do this.

How to switch between the two mail systems for users who may need calendaring but not be on Exchange by default?

• IMAPsync does a decent job, though it looks like right now we have a choice to:
  1. Have it die on emails > 32MB
     • Did not occur in student transfer because no one had an attachment that size, but it seems likely with larger quotas these could unfortunately become more common.
  2. Not die on large emails, but lose internaldate information (important since Outlook uses it in lieu of the Date: field - I mean why use the Date of the email to display the Date of the email)
  3. Fix Mail::IMAPClient to not lose internal date and/or write our own migration tool (IMAP more or less required).
  • Does Exchange let the user Administrator become the user melson? It's how imapsync works currently; otherwise, tis going to be tricky cause we need some way to do this without user intervention.