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.


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!

The curse of .local

When Toucan first installed our suite of iMacs, we had a simple Active Directory (AD) integration setup, authenticating and accessing network home folders from our Windows Server 2003  Active Directory.  This worked well, with fast log-on speeds and generally playing properly.  However, over the year the login speeds started to deteriorate.  I originally thought this was because we had installed a Mac Mini server to add some golden triangle goodness to our network, so didn’t investigate much further.  Unfortunately, things took a turn for the worse at the end of October 2011 when all the Macs decided that they wouldn’t log onto our AD any more, instead just showing the red light and ‘Network accounts not available’.

Understandably, this wasn’t so great, especially as one of the reasons for getting some Macs in the first place was that they ‘just work’.  Really bad is probably a better way to put it.

After much Internet research, we managed to get things working a little bit by doing the following:

  • creating computer accounts for each Mac on the AD before binding each machine
  • rebinding each machine, making sure we put in the IP address in Directory Utility where it says ‘Prefer this domain server’ and unchecking the box for ‘allow authentication from any domain in the forest’

This still wasn’t a very reliable solution, with the dreaded network red light still appearing regularly and log-on times taking up to six minutes.  It was like returning to the good old bad days of a decrepit ICT suite of aged XP machines…nooooo!

It turned out that the problem was because our internal domain ended with .local.  Apple uses this for its Bonjour technologies and, despite several possible hacks suggested by Apple (involving mdns_timeout and IPv6), things weren’t getting any better or likely to anytime soon.  Apparently Apple changed the way Macs resolve DNS around 10.6.7/8 in order to get ready for Lion.  The couple of Lion machines we had weren’t working at all with our AD so something needed to be done.

In the end we decided to change our domain.  Not an easy task (so I’m told) so our technician suggested buying a cheap new Windows 2008 Server and setting up a new .sch domain on it.  We would bind all the Macs to that server, leaving the PCs as they were and with the old server still doing all the file sharing for the network homes and shared drives.

We did the transition on a day when no teachers were in and managed to set up a new server and bind 50 machines in a day…not bad!  The only major snag was that all the home folder permissions on any existing network accounts on a machine didn’t work any more, resulting in not being allowed to look in the ~/Pictures, ~/Library folder etc.  Looking back we probably could have figured out how to reset the permissions, but instead we just deleted every account off every machine so that they would get freshly created on login.  Most children’s work gets saved to network folders so we only had to make sure we rescued any iMovie projects or important files saved to teacher’s desktops.

It was a bit of a job to sort out, and we now have two independent yet interconnected domains on our curriculum network, but things are now working much, much better (including our now fully-functioning Lion machines). Our technician is planning to wipe the old server during a holiday so we only have one domain, but I’m sure that’ll be another tale.