We’ve already talked about migrating to and from both Dovecot and Google Apps for Business without having to reset the users’ passwords. In this post we’ll talk about doing the same for Microsoft Exchange.
Similar to Dovecot, Microsoft Exchange also supports IMAP login using a modified username-string. In Exchange, this string looks like this:
Domain/AdminUser/UserName
Our thesis was simple: we wanted to know what email system/solution the ‘elite’ colleges in the U.S. were running. We were also curious to see to what extent Google’s Apps for Education and Microsoft’ Live@EDU managed to penetrate this market.
To be honest, we were somewhat surprised to learn that the by far most popular email system among the ‘elite’ schools was Microsoft Exchange. Fifteen (15) of the schools surveyed used Microsoft Exchange. However, it should be noted that many schools appears to be running Exchange in parallel with another system. Since we have no data on the distribution of users among the different systems, we simply counted both (or all) systems. The second most popular email server was Cyrus with eight (8) schools, closely followed by Dovecot, Google Apps, Sun Java SMS and Zimbra, all with seven (7) schools each.
It is clear that Google’s Apps for Education has been doing a much better job penetrating this market than Microsoft with its Live@EDU. Among all the schools surveyed, only one school (Washington University in St. Louis) is running Live@EDU exclusively. The only other school using Live@EDU, University of Washington, also offers Google Apps. They simply allow their students to pick which one of the two they prefer.
It should also be known that there was a significant number of email servers (13 to be precise) that we were unable to identify. In a number of these cases we could make an educated guess, but we decided to leave them in the ‘unknown’ category just to be safe.
A few days ago I was on a phone conference with a new client (a well-known non-profit, which shall remain nameless for now). They are moving from a hosted Exchange solution over to Google Apps. During the phone conference, we came up with a very clever way to deal with the DNS problem. The DNS problem in question is one of the biggest hurdles with email migration: DNS propagation of the MX-record changes may take up to 48 hours for misconfigured and/or caching DNS servers even if you have a low TTL configured. In the meantime email might go to either your old or your new email provider.
The solution is simple, which makes it great. The key is to have two email addresses on separate domains (sub-domains or separate domains). Since this client was on a hosted Exchange plan, they already had two addresses for these accounts: one for their own domain, and one from the email provider (something like username@non-profit.emailprovider.com). Since both these domains have proper MX-records configured, email can be delivered on both addresses. Fairly straight forward, right? (Phase 0 in the illustration below.)
Now let’s move on to the clever part. Since the non-profit was moving to Google Apps, they needed to change the MX-record for their domain to point to Google’s servers. This can usually disrupt the flow of email, as depending on if the sender’s DNS server is using the new updated MX record or not, the email can be delivered to either the new or the old server. However, since the the email accounts can be reached on two separate domains (and therefor two separate MX-records), we can configure the primary domain to forward the emails to the other domain. In Google Apps this means that you have to create forwarding addresses for every user from username@non-profit.org to username@non-profit.emailprovider.com. (Phase 1 in the illustration below.)
Ok, you might think, that just puts us back to square one. Not so fast. What this means is that we do not have to worry about the DNS propagation anymore. We can do this change the weekend before the actual migration and then all we need to do the weekend of the actual migration is to remove the forwarding and set up a real account. Simple and brilliant. You can even break apart the migration into several groups and do one group at the time. (Phase 2 in the illustration below.)
