Tag: managed preferences

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!

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.

LGfL 2.0 attempt 1.0

We had quite an ambitious but not unreasonable plan today of switching over our broadband at school to LGfL 2.0 by the end of the day. We nearly managed it, but with several large stumbling blocks.

We started out tackling our admin network, as they only have 13 computers and a server.  This was working quite well until we realised that users could browse the internet but couldn’t access any services from the server (such as shared documents and databases etc.).  Not good.  This is because LGfL 2.0 does web filtering by requiring each computer to use a given external DNS rather than a local one, or something like 8.8.8.8 from Google.  If you set the external DNS first, then you can’t see the server; if you set the internal DNS first, then you can’t see the Internet.  Aaarrrghhhh!

After several fraught conversations with Atomwide we eventually got it to work by getting the server’s DNS to forward external requests to the external DNS.  We had tried this previously, but we only got it to work by completely rebuilding the DNS.

After doing a second sweep of the Admin computers to check they worked properly, we moved onto the Curriculum network.  At first, this seemed pretty straightforward as the old proxy server could be turned off on the PCs with a judicial tweak of the Group Policies and the Macs could be adjusted by pushing out the following commands using Apple Remote Desktop:

networksetup -setwebproxystate Ethernet off
networksetup -setsecurewebproxystate Ethernet off

Bargain.  Changing the DNS settings on the server seemed to be a little more straightforward and soon the Internet was up and running successfully.

Sophos on OSX proved a little more tricky to fix, as I couldn’t convince it to change its preferences with Workgroup Manager.  Instead I had to log onto each machine and put in the new update URL, which is now as follows:

http://sophos10.lgfl.org.uk/escosx

The next big problem then struck, in that the Internet connection was flaking out.  It would sometimes connect, but would then timeout repeatedly.  We tracked down the problem to the fact that both the Curriculum and Admin networks were plugged in at the same time (not unreasonable!).  We’re still awaiting a fix on this from Atomwide, so in the meantime we’ve switched the Curriculum back to our old provider.

Sidebar in Lion

Having got the Lion machines to actually log onto our network, the task was to tweak away the preferences using Workgroup Manager on our Snow Leopard server.

One of my aims for the Macs in the school is that they should be just as easy to use for everyday tasks as a PC was before; it’s no good it being super simple to make a video in iMovie if it’s a complete pain to access the school shared drive.  Putting a shortcut to the ‘school’ shared drive in the Finder sidebar was therefore a priority for me.  I managed to get this to work in Snow Leopard because a mounted network drive appears under ‘devices’ rather than ‘places’ so I just managed those preferences with Workgroup Manager.

Toucan set up our Macs with a log script that renames the ~/Documents folder to something called ‘MacDocuments’ and then creates a shortcut to the user’s network home (i.e. Tim.Lings$ in my case) called ‘Documents’. Without any further trickery, Finder then puts this link to the network home in the sidebar instead of the normal link to the user’s Documents folder.  This is remarkably handy, as default folder for saving files automatically becomes the network home folder rather than a local documents folder.  This is much easier than having to train children and teachers to always save to the network drives.

Now the problem with Lion and the sidebar is that it puts any extra shared drives under the ‘favourites’ heading on the sidebar, along with ‘Pictures’, ‘Movies’, ‘Desktop’ etc.  The clever hack mentioned earlier still works, meaning that my network home folder appears in the sidebar instead of the local ‘Documents’ folder.  Normally to manage the preferences of a feature in OSX, you just set it how you want it, find the relevant .plist file in ~/Library/Preferences (i.e. com.apple.sidebarlists.plist), make a copy of the file, open it with Property List Editor, remove all the XML keys you don’t want to manage, and then import it into Workgroup Manager.  However, this then means that every user would have ‘Tim.Lings$’ in their sidebar, as well as the ‘school’ shared drive as they all lived under that ‘Favourites’ heading in the sidebar.  What to do?

It then struck me that maybe if I changed the key in the preference file to go back to just showing the default ~/Documents shortcut, Finder would swap in the relevant network home drive, as before.  I copied that key from a blank Lion login account and it seemed to work.  Hurrah!