The Cloud

Ah, the cloud: a wonderful metaphor dreamed up by the marketing departments of Big Tech companies to describe how your data doesn’t have to live on your own physical computer or server but can live inside their data centres instead. We, the user (whether that’s a big organisation or just an individual consumer), no longer has to worry about how that all that computery stuff actually works: instead it can be abstracted away into a nice little diagram of a cloud.

And it’s not a bad idea! Steve Jobs introduced iCloud back in 2011, which was mainly just a marketing concept to bring together an IMAP email service, online backups for your iPhone, some photo storage, file storage and a few other bits and bobs. As internet connections have increased in speed an ubiquity, it has made more and more sense to have certain online services hosted somewhere ‘out there’, rather than inside a school’s network. Many schools might still run a Windows file server, but I doubt there are many that still run their own mail server – this job has been farmed out to ‘the cloud’.

So what are the benefits of moving to the cloud, particularly in the current situation we find ourselves in?

Someone else runs the server for you. Particularly in a small school, this is no joke! Running servers efficiently and effectively isn’t easy and requires a certain level of technical expertise.
It’s cheaper. Because of economies of scale, it usually works out cheaper to buy a slice of someone else’s cloud computing power rather than do things for yourself, particularly if you factor in the true cost of running your own server.
It allows for access outside of your network. It’s possible to set up VPN connections to on-premises servers, but it’s much easier if you’re using a ‘cloud’ service that is designed to be accessed anywhere.
It tends to work better with modern computing devices. If you’re running everything on Windows PCs, then your legacy server setup is fine. But if everyone’s using iPads, then you need services that play nicely with modern apps, file systems and workflows.

So, what might networked services in a school might need to end up in the cloud?

Email. This is a quick win, as more than likely you’re already getting someone else to do this for you! We make use of London Grid for Learning‘s Staff Mail, which has a web interface as well as offering Exchange access on a Windows PC, a Mac and iPad/iPhone. But Office 365 or G-Suite for Education are good options too!
Calendar. Our Exchange email can do calendars for each individual, but we use Google’s calendar for the whole school calendar. Only certain individuals can add new events, but it means that everyone can see what’s going on across the school.
User Authentication. This needs some careful thought – how are your staff (and students) going to log into the cloud services? As the number of online services increases, so can the number of different usernames and passwords. This is both annoying for staff as it’s one more password to remember and can also become a real security risk as staff may reuse passwords etc. We use LGfL’s Unified Sign On (USO) as the core identify and then are able to sync this up with G-Suite, our on-premises Active Directory as well as Office 365.
File Storage. We use Google Drive, as schools get unlimited storage. It also has quite a few ‘hooks’ that allow us to weave it into existing workflows: there is an app for iPad, there is the Drive interface on the web (that Google would much rather you used), and you can also use Google Drive File Stream on the Mac (which adds Shared Drives in a comparable way to a normal network drive). Because the files are all stored in the ‘cloud’, they can easily be accessed when working from home.
Photo Storage. iPads make for handy cameras, generating gigabytes of photos and videos over time. Thankfully, Apple offers 200GB of free storage for schools with Managed Apple IDs. This means that photos can be backed up to the cloud from iPad, along with device backups and iCloud document storage.
Management Information Systems. In the UK, Capita SIMS is the market leader for managing student data, whether that is home contact details or attendance registers. Capita do offer a ‘hosted’ version, which allows you to run the software on their cloud servers instead of on an on-premises server, but it still is very much a Windows PC-only piece of software. Nearly 5 years ago, we moved to a web-based MIS called Pupil Asset that provides much of the same functionally but inside of a web browser that can be viewed on any device. It’s not all been plain sailing, but we’re now in a much more agile position when it comes to accessing student data remotely.

Moving to the cloud does mean a change in workflows and you have to make sure staff are on board. It does need to be carefully planned and communicated, with potential issues identified and addressed quickly. If you are able to articulate the ‘why’ for a switch to ‘cloud’ computing, plus do all you can to make it as easy as possible for people, it can be a real success and make a big difference.

Getting Caching Server working on LGfL

Caching Server is a cool part of OS X Server: once you turn it on, it basically becomes a local cache of the App Store (Mac and iOS), keeping a copy of downloaded apps on your local network. This results in faster app downloads, as they’re coming from within your network, and less use of your broadband connection. Which is nice.

