Google Apps Deployment – the Complicated Way

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 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.

Staff iPad Deployment

It’s been two months now since we deployed iPads to the staff. The staff have taken to the iPads enthusiastically and it is a pleasure to see them being used to fervently. Well, at least in the majority of cases!

One of the first things we did was change our morning roll-call procedures so that teachers could capture their absentees each morning directly into our administration software (ADAM). This means that each staff member has their iPad with them every morning which has lead to some unintended benefits of sharing experiences and tips and tricks with one another.

We have run some training courses – nothing particularly mind blowing at this point. I want teachers primarily to understand the paradigm of tablet computing. They need to understand that a tablet is a valuable tool for an entire myriad of tasks and not just “computer” jobs. We will up the tempo next term and run a comprehensive training course right before school gets back where we will start looking at academic workflow.

Our wireless network, UniFi based, has held up well, and we are in the process of increasing the density of it. There is one (very) dark spot on campus which we only picked up after the deployment. There are between 170 and 200 wireless devices being brought onto campus each day and these are coping so far. In theory we could hit a capacity of up to 600 devices and so some significant increases in coverage will be necessary in the next six months.

The deploying and updating of Apps using the server profile manager is working well. However, it has highlighted one iPad that hasn’t been brought onto campus in – how long – two months… Certainly, at least we know where to focus attention and do some cajoling!

Other internal processes have changed to accommodate the fact that iPads are always present. We still do a fair amount of printing, but I suspect that this will drop off as people get more familiar with the technology. One thing that has changed, slightly, is that our morning notices are written up in a file in the staff room. While this has not been replaced with an electronic document (a Google Doc would work brilliantly), at least a photograph is being taken of the page and e-mailed to staff instead of being run off on the copier as was the previous practice.

Slowly, slowly catch a monkey…