Re-developing our intranet

Amongst other things, one of the projects that I'm really excited about at the moment is re-developing our school Intranet. Over the next few month's I'm going to try and use this blog as a diary of this re-development, in the hope that not only have I got something to look back on, but that others doing the same thing might be able to learn from our mistakes.

A bit of history first. When I started at school 2 years ago, there was an existing implementation of Moodle, hosted on a server in the school, that had been put together by some enthusiastic teachers, and the previous network manager. The Moodle site was being used, albeit by a handful of teachers, to deliver learning content but it really needed some development. As well as the Moodle site, there was a simple html page, also hosted internally, that was acting as the school Intranet. This page was a basic, boring, single level page with links off to .pdf files of school news, and some other limited sets of information.

One of the first things we did as a group was to decide that the Intranet site needed a re-design. In order to take advantage of some of the dynamic content that it offers, we decided to use Moodle as our Intranet. Looking back on things now, I can see that this has probably made things complicated as time has gone on and the uptake of digital learning has increased within the school, but for the last few years it has worked reasonably well.

So we presently have a Moodle site that is set as the homepage for all of the browsers in the school. It is used for delivering teaching and learning (the LMS) and also for distributing information such as school news, sports draws etc. through forums. We have recently setup Single Sign On on the site, so all users at school are automatically logged on.

What we are looking for now is to expand the 'Intranet' side of things to incorporate many more areas of the school, and in doing so, we've come to the conclusion that Moodle probably isn't the best place to do this. So once again, we are I suppose looking at reverting Moodle to be our LMS, and employing an alternative platform (perhaps Google Apps, which we have and use fairly extensively) to provide our Intranet. A mission statement (that I have just come up with!) is that it "is a 'one stop shop' where staff, students and the extended school community can learn and communicate in an effective, efficient and safe manner". Our 'Moodle Manager' and I are going to make a start over the upcoming holidays.

Reminder to self

When using the Google Apps Directory Sync tool, make sure you TEST the configuration file before you save and run it! 

I have just managed to delete a user from my Google Apps domain (including all of her email, contacts etc.) after  excluding her account from synchronisation. What I didn't realise was that I had set the Sync tool to delete any accounts not found in LDAP or that are excluded, so on first sync, bang, off it went.

Unbelievably there seems to be no way to recover things yet, but I'll wait for Google to get back to me on that one.....

Forcing Google Apps to use Chrome instead of Internet Explorer

Continuing on with our roll-out of Google Apps for Education here at school, we have been struggling a little with browser compatibility.

First off,  it's obvious, and it's inevitable, but Google Apps is much better in Chrome than it is in Internet Explorer, hands down. I'm not entering into the browser debate, and in lots of ways I don't really have a browser preference but Google Apps simply looks, feels and functions better in Chrome, and as new features become available in Apps, we are finding that IE won't even run some of those features anyway (Wave, Drawing etc.). There is a plugin available from Google (Chrome Frame for IE) that enables Chrome functionality within IE, but as with most things Google, there doesn't seem to be any offline installer that we can use to push out to all of our client workstations. We will keep looking though, because if we find one, it will solve most of the issues we are having.

Another simple solution would seem to be just to roll-out Chrome to all of our workstations right? Wrong. Again, Google doesn't make this easy. Although there is a standalone installer for Google Chrome it installs itself into the user profile directory rather than the common 'Program Files' and for a few reasons this simply won't work on our network. Again, no easy fix for this yet either.

Having spent a few hours on this, I went and did something else to clear my mind, and I then remembered 'Portable Apps'. Portable Apps is a collection of applications that have been packaged up to run on portable media (i.e USB keys) but they often run just as well on a network, without many of the hassles of applications that need to be 'installed'. We use Audacity and WinFF as portable Apps here and students run them seamlessly across the network. There is a portable apps version of the latest Chrome browser and I'm pleased to say it works a treat. I simply installed it to a network share, then created shortcuts in the student profile that run the portable version of Chrome, and call up the particular address for each Google Apps component on startup. So the students now have separate shortcuts on the desktop to Google Docs, Google Sites and Google Calendar that force run Google Chrome. Job done so far. We still have links on our Intranet page that point directly to the web addresses of Google Apps, and these will open in the default browser (which is IE on most of our workstations) so that is the next problem. We'll keep looking for the Google Chrome Frames installer, and maybe an easy way to push Chrome out to workstations, but for now, it will do.

