Trying to get back to work after a great week of vacation in Bend, Oregon, and then surviving the first week of school for my son – now it’s time to get back to work! UW Technology Services, the unit I’m now part of, is in the midst of moving calendaring (and email) systems to a Microsoft Exchange environment. That’s a huge change, and one that has both positive and negative aspects. This will be the first of at least two and probably more posts on the topic – in this one I’ll talk about the background of moving to Exchange, and later I’ll talk about strategies for living with Exchange as a (mostly) Macintosh user.
Here in UW Technology we’ve used Oracle Calendar for our calendaring needs for a bunch of years, starting when it was known as Corporate Time, before Oracle acquired it. While it’s served our needs fairly well, there’s a growing feeling that the product family isn’t fitting into the technology environments we’re moving into – we’re not a big Oracle shop here, and the Collaboration Suite, as it’s currently known, is being tied to other pieces of the Oracle technology architecture. And it doesn’t help matters that Oracle Calendar’s client software, both in the desktop and web versions, is, well, clumsy at best.
We’ve also reached a point where we’re running a fairly sizable Exchange service for departments at the UW that live in a mostly Microsoft environment. That service is working well, and the units that use it seem very satisfied with it. For the large numbers of people who work with mostly Microsoft Office tools on their desktops (Word, Excel, Access), Outlook and Exchange fit right into their work habits. As units have moved to Exchange (or run other calendar systems) it’s become even more difficult to coordinate scheduling at the UW. To paraphrase the old saying, “A person with one calendar knows what meeting to go to, a person with two is never sure.”
We here in UW Technology have long been proponents of ongoing efforts to foster standards for allowing different online calendar products to interoperate for scheduling (we were the first charter member of the CalConnect consortium). It’s encouraging to see the progressive adoption of the CalDAV standards, which have now been implemented by Apple, Google, Mozilla, Zimbra (now owned by Yahoo!), and will be supported in the eternally forthcoming next version of Oracle Calendar, called Beehive. At a base level the CalDAV access protocol allows different calendar clients to interoperate with a given calendar server. The CalDAV Scheduling protocol allows clients to interact with each other independent of what server their calendars are stored in. Sounds promising, right? But you’ll notice one very large player missing from that list. Need a hint? Located in Redmond, initials MS. So despite all the forward progress, and Microsoft’s membership and participation in CalConnect, there still isn’t widespread calendar interoperability. Despite the lack of interoperability (or maybe partially because of it), Exchange now has by far the biggest market share among integrated groupware systems.
Exchange was designed in the early ’90s as Microsoft’s standalone groupware server, and they chose to implement the calendaring features by storing calendar data as specially formatted email messages that their Outlook client knows how to interpret. That means that in order to use Exchange for calendaring you also have to use it for email. I’ve been fairly vocal over the years in my opinion that this is a fundamentally flawed architecture – email and calendaring are different functions, and you ought to be able to separate them in the way they’re implemented and administered. I haven’t changed that opinion. But, for better or worse, architecture doesn’t always carry the day, and there are lots of features that are being added to Exchange (like unified messaging) that are things we know our institution will want to take advantage of. And it’s certainly not difficult to make decisions to implement Microsoft technology (though some of our peer institutions, like Indiana, report that running Exchange is considerably more expensive than running open source messaging systems).
So we’ve decided to bite the bullet and move to Exchange.
In some ways it’s ironic that we’re implementing Exchange at just the time when Macintoshes are becoming far more prevalent, iPhones are proliferating, and cloud-based email solutions are poised to be the next big thing. If I had to make a prediction, I’d guess that this current move to Exchange will last a few years after which we, along with most other institutions and businesses, will use email and calendar hosted by large vendors such as Google or Microsoft. But in the meantime, we’re off into a brave new world. In my next post on the topic, I’ll talk about the various current options (none of the really great) for Macintosh users in an Exchange environment, and some better options coming in the future.
Technorati Tags: calendaring, email, exchange, Microsoft
2 thoughts on “The Move (to Exchange) is on”
Does this mean that the UW’s general use email servers will be moving to Exchange?
If so, what’s wrong with UW-IMAP?
I understand that UW Technology operates a bunch of IMAP servers in order to even out the load. Would Exchange allow for decreasing this number of machines, or would it require more?
Is the number of machines required even an issue?
I guess I have a lot of questions; I was actually discussing this topic with a friend last week.
At this point Exchange is an option for departments, targeted at staff and faculty. It’s not that there’s anything wrong with our IMAP servers for email, but Exchange offers integrated calendaring and email, along with other add-on features like integration with voicemail, that are attractive. Future plans will be based on usage and available options, including options available in the Internet “clould”.
I’m not sure about numbers of boxes per number of users when compared with our UW IMAP servers, but in some ways it’s not a fair comparison because one is a single purpose server (email) and the other servers multiple purposes (which is part of my complaint about the architecture of Exchange). They also run on different platforms – the IMAP servers are run on linux servers, while Exchange runs on Windows. Data from our peer institutions indicate that Exchange is more expensive per account than plain IMAP email.
Hope that helps answer the questions!