Unfortunately I’ve never been able to get it to work as my school is part of London Grid for Learning (LGfL). LGfL is a broadband consortium, which allows schools to buy broadband at much cheaper rates because the LGfL trust has built a lovely big network (with the help of Virgin Media Business) just for schools in London. With an eye to safeguarding children, this network is built to be very safe and secure. The upshot of this is that our little Mac server is buried deep within the network behind many firewalls and switches and routers and so on. Which has meant that Caching Server hasn’t worked, as it needs to sit pretty close to the open Internet.

Until Yosemite that is.

We recently had our server updated to OS X 10.10, and with that comes some improvements to Caching Server. One of these is the ability to set the public IP addresses/ranges that will use the Caching service, thus making it all work.

Here’s how:

Open the Server app and click on ‘Caching’. Turn it on.
Click on ‘edit’ next to where it says ‘Permissions’.
On the drop-down menu next to ‘Serve clients with public addresses’, choose ‘on other networks’.
Click the plus in the box below and add the public IP address of the server. You can find this out by clicking the server name under ‘Server’ in the sidebar.
Enter in the public IP address for all LGfL-connected, which is 5.150.101.173. Apparently!
You then need to set some client configuration on your DNS server. Our DNS is on a Windows server, so I click ‘Client Configuration’, choose ‘Windows’ as the DNS type and then copy the command. I then open up the Windows server, type ‘CMD’ into the search box to open the command line, then copy the command.

And that seems to do the trick! Lovely.

The State of Mac Management

In the glory bygone days, managing Macs was easy: just setup a OSX Server, get Workgroup Manager working and then configure users preferences to your heart’s delight. There were ways to easily tweak settings using a GUI, or you could import whatever .plist file you wanted to and have a custom preference.

Now, it wasn’t all a bed of roses: the Mac had to be bound to the OSX Server for these managed preferences to work, meaning things got rather ugly if the server got taken down for any reason. Plus, you had to find other solutions for imaging Macs, deploying and updating software and remote access. But there were tools for this (Deploy Studio, Munki, Apple Remote Desktop), so we were happy.

Then along came Lion. As part of taking everything Apple had learnt from iOS ‘back to the Mac‘, Configuration Profiles were introduced. These were just the same as the profiles used to manage iPhones and iPads, offering ways to lock down certain things and setup accounts like email etc. The other cool thing was that these lightweight profiles could be pushed out to a Mac from an MDM server, removing the need to have the Mac permanently bound to a server. Instead, the Mac would keep hold of its profiles until the server gave it some new ones. Macs and iPads could all be managed from one place: one MDM to rule them all!

Workgroup Manager continued to be updated by Apple, but with very little attention given to it. The last version released was for 10.9 server: it still works in 10.10, but has officially been retired and any future support for it is quite unlikely.

As someone who likes to live at the bleeding edge of technological change, did I adopt it straight away? Not for want of trying! Apple offered their own ‘free’ version of an MDM as part of their Server app, called Profile Manager. We couldn’t even get it to work in 10.7, finally got it working with some iPads in 10.8 and then gave up on it in 10.9 (after suffering email profiles being pulled off every teacher iPad due to some weird Active Directory issue).

The issue with it boiled down to how Configuration Profiles just aren’t the same as Managed Preferences. In the ‘walled garden’ of iOS, we just accepted that certain things just weren’t manageable (like position of apps on the home screen or the initial setup of apps etc). Whereas Managed Preferences had given the Mac administrator the taste of absolute control – you shall have the settings I give you! Plus, they also had the fine-grained option of setting preferences to ‘once’, ‘often’ (ie every time you logged in) or ‘always’… with profiles, everything was just ‘forced’.

So, the questions are: what actually needs to be managed? what are the ways of doing it?

Things that need to be managed:

First run settings on stuff like Office
Mounting shared drives
Tweaking the UI as required, eg right click on Apple Mouse, sidebar defaults etc
Licence keys for apps
Setting keyboard, location etc
Managing the dock
Installing new software and patching existing software
Imaging new Macs
Running Apple Software Update

So what are the tools?

Using a Configuration Profile, either for the settings Apple gives you, or importing a custom plist – only works if you don’t mind it being ‘always’. Tim Sutton has a command line tool for converting a .plist file into a profile. An MDM server can push out profiles over the air and Munki can now install profiles too.
Tweaking the preferences in the default user template. Composer as part of Casper Suite has a handy feature for doing this as well as filling existing users’ preferences as well.
Running various scripts on startup/login/logout. Our Apple reseller has a way of running various scripts like this, and Casper can manage his too. You can also make payload-free packages which just run a script when installed and can be distributed with Munki.