18/11/10 Update on this, the Google Chrome Frame installer is now available as an msi which can be pushed out via Group Policy

Google Talk / Google AppsAccounts

Google Talk is a basic instant messaging program and can be used as part of Google Apps for Education. My Google Apps (GApps) users can sign in using their accounts and, as I had just had a request for an instant messaging system for the staff I thought this was a great thing.

Well it is, but as always there's a 'gotcha'.... The problem is that we don't really want instant messaging for the students. Easy you say, just don't install Google Talk on the student machines? Well yes, that does help. However, in their wisdom, Google decided to build the 'chat' feature into Gmail, and I am rolling out Gmail to all of my users. So the students bring up a browser, login to Gmail and they are automatically (gggrr) logged in to an instant messaging program within a browser! Searching the Google help forums I have been staggered to find that you can only disable chat/google talk at the domain level, so it's either on or off for everyone. If I disable it the students can't use the chat feature built in to Gmail (which is a good thing obviously...) but the staff can't use instant messaging.

After discussing with the staff we have decided that IM is too important a tool not to have for staff, and that the Google route is the obvious way to go. So we are sticking with leaving chat on, and putting the emphasis on the teachers to monitor usage in class, and try to educate the students about the appropriate time to be using things. It's been really interesting as what started out as a simple technical problem has lead on to discussions around a whole bigger issue of whether in these days of collaboration and communication, we should even be trying to restrict access to stuff anyway. I can see that the traditional role of the Network Manager is changing and even though I have always seen myself as an 'enabler' rather than a 'disabler' it is still a challenging time trying to find the right balance between giving students access to the tools that they need and use, but trying to ensure that they are used appropriately.....

Migrating email from SchoolZone to Gmail

In so many ways, the webmail component of Telecom SchoolZone is terrible. It's based on an outdated form of SquirrelMail I think, and my rollout of Google Apps at school is an attempt to replace it with something far better, Gmail. Google Apps comes with Gmail for all of our users, and they get to keep their existing email addresses. Switching to Gmail is a fairly straightforward process itself (that I'll talk about later I suppose) but trying to migrate users existing email and contacts is turning into a big job. SchoolZone email has no facility to export messages, so the method involves downloading a users emails into an Outlook pst (one folder at a time) and then uploading them using the Google Email Uploader tool. This in itself is a huge, time consuming job, but here Google falls down a bit too. The problem is that the email uploader tool doesn't support proxy authentication so fails through our school internet connection. Faced with these issues, I'm seriously thinking about not migrating messages at all, but giving the users shortcuts to SchoolZone email for their old email, and Google for their new stuff, at least for a while anyway. I can get them to forward any important messages in their own time and I'm comforting myself that it's a good opportunity to clean out some unwanted emails (even though they did this at the start of last year when my predecessor moved the school from Exchange to SchoolZone). It's ugly but easy, and will probably be all forgotten about in a few months anyway...


- Posted using BlogPress from my iPhone

Google Apps implementation part 1

Welcome to my blog. Over the last few months I've been planning to roll-out Google Apps for Education at our school, and during the recent Christmas break, I've made a start. At the time of writing this, I've got Active Directory populating and synchronizing users and passwords with Google Apps (using the Google Directory Sync Tool). So far, I haven't publicized it to my end users (as they are all on holiday anyway...) and I haven't enabled Gmail as I need to do some more work on migrating from our existing email system. The only real gotcha that I came up against was synchronizing passwords. Active Directory stores it's passwords in binary, and the Sync tool can only read plain text, MD5 or SHA-1. To get around this, I've got this filter installed and configured on my DCs, which in turn populates an LDAP field with an SHA-1 password which is then read by the sync tool. The field doesn't get updated until the user's AD password is changed at least once, but after that it seems to work well. I haven't got Single Sign on going (and am not sure if I will try yet). So this next week it's the bit where I get to further explain to staff what Google Apps is, how it can benefit them, and how they can logon. Then it's implementing Gmail, and then rolling it out to the 800 or so girls at school