Quite a while ago, I moved all of our student e-mail addresses to Google Apps for Education which was a really straightforward affair. We used a completely separate domain and so there was no complication. Their domain pointed straight at the Google servers and the staff domains pointed to the local Exchange servers.
Since merging with our two prep schools, we’ve wanted to move their e-mail accounts on to Google Apps which, for the most part, has been easy too. Their domains were .co.za domains and so we’ve established the student e-mail accounts on .org domains. So, similarly, this hasn’t proved too difficult.
One complication arose with the synchronisation of users from three Active Directory Domain Controllers (each of the campuses) to a single Google Apps account. The problem was that each server didn’t recognise the users from the other two and thus would disable (or worse, delete) them. It took some doing – it is possible – to ignore the containers that the other servers create.
The complications are starting to arise now. Our head office has been based on the College campus. This is likely to change shortly. Thus I have been in the process of moving all the head office accounts off our Exchange server and onto Google Apps. There is one particular user – our marketing officer – who has a lot of time an effort invested into her Exchange mailbox. Thus moving her off the server is difficult. While her account is active, however, the Exchange server claims it can deliver mail to anyone on that domain and so mail sent from the College to anyone at head office is thus delivered to the local server and not to the accounts on Google Apps. To date, I’ve had to create dummy accounts on Exchange and for each head office account, add in a POP fetch to periodically get mail from the Exchange server delivered to the Google accounts.
The reverse process is easier. The MX records point to Google Apps and we’ve implemented dual delivery for the head office domain to ensure that mail is delivered to both Google and Exchange. The dual delivery is set to ignore delivery failures. I have also put in a reasonably complicated regex expression to control who gets dual delivery and who doesn’t. Thankfully, there are a small number of users and this has been manageable thus far.
This migration process will be complete in the next few weeks, but I worry about the investment of effort in managing appointments on local users’ Exchange calendars that this particular user performs. While there is synchronisation between her Google and local Outlook install (we will use the Google Sync Tool, not go to native Gmail for now), the problem is that she is required to make and add appointments to other people’s calendars as part of her job function. These will now be reduced to meeting requests and will be unable to see when times are free or not.
Once all staff are using Google Apps, then this issue disappears (although only if you’re using the GCal web interface).
Apart from head office, we have moved one other section of staff onto Google Apps Gmail. Due to incomplete building works, a nursery school has had to be relocated into the College campus. To prevent even more issues with e-mail servers and multiple mail domains, we’ve moved these nursery school staff onto the pupil’s e-mail domain (which will, in time, become the standard mail domain for everyone). This seems to have gone reasonably well. There are AD Contacts created on their main Exchange server so that their colleagues can communicate easily with them (also to re-route any other incoming mail). Given that the domains that are hosted on the Exchange server and in Google Apps are different in this case, the contact route works… The other alternative is to “establish an external mailbox” in Exchange so that and mail delivered to the Exchange user is re-routed to an external SMTP address.
One advantage of the Dual Delivery route is that we get the benefit of Google’s entirely amazing SPAM filtering. We currently have a few domains that are routed through our ISP’s SPAM filters and they are entirely not amazing. In time I will change the MX records so that those e-mails are delivered to Google, stored in Gmail and delivered to the local Exchange servers. At least this will start building up their mail reserves on the Google servers so that when we do a final migration, much of their mail will already be on the server. Given that we’re already synchronising their user details, it means that they can already log on to the Google Apps and start using that mail. Well, all except for local e-mail, it will work.