So how do you choose the right tool? The factors are:

Cost: MDM servers aren’t cheap necessarily, nor is spending money on getting an Apple reseller to set things up for you.
Experience: are you savvy with scripting and dealing with the command line? If not, a solution with a GUI might be better.
Continuity: I work in a primary school where high turn-over of staff is quite common. Does the solution need to keep working even if you go?
Time: do you have time to learn and understand the intricacies, or do things need to work ‘out of the box’? I am in the fortunate position of being able to give time to figure some things out, but most primary schools aren’t.

At my school, we’ve gone for Casper Suite as a way to have a GUI for managing Macs that doesn’t rely on me being a complete Mac system admin with lots of experience in scripting etc., whilst also moving away from Managed Preferences and leveraging Configuration Profiles instead. Let’s hope it works!

Casper Suite

We’ve just had Casper Suite installed at my school. Part of the installation process is a three-day ‘Jump Start‘ where a highly experienced trainer (in our case, two, as we had someone shadowing) guides you through installing the software and the processes involved in setting up and running it.

So why Casper suite? Over the years, we’ve ended up using a range of different systems and technologies to manage the Macs and iPads in school. The Macs have been managed with an OSX Server running Workgroup Manager, plus a few scripts written by our Apple Reseller and the use of Munki for managing software installs and updates. With iOS, we’ve used Meraki, making use of the VPP programme and managed distribution, as well as Apple Configurator for class sets of iPads.

This has worked pretty well, but I knew we needed to move away from Workgroup Manager. Since 10.7 Lion, Apple has pushed the use of Configuration Profiles instead of Managed Preferences. Technology-wise, it isn’t a straight swap, as there are things you can do with MCX that you can’t do with profiles, and vice versa. But with 10.10, Workgroup Manager no longer even exists (even though the 10.9 version still works!), so I knew we had to do something. Casper suite was well spoken of, properly supported OSX as well as iOS, and seemed to have some cool features.

The main drawback of Casper Suite is the cost: as an educational customer, you only pay for support per device, which works out pretty cheap. But you have to pay for the three days of ‘Jump Start’ before you begin, which is not cheap! However, I calculated that it works out about the cost of a case per device, which isn’t so bad. An iPad without a case is pretty hobbled, and I’m sure Casper will add a depth and richness to our deployment.

The Jump Start went pretty well, and we managed to get everything working by the end of the three days. I did finish the three days feeling overwhelmed with everything there is to do (sorting out all the configuration of the Macs then imaging them all, plus redoing all the iPads), but I think it will come together over the next half term.

Here are some of the highlights so far:

Casper Focus: allows a teacher lock all the iPads in a class to a particular app or webpage
Self service: dishing up apps, books and in fact most things to users
Deployment Enrollment Programme (DEP): iPads get automatically enrolled to Casper and tied to a certain user out of the box
Composer: a powerful way to package up Mac apps, including the ability to fill the user template and existing users’ preferences
JSS: the fact it runs as a web service, meaning that Macs don’t have to be bound to an OSX server any more
JAMF Nation: a community of helpful geeks who are there to help find solutions to problem

I’m not sure it’s the right solution for small primary schools, or places without an onsite Mac geek, but I think it’s going to work really well for us.

How to get alert emails to work from a Mac Server

With LGfL, they are quite strict on what devices on their networks send email. However, they are happy for you to make use of Google’s SMTP server.

Things like Profile Manager make use of email for inviting users onto the Managed Distribution programme, so I wanted to setup our Mac server to be able to send emails like that. After a bit of searching, I came across this brilliant explanation of how to send mails from localhost. And it seems to have done the trick!

What I’m looking forward to in the Great Software Update

At WWDC, iOS 7 and OSX Mavericks were announced and September 10th is the date when the new iPhones get revealed, so I’m guessing that the release of the aforementioned software won’t be long after that. Here is what I’m looking forward to in those releases:

Automatic software updates for iOS. No more stomping around the school with a big sync case updating iPads. Or at least I hope.
SMB as the default for file sharing on Mavericks. This should hopefully mean that using a Windows file server will be less painful.
A better Profile Manager on Mavericks Server that can actually manage ‘Often’ preferences on a Mac.

