This is an overview of what tools there are for managing a bunch of Macintosh computers on a network. It is intended as a starting point for someone wondering what on earth to do with all those pretty-looking computers the hippie designers like so much.

Basic environment
—————–

You must remove admin access for users, otherwise you cannot be certain where the user data is, and if you cannot isolate the user’s data then you cannot trust that updating the system won’t delete their stuff.

You really need to have the Macs bound to a directory and have account info stored in the directory. This means you don’t need to create and maintain local accounts on each Mac. It is also makes life much simpler when you need to migrate data from one Mac to another because the account uid/gid will be persistent.

Mac OS X Server
—————

The server version of Mac OS X includes a [software update server][sus]. By hosting your own local copy of the Apple software update server you conserve network bandwidth and you get to withhold what updates are presented to the Mac clients should you want to.

You also get to use Apple’s directory service and to control policy with MCX.

You don’t necessarily need OS X Server, but it is very useful.

[sus]: http://support.apple.com/kb/HT4069

Reporting and management suites
——————————-

From there you have a bunch of approaches. Big environments (educational) use things like [Radmind][1] and [Puppet][2] to enforce software load-sets across hundreds, thousands of Macs.

For small network sizes people use [Apple Remote Desktop][3] (ARD) and/or [Casper][4]. ARD is extremely useful whatever you decide to use because the administration software includes remote desktop stuff so the help desk monkey can take over the user’s screen, fix the problem and put the telephone back down.

Although these tools handle reporting, remote installations, running scripts, batch configuration, etc. you still need to spend a lot of time building installation packages. You need a base system image that can be quickly deployed to a Mac, and you need additional images or installation packages containing the various software that goes on top.

[1]: http://rsug.itd.umich.edu/software/radmind/
[2]: http://www.puppetlabs.com/
[3]: http://www.apple.com/remotedesktop/
[4]: http://www.jamfsoftware.com/products/casper-suite

Deploying system software and applications
——————————————

To build system restore images use [InstaDMG][5]. Much better than everything else.

What you want for deploying software is some form of un-attended network push. This means the software installation has to work with access via SSH, whether the user is logged in or not and needs to succeed when installed as root.

With luck your software vendor already uses well-behaved package format installers (i.e. Microsoft most of the time). Or the software is a self-contained app so it can be installed and updated by copying it to /Applications (maybe you go to the trouble of making a pkg for it first).

But flipping heck Adobe hates Mac administrators. The Adobe Creative Suite installers (including those on volume license media) are absolutely useless. The updaters are even worse. [Adobe provides a volume deployment kit][6] which is bafflingly obtuse and which doesn’t actually work for the admin’s most important installation scenario.

Casper and [LANRev][7] include tools for building pkg installers from the Adobe media. Adobe’s enterprise kit supposedly does the same thing. The other thing you do is build your own pkg from what gets installed. That isn’t too painful, but having to build your own update pkgs for the numerous Adobe updates is painful.

(The [Apple Installer-Dev list][8] is full of developers trying to work around bugs in PackageMaker that crop up as soon as you want to do anything other than copy files to disk. Many admins prefer [Iceberg][9] or [Packages][packages] and other software for building installer packages.)

[5]: http://code.google.com/p/instadmg/
[6]: http://www.adobe.com/devnet/creativesuite/enterprisedeployment.html
[7]: http://www.lanrev.com/
[8]: http://lists.apple.com/mailman/listinfo/installer-dev
[9]: http://s.sudre.free.fr/Packaging.html
[packages]: http://s.sudre.free.fr/Software/Packages/about.html

System configuration and user preferences
—————————————-

To some degree you configure the system as part of building the base image. Things like have the Mac automatically configure the network, bind to a domain, set power-saving mode, disable auto-login, etc. should all be part of a first-run script that happens when a new Mac is switched on.

In general you should avoid changing the default settings for everything else, either per-Mac or per-user. Saves you much hassle.

Most software these days uses plist format and reads the settings from the correct places (even recent versions of Office are good at this). Adobe of course doesn’t, but I have infinite patience. Assuming all the prefs you need to manage are in plist format, you either just run scripts to set things on an ad-hoc basis or you enforce policy with login hooks. If you use [Open Directory to manage Macs][10] you can use the Mac OS X Server tools to push settings to all users. Since 10.5 you can [use each Mac’s local directory in much the same way as Open Directory to manage settings too][11] (although you need to then handle updating each Mac yourself).

You can use [login/logout hooks][12] which run for each user. You usually find if you run a system-wide script to adjust per-user settings that at some point you mess up the permissions, no matter how careful your script is. The other approach is to use [per-user launchd scripts][13], although they were effectively broken in 10.4 and not much better in 10.5. The [launchd man pages][launchd] are required reading even so.

[10]: http://images.apple.com/server/macosx/docs/User_Management_v10.6.pdf
[11]: http://www.afp548.com/article.php?story=using-mcx-in-the-dslocal-domain
[12]: http://support.apple.com/kb/HT2420
[13]: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/Articles/LaunchOnDemandDaemons.html
[launchd]: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man5/launchd.plist.5.html

Interesting bits
—————-

– Mac OS X Server docs: [http://www.apple.com/server/macosx/resources/documentation.html](http://www.apple.com/server/macosx/resources/documentation.html)
– Macos-x-server mailing list: [http://lists.apple.com/mailman/listinfo/macos-x-server](http://lists.apple.com/mailman/listinfo/macos-x-server)
– Munki, for deploying software: [http://code.google.com/p/munki/](http://code.google.com/p/munki/)
– DeployStudio, like Casper: [http://www.deploystudio.com/Home.html](http://www.deploystudio.com/Home.html)
– AFP548, fantastic tips: [http://www.afp548.com/](http://www.afp548.com/)
– Mike Bombich, admin: [http://www.bombich.com/](http://www.bombich.com/)
– Greg Neagle, admin: [http://managingosx.wordpress.com/](http://managingosx.wordpress.com/)
– Preston Holmes, admin: [http://ptone.com/dablog/](http://ptone.com/dablog/)
– MacEnterprise mailing list: [http://www.macenterprise.org/mailing-list](http://www.macenterprise.org/mailing-list)
– MacManagers mailing list: [http://www.mac-mgrs.org/](http://www.mac-mgrs.org/)
– Adobe installer blog: [http://blogs.adobe.com/oobe/](http://blogs.adobe.com/oobe/)