So, how did that Google Apps move go?
Some clouds, rather than The Cloud
Over the holiday we migrated the whole school over to Google Apps (all 1800 students and 200 staff). This is a quick summary of how we found the process, what problems we had, and the benefits we have seen since the move. I’m very aware that our LA will start the process of moving schools over to live@edu at some point later this year so I thought it might be interesting to offer up some views on how we have found working on the Google system so others can make a considered choice between them. More than happy to answer specific questions or redirect them to a member of the tech team if I miss things, or people are always welcome to come and have a look.
Both of the systems have fairly lengthy sales pitches at their respective websites (Google here, Microsoft here) so I won’t write too much about what they do. I’ll assume most already know- basically there’s nothing really between them and what is different has been documented online before. The significant detail in terms of users that people often don’t consider though is familiarity- a large proportion of our user-base was already using Google tools personally. This isn’t about a bias, but it does impact on your training and adoption considerations.
The most positive aspect about the migration process from a sysadmin point of view has been the Google APIs. The provisioning API made the process of account creation incredibly simple- it just syncs up to our directory in school. Any changes there are reflected in the Google accounts, that’s it.
Once we’d set this up the accounts were in and ready to use. This includes calendar, chat, documents and sites. The admin side of things let us deal with central calendars/contacts, and sorts out who can do what. Where things became harder were when we started to migrate existing email to the new system. Obviously you could skip this entire process if you make the change by telling users nothing will be done automatically, but we’re a helpful bunch so thought it would be worth going through.
In Hampshire we run two separate email systems at an LA level. Staff and students run a web-based mail system called @mail, SLT and admin use the Outlook Web Access stuff. All fine if a little limited, particularly when it comes to any back-end access for this kind of job. Our lovely network manager (@jamesyale) wrote a genius piece of script to automatically forward mail from all the @mail accounts into our new Gmail setup and users were asked to migrate their contacts themselves if they needed them. All good. Sure he’d be more than happy to share if anybody is interested. The OWA stuff is a different story and still an ongoing problem so no comment…
The lesson to take away for other admins taking this process on is about mail redirection. We completed the above, changed the DNS entries, everything seemed happy sending and receiving email. We then discovered that mail is redirected internally within our LA, so any email sent from another Hampshire School was only looking locally for the accounts and being sent to the old ones. Not a problem as we can run the forwarding script nice and regularly, but the most difficult part was requesting this change from the LA. After a huge amount of faff it is halfway to being completed now and basically not something that users notice, but a pretty major problem we didn’t consider. The positive to take away for us is while it has been something of a helpdesk nightmare, we have made some contacts within the authority so hopefully have a good way of getting advice/support before our next major move.
The only other issue we have discovered in the migration is related to the provisioning API. I can’t stress just how great this tool is- no creating duplicate versions of accounts/etc. The problem we have found is for users with mobile devices. Because Gmail is looking at our database for passwords it doesn’t store them in its own. This means when users try to log into the mobile interface it throws up a password error until the password has been entered. Not a big problem and a simple enough fix, but good to know if you’re having the same issue. This may also be something to do with how we have set it up, just documenting a problem we had.
One other minor bug- 3 of our SLT have Blackberries. Blackberry and Google don’t appear to like each other, so the two don’t link perfectly. Some problems around read/unread and deletes, but it seems this has now been fixed by the Blackberry types. Obviously the advice here would be to get a shiny iPhone/Android based phone, but as it’s fixed now so you can keep your Blackberry if you really have to.
Finally, the move has proved incredibly popular with staff and students so a short list of the things users have really liked so far:
- Conversation style storage of emails in your inbox
- Labels and archive
- Chat for communication between staff
- Shared calendars for groups (exam timetable for example)
- Free text messages from the calendar
- Collaborative document editing
- Simple contact group creation
And the thing I was most pleased about is we achieved the migration without any staff training. A quick announcement in a briefing and a few bits of policy change and that was it. Really easy to pick up, and the online help is really strong. We’re now slowly introducing new features through our fortnightly tech newsletters and small-scale trials, and have started to look at the Joomla/Moodle integrations too.
