This is the first in a series of posts where I hand the reigns of the blog over to one of our customers. I’ve invited James Mason, Senior Portal Developer at the University of Chichester, to (in his own words) “mess up the Blog with some illiterate rambling about our recent implementation of Live@edu”. So, over to James…
The University of Chichester is a small, modern University with approximately 8,500 live accounts. We are predominantly a Novell (Linux) based network with a smattering of Windows Servers to run SQL databases and Windows XP on the desktop. We had recently completed a project to virtualise many of our servers, and we had the capacity to create some more virtual servers as well. Novell has an application called “iChain” (latest version is Novell Access Manager) which we use as a reverse-proxy sitting in front of our web based services. This provides additional security, load balancing, access control lists and single sign-on. The University has a portal system, Luminis IV which includes the SunONE e-mail and calendar software. When on-site, users log onto their PC’s and are automatically (through iChains) logged onto the portal and then are subsequently able to access a variety of tools without any subsequent logins. Externally, people access the portal through our main website, log on to iChains and are then treated as being “on site”.
In September ‘08, the University set up a Project Board with the mandate of finding a new e-mail and calendar system for students AND staff. This system would need to fit seamlessly into our portal, offer a far better user experience and be more robust but would not lose any of the benefits of the integrated system (ability for lecturers to e-mail their classes or send targeted announcements for example)
Choosing the new mail system
First order of the day was to look at the competition. In the end we narrowed the choice down to:
1) Do nothing - A PRINCE2 requirement :-)
2) Microsoft Exchange – the benchmark to compare the alternatives to
3) GroupWise – Novell’s e-mail system that could integrate to our systems easily
4) Google Mail – A very popular system with the benefit of being free
5) Live@edu – Microsoft’s answer to Google Mail with Exchange in the background
This all sounds well and good, but the University had a fly for our ointment. No budget. Everyone wanted the mail system changed (we could only provide 100MB of mail space), but nobody was willing to pay for it. The only resource provided was to IT personnel as and when they were available. Given that, options 1, 2 and 3 were not viable, although we kept them as a way to gauge the viability of the other options.
And to be honest, there was not a lot to choose between Google Mail and Live@edu. They both have fully featured mail and calendar tools plus a whole host of applications that can benefit both students and lecturers.
In the end we chose (drum roll, please) Live@edu (surprised?). This was because:
· The UI look and feel was more professional
· We are an Office 2007 site, something Google didn’t support yet
· We felt Microsoft had a more professional approach with road maps, upgrade paths and support
· It would take less development time (read expense) to integrate Live@edu
To make this work, we required the following:
1) An automatic way to maintain accounts
2) Single sign on
3) Modification to our portal to change mail systems
4) Not changing any current e-mail address
5) Migration of information
Microsoft supply multiple ways of solving the first part, but if you want to synchronise passwords then their best solution is ILM (Identity Lifecycle Manager). They also provide a piece of kit that can single sign on to any part of Live@edu. However, both require Active Directory. So our first step was to install a couple of virtual domain controllers and populate them from our eDirectory tree using Novell’s Identity Manager. A simple install of ILM and IIS got us up and running (I know nothing about either IIS and was still able to get this running as needed within the day). The modifications to our portal were relatively straightforward.
However, the major headache was due to our decision not to change e-mail addresses (email@example.com had to exist on the new AND old mail systems). This meant that we had to create the chi.ac.uk domain on Live@edu but we could not activate it (by pointing MX records at it) until our “go live” date. We could, however, pre-create the accounts in our domain. So, we had e-mail accounts in both our old mail system and Live@edu.
Our last challenge was going to be how to migrate data from the old mail system to the new. Here it was Outlook 2007 that solved our problems. We could automatically set Outlook 2007 to link into both the old and new systems and enable users to just drag and drop their mail as needed. We created a “Frequently Asked Questions” page with annotated videos to help people with this process (http://help.chi.ac.uk/FrequentlyAskedQuestions.cfm).
The e-mail accounts we created in Live@edu were ready and available for staff, even though the domain wasn’t technically active. We used this to our advantage by running training sessions for staff BEFORE we went live. This enabled us to ensure that the accounts, passwords and personal details had all been created correctly and reduced the risk of lost e-mail. We only created 10,000 accounts of which there were about 500 full time staff accounts. The sessions were short (one hour maximum) and we sold the idea to staff with the carrot of a “preview of the upcoming mail changes” and stick of “if you do not attend, your mail is AT RISK”. This way, we got approximately 80% of staff to attend and solved the major issues before we went live.
The go live date (23 May) was very smooth. All the systems were already in place and all we had to do was change the MX records to point to the new mail system and restart the portal services (to activate the changes). Within 15 minutes we were on the new mail system.
That’s not the end, though. Live@edu contains far more than just e-mail and calendar. We didn’t want to overload our staff with new information, so we decided to have a phased rollout. This was helped with us supplying access to the new tools through our portal. So, on 23 May we only linked in the mail and calendar. We are in the process of rolling out SkyDrive, Messenger and the other tools at monthly intervals. Of course, users could access all of these tools already if they know the URL’s but that is unlikely in our environment.
For two weeks after we rolled out the new mail system, our Helpdesk was inundated with questions, complaints and…praise. Yes, you read that right. People actually took time to applaud the new system. Sure, there are quirks, changes and (of course) actual bugs but these are mainly resolved with either a bit of training or passing the job onto Microsoft’s support (the benefits of an outsourced solution).
Officially we are not closing this project until all the tools provided have been delivered (with the support in place) and the students have returned for the next academic year. We also have to decide on how we deal with the “e-mail for life” issue – we would love to provide this service, but at the same time we do not want ex-students being in the global address book.
Obviously, this is a very brief synopsis of all the work that went on (both by the University and Microsoft) but in general, for such a large change for the University, this has been a relatively painless process. We were fortunate in having some systems in place already (namely iChain, Luminis, Identity Manager and VMWare) but that made up for the lack of specialist skills that are simply too expensive for a small University.