Network drives on wifi

Back in 2010, when we were considering getting some Macs in school, one option we considered was getting a set of MacBooks for use by kids. As we already had some PC laptops which connected to the server via wifi, I thought we could do the same with some Macs. However, our reseller strongly advised putting in wired network connections if you are binding a Mac to an Active Directory as performance would be poor on wifi. I didn’t think much further about this as we ended up getting lots of iMacs instead, which all ran off wired Ethernet connections.

However, I recently tried adding a MacBook Pro to our domain, running it just on wifi, and this cautionary advice all came flooding back. Because we’re a big school, we make a lot of use of shared drives for saving work on. Working on a document off of a network drive requires a constant connection, which can become a little tiresome on wifi (particularly if the access point has a couple dozen iPads on it as well!). Having had enough of the spinning beach ball of death, I found a long network cable and plugged myself in.

Running documents off a server does feel a bit like living in the dark ages though. Admittedly, it is handy to be able to log onto any computer in the school and have all your document just there, but you do pay for it with a performance hit. Storage read and write is the last great bottle neck, which is why Apple is aggressively moving towards flash storage (Flash? We love flash!) wherever it can. The iCloud document model also makes a lot of sense: your documents live on your iPad/Mac/iPhone, but any changes are pushed to your other devices so that the same document is ready and waiting when you get there. That way you get the speed (and non-reliance on a permanent network connection) of a local document with the convenience of network storage.

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.

Reflector vs. Apple TV

One of the really cool things about an iPad in the classroom is how you can mirror your iPad’s screen to any AirPlay-receiving device.  Like an Apple TV.  I use this functionality all of the time, basically using my iPad as a replacement for the notorious ‘smart’ board, particularly when using Explain Everything.  It’s very handy and means I can have my iPad sitting on the piano whilst I’m teaching and easily change slides, annotate things, move things around etc.

Apple TV is Apple’s preferred way of doing this, which is their little black box of goodness which you then plug into your widescreen TV by HDMI and go from there.  If you have a widescreen HDMI TV, then this is the simplest solution.  However, most schools are instead running some sort of fangled VGA projector+computer+monitor+speakers+amp, without an HDMI input or output in sight and projecting onto a 4:3 interactive whiteboard.

This results in the following problems:

  • you’ll need to buy a HDMI to VGA converter.  Kanex do the very cool little adaptor that does the trick, but the problem with this (so I’ve been told) is that it can’t cope with a really long VGA cable to the projector as isn’t powered.  Most schools have the VGA cable running up the wall and along the ceiling, adding a good 5 metres of cabling.  You can buy powered HDMI to VGA converters, but this adds another little box, another power lead and all sorts of other tangles.
  • screen ratio issues.  The Apple TV assumes you are going to a 16:9 output, so it just adds black bars to the left and right of the image when mirroring the 4:3 iPad.  When you are projecting to a 4:3 screen, this results in either a weirdly stretched image or a rather small image.
  • you’ll need to switch between displays.  If you’re already running a smartboard computer, the teacher will have to switch displays on the projector to the Apple TV input.  Not difficult, but still a bit of a bother.

Enter Reflector (formerly Reflection).  It’s a Mac (and PC) app that turns your computer into an AirPlay receiver. It’s only $15 and you can buy multiple licences slightly cheaper.  All you have to do is start the app running, and then you can mirror your iPad to your Mac’s display.

The advantages are as follows:

  • true 4:3 mirroring.  If your computer is already running a 4:3 display, then the iPad mirroring will fill the whole screen.  Yay!
  • no display switching.  It just uses your existing screen and projector.
  • no extra wires or boxes.  Which is always good.
  • cheaper!  £10 vs £85 speaks for itself.

The only downside is that iPad Keynote slideshows don’t fill the screen.  This is because the Keynote app assumes it’s mirroring to a 16:9 Apple TV so adds it’s own black bars to the left and right of the image.  Swings and roundabouts I guess!

Managing without the Mac server

A few weeks ago, we discovered that the second hard drive on our Mac mini server was failing.  Which isn’t good.  It’s still under warranty though so won’t cost anything to fix, apart from the inconvenience of having it taken away from our school for a few days.

And an inconvenience it certainly has been!  The Mac server has been brilliant for managing all the little settings and preferences on the Macs and I’ve made much use of Workgroup Manager for tweaking this and fixing that.  This makes it all the more painful when it is removed, especially with a large school full of an ever-increasing number of Macs.

All the Macs are bound to two servers: the Open Directory (OD) on the Mac server and the Active Directory (AD) on the Windows server. The AD manages usernames and passwords and serves up all the network drives, but the OD tells the Macs what to put in the dock, what drives to mount on login, and where Microsoft Office can put all its first-run registration windows (i.e. not on my screen!). Without the Mac server, the Mac will still let users login, but the dock will be empty, network drives won’t be mounted and everyone will come running to find me and demand access to their shared folders.

