Agreed, but the MAPI/CDO client package is available as a free download. It's generally listed as a prerequisite for any application that requires it.

Not that much of an inconvenience, really.

powershell uses UTC with an offset for the locale; however, you can remove the offeset if you wish and retrieve UTC only; you can even apply unix-style formatting if you want.

Powershell is pretty friggin awesome once you scratch the surface...

I think you've muddled the MAPI client and MAPI protocol together, so i'll clarify for you: MAPI as a client access method (ie the MAPI protocol) is built-in, and turned on by default. For Outlook clients who are on the same network as your Mailbox server(s), this is the default connection method. The MAPI client bits, however, are not included in Exchange server anymore. Really the only thing that i've found that this affects is the ability to export mail to a PST when working directly on a mailbox server. It's been replaced by a number of powershell commands (export-mailbox, import-mailbox), and can still be done on workstations with Outlook installed (because the MAPI client bits are part of Outlook).

Exchange isn't an applications platform, and isn't billed as such. It's Groupware, period, full stop.

That's not to say that Exchange 5.5 wasn't billed as an apps platform, but that was 10 years ago. Things change, and your anecdote from 1998 can't possibly be expected to reflect the current state of affairs.

For what it's worth, Exchange can interact with external applications through the use of the Exchange Web Services API, which is a little difficult to grasp at times, but it's well documented on MSDN. We've developed several custom applications around the calendar interface in very short periods of time.

You're both correct, sort of.

Evolution uses Exchange Web Services to gather calendar data, and IMAP for messages.

There is, however, a MAPI add-on available, but the last time i checked it only worked with Exchange 2003. The IMAP+EWS combination works well, and is implemented in other mail applications - for example, the Mail app that comes with OS X.

You really should read up on Exchange Powershell: export-mailbox -identity username -startdate MMDDYYYY -enddate MMDDYYYY -targetfolder foo -targetmailbox username (or if you're daring, you can specify a PST file). and for mailbox sizes:

get-mailboxstatistics -identity username | select identity,totalitemsize

You could even script the two together, to identify mailboxes larger than, say, 1 GB and then export items older than 180 days...

$enddate = (get-date).AddDays(-180)
get-mailboxstatistics -resultsize unlimited | where-object{$_.totalitemsize -gt 1GB} | export-mailbox $_.alias -enddate $enddate -targetmailbox foo -targetfolder bar

Seriously, RTFM.

To further address your concerns about client compatibility...

Instead of using MAPI, which is admittedly a flawed and convoluted protocol, many mail clients are being developed to take advantaged of Exchange Web Services. The Mail app that ships with most versions of OS X uses IMAP to fetch mail from Exchange, and Exchange Web Services to work with the calendar. I believe that Evolution does something similar.

In the future, you'll see these same clients start to use EWS for mail as well. The newest version of Entourage will use EWS exclusively when dealing with Exchange servers (until recently, it used a MAPI implementation).

Who is modding this guy up?

IMAP is enabled on ALL MAILBOXES in Exchange 2007 by default. You just have to configure a few settings and enable the service. You can also disable IMAP globally.

To answer your previous assertion that Thunderbird doesn't work - you're wrong again. Our user base uses Thunderbird extensively. Like many universities, we used to push Eudora, waaaay back before we moved to Exchange 5.5, and a lot of professors liked Eudora enough that they will never use Outlook. Thunderbird is the most suitable replacement for Eudora that we've been able to identify. It works great with or without SSL encryption, using POP or IMAP.

So seriously, you very obviously don't have a clue. Please stop with the misinformation.

Windows clustering allows for Active/Active clusters, so you CAN run the same service on two cluster nodes at the same time (with the exception of Exchange).

Setting up two servers to host VMWare guests and copying is not a good idea either - the HA tools for VMWare are expensive, and totally unneccessary for the proposed deployment. Without these HA tools, he would have to down his primary guest every time he wanted to make a snapshot.

We're talking about a very simple deployment here - HTTP and FTP. You don't even need clustering or a dedicated load balancer - instead, try using round-robin DNS records to do some simple load balancing, and then use a shared storage area as your FTP root (could be a DFS share for Windows or an NFS mount in Linux). This would give you a solid two-server solution that works well for what you're trying to accomplish, and adding servers would be trivial (just deploy more nodes, and add DNS records to the list).

If it grows much larger than 2 nodes, you might consider an inexpensive load-balancer; Barracuda sells one that works well and will detect a downed node.

Clustering for this job is totally unnecessary though. You're wasting your time by looking into it.