Friday, June 4, 2010

Migrating from Microsoft Exchange to Google Apps (Part I)

Recently I embarked on upgrading our existing Microsoft Exchange server to Exchange 2010. I was very impressed with many of the new features on 2010, most notably the new Outlook Web App and the high availability features.

The situation here at work is we are a small private college. We have around 120 FTE staff and faculty along with 500+ students. And throw in some emeritus faculty and we have a good sized Exchange installation. As I progressed through the initial design, installation and testing of Exchange 2010 things were going reasonably well. The initial testing revealed that our current version of NOD32 on the clients would delete all HTML e-mail. That was a shock and took some time to determine why e-mail was simply disappearing. Next we had to purchase some additional licensing for Windows Server 2008 R2 and Exchange 2010 to support the design that I had laid out.

Here is what our design looks like: We have a single CAS server running Black Berry Enterprise Server, OWA and hub transport. On the back end, I have two mailbox servers hosting the mailboxes. This will generally improve uptime for our clients and offer superior redundancy with the mailbox databases which is very important.

Things were going well, until I decided to check on CAL's for our students and emeritus faculty. Microsoft said that we must "refresh" our student CAL's for the move to 2010. Not good since budgets are tight.

What to do?

I initially thought that we could host a second solution on site using an open source groupware system. There are many out there that would fit the bill so to speak. Yet, this would increase complexity and we would have additional infrastructure to manage. I wasn't pleased with this solution. I checked into Google Apps for Education. Google offers educational institutions all of the Google apps for free. This seemed like a good fit, but would it meet all of my requirements?

Overall my requirement list is short:
  1. Support single sign-on.
  2. The ability to script account creation and deletion.
  3. Simple back-end management.
  4. Offer a good experience for our students.
Single sign-on, or SSO is critical to a seamless user experience, which is why it is listed first. Also, offering a good user experience is critical as well, but this is a known quantity since many people in the office use GMail, including yours truly.

The other two items on the list, scripting and management are more internal IT tools offering nothing to the customer. Yet, it makes our life simple in the office. Currently all account creation and deletion is handled with scripts that contact our ERP system to enumerate the list of students. I can easily create hundreds of accounts by executing three scripts. Not bad, but I'm working on reducing that down to one. The Google API is key to making this happen.

In the next installment, I'll discuss how I implemented SSO using Google Apps.