After some very helpful support from our wonderful reseller Toucan, I settled upon this plan:

  1. Make a local account and set it up just how I wanted it, i.e. applications in the dock and network drives mounted on login with credentials on the keychain.
  2. Log in as root and copy this home folder to all the Macs using Apple Remote Desktop.
  3. Tell teachers to login with the local account only.

The first part was fairly straightforward.

The second part was a little more tricky as it involved logging in as root, something I had not done before.  But Apple give some easy-to-follow instructions how to do it.   This gives the user unlimited powers to look in any folder and move anything anywhere, without running into permission errors all the time.  Once logged in as root, I used Apple Remote Desktop to copy the home directory of the local user to all the Macs. I had already set up a local user previously, so I just reused that name and didn’t have to go to each machine and add a local account.

The annoying problem I ran into was that some Macs were still remembering all their managed preferences, even though the Mac server was unavailable.  This would have been fine if every Mac was doing this, but it was inconsistent across the school and gave an uneven user experience.  Thankfully, I found an article explaining how to flush the MCX cached settings. Et voilà, everything working fine.  Or at least good enough.

I hope the Mac server gets fixed quickly!

It does make me realise why Apple is moving to profiles for managing preferences on a Mac, just like with iOS.  That way, the client machine remembers the settings it’s been given, rather than relying on a continuous connection to a server.  It’s just a shame that Profile Manager isn’t quite up to the job as of yet, particularly with OSX.

Wineskin: running Windows apps without Windows

Over the last few months I’ve been making use of an app called Wineskin, which lets you run Windows applications on a Mac without running Windows.  It utilises Wine, an open-source project which attempts to duplicate all the functionality of Windows libraries thereby enabling Windows executables to run on Linux/OSX/etc.  This doesn’t work with everything, but definitely with enough titles to make it useful.

The particularly cool thing about Wineskin though is that it installs all the Wine binaries inside a normal .app OSX application package.  You then install the software you want within this ‘wrapper’, thus enabling it to run on any Mac without requiring Wine or anything else to be installed first.  This is very handy in a school, as I can create wrappers for all the different Windows applications I want to run and then just drop them into the Applications folder of various Macs, via Apple Remote Desktop.  The user then just launches the app and starts using the program.  This makes for a much smoother experience that clicking on a VMWare Fusion shortcut, waiting for the virtual machine to start, clicking through the various ‘Download update!’ and ‘Buy the new version of Fusion!’ messages and then finally getting to your application.  Well I think so anyway.

Today I tried getting it to work with a BBC Active CD-ROM about ‘Rites of Passage’ in RE. It seems to function ok, although I’m having trouble moving the Wineskin ‘wrapper’ between computers.  The weird thing is that you can preview the whole piece of software online using Flash, which makes me just a little bit annoyed why they didn’t make a Mac version while they were at it.  I guess it can’t have be worth their while. And if they’re making and selling CD-ROMs, they are clearly not trying to be at the cutting edge of technology, especially as you would be increasingly hard-pressed to find a Mac with an optical drive anyway…

iChatting across subnets

We’ve had iChat set up on our macs for a while, making use of Bonjour to provide a zero- configuration way for teachers to communicate around the school. We now have a second site and teachers wanted to be able to iChat between sites but it wasn’t working as Bonjour doesn’t easily work across two different subnets (especially if LGfL are involved!). So instead I set up iChat Sever on our Lion Server.

It was mainly straightforward, once I had figured out how…

  1. Turn on iChat server on the Lion server.  Involves switching it to on.  It sets up a Jabber messaging server.
  2. Set up the login details using Workgroup Manager.  There is a manifest called ‘iChat.Jabber’ which gives you a managed client settings already set up.
  3. When a user logs onto the Mac, their credentials are used to log onto the iChat server.  This requires an AD or OD setup, which meant a few issues when it came to the experimental ditched directory Macs. I had to set these machines up manually using the user’s network logins.
  4. Initially, the iChat window doesn’t show any ‘buddies’, which  renders the service useless at school because teachers wouldn’t know each other’s iChat accounts.  Lion server promises the ability to add all users as buddies automatically, but this only seems to work if you’ve got an Open Directory setup (i.e. all user accounts are on the Mac server rather than elsewhere).  Instead I had to log each user into iChat and then run the command ‘sudo jabber_autobuddy -m’ in Terminal on the Lion server.  This adds everyone who has ever logged into the iChat server onto everyone’s buddy list.

It seems to be working fine, with the teachers across two sites particularly finding it helpful.