Making the ICT Suite more iPad-like

Over half term we had the fun job of upgrading our Mac server to Mountain Lion and then fiddling around with user accounts to make the Macs play nicely with our new ADSync setup. As part of this process, I decided to change the way that the ICT Suite worked.

The old setup had children logging in with a class login, which allowed for a shared ‘documents’ on the server. However, you would have to be logged in with those credentials to see the files, which would be annoying for teachers wanting to access work elsewhere in the school. Entering a password to login was also rather tricky for the younger children, wasting a substantial part of ICT lessons early on just with logging in. Also, because iMovie projects were saved locally to a machine, children would have to go back to the same machine with the same login to continue with their video. This generally worked well, but if a child didn’t check that the Mac was logged out before starting work, they may have no idea what login to use to go back to it in a later lesson.

Instead, I set up the ICT Suite as follows:

A local account, without a password
The login screen showing the local non-adminstrator account as a ‘badge’, rather than a text field for username and password
When children log in, a shared drive is mounted via Managed Preferences, which has the username and password build into the URL (e.g. smb://username:password@pathtoserver/sharepoint). This shared drive is a subfolder of the shared drive that teachers use across the school, meaning teachers can see children’s work but children can’t see all of the teachers’ work.
A login script runs which renames ~/Documents to ~/MacDocuments and then creates a symbolic link to the mounted shared drive and calls that ‘Documents’. This little manoeuvre tricks Finder into putting that shared drive into the sidebar where Documents used to be, and also makes it the default save position

The upshot of all of this is that it makes the ICT Suite have much more of an iOS-like experience; instead of typing in usernames and passwords, you just click and go. Popping into the ICT Suite today, teachers and children certainly liked the change!

Munki really does work!

Munki really is brilliant. From the user’s end, it is basically invisible, installing software when the computers are sitting logged out and never bothering anyone. From the admin side, it is super quick to import a package file and super easy to add it to the list of files to be installed. This week alone I have been able to push out three different installs, confident that, by the next day, they will be installed on all the machines.

The only problem with it is that the admin backend is not hugely user-friendly, relying on setting up your own webserver, typing stuff into Terminal and editing a .plist file of software to be installed. I would love it if someone might perhaps consider building a beautiful and simple GUI backend too. Anyone offering?

ADSync

When I first heard about the LGfL USO, it made a whole lot of sense to me: one Unified Sign On, allowing you to log onto a range of different services using just one username and password. As part of that service, something called ADSync is also offered, which allows your Active Directory to have all the same usernames and passwords as your USO account.

I first heard about this in 2010, and we have finally installed it in our school! Hurrah!

We were a little bit wary of this (as was my technician, who didn’t like the thought of someone else controlling our AD), but the installation seems to have gone very well. It was all installed remotely, but Atomwide were very friendly and helpful along the way.

The job isn’t completely done yet as all of the Mac home folders are still under the old names. However, Toucan are coming in and running some sort of magical script that will rename everything and make everything work wonderfully. For staff, this should mean there is one less username to remember. And for support staff who don’t log onto their emails very often but do use the Macs, it might help them remember their login!

Flash vs. Safari

Upon arriving at school today, teachers started telling me that they couldn’t view their Flash content because Safari was saying that the plugin was out of date and therefore blocked. Some had the initiative and had download and install the update because they knew the admin credentials, but it wasn’t looking good for everyone else.

Thankfully, Munki was there to the rescue! I managed to quickly download the Flash installer (using the volume distribution link on Adobe’s website – long story) and then uploaded it to our Munki repository. Our Macs are set to update every morning using Munki, but that was no good in this situation as everyone was already logged in. Instead I had to post some instructions for staff on how to use the ‘Managed Software Update’ app which comes with Munki to manually activate the installation.

Simples. Kinda.

The reason this is all happening is because of Apple’s XProtect software, which downloads a list of software to watch out for and then proceeds to block it as it comes across it. Which includes any out-of-date versions of Flash.

I guess the annoying part of this is that there is no automatic way of downloading and installing Flash updates, particularly on a network and particularly because Adobe specialise in inventing their own balmy and non-standard installer files.

Maybe Safari should join Chrome and offer automatic updates of plugins (particularly Flash). Or maybe Flash should just hurry up and be replaced by HTML5.