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/)

Another thing I like about Mac OS X is [the print preview available in any software][printing] that chooses to provide printing (unless that software [chooses to be awkward][acrobat]).

Best software ever

When this feature first appeared, one could trigger a stupid bug if one happened to have an application other than Preview.app set as the default application for files with the `.pdf` extension. If you had Adobe Acrobat set as your default PDF viewer, then hitting the preview button in print dialog boxes would open that preview in Acrobat.

It was a stupid bug, particularly because it was so obvious what was going wrong. The preview was being written to a temporary file with a `.pdf` extension and then being opened using whatever handler was defined in launch services. But you don’t want that, you want it to be handled by the operating system and not be subject to whether or not you have the patience to wait thirty seconds while Acrobat version 6 merrily paints its splash screen for your pleasure.

Later versions of Mac OS X fixed this so that the print preview is *always* displayed using Preview.app. This happens even if you set Acrobat as the default application for `.pdf` files, and it is a good thing it behaves like this. (In fairness, launch times for Acrobat since version 8 are no longer painful.)

*I tested what happens if you delete Preview.app on a clean 10.5.8 install: the system falls back to opening QuickTime Player.app for displaying previews (which works fine). And if you delete QuickTime Player.app it falls back to using Safari.app (also works fine). And if you delete Safari.app it falls back to TextEdit.app (which works fine as long as you can render raw PDF data in your head).*

It is as if going by the default association between file extension and application was not enough; that the system had a need to use a particular bit of software for these PDF preview files, regardless of what software was chosen as the handler for a different set of PDF files. Who’d have guessed?

All of this is an argument for providing a **programmatic** way to set the owning application for a file. You might call this a creator code, potentially any file could have one, but no biggie if it was not present because you could fall back to some regular stupid heuristic for determining the owner.

And then in Mac OS X 10.6 you might [change the behaviour of the system][106] so that [this useful and important information about the file is ignored][ars]. Grumble.

Dammit, only just occurred to me to see whether the system would eventually fall back to using Acrobat itself for displaying previews. Grumble.

[printing]: http://support.apple.com/kb/HT3771
[acrobat]: http://www.adobe.com/products/acrobatpro/
[ars]: http://arstechnica.com/staff/fatbits/2009/09/metadata-madness.ars
[106]: http://db.tidbits.com/article/10537

[Tim Gaden over on Hawk Wings][hawkwings] [doesn’t agree][agree] that [Mail.app’s behaviour regarding deleting POP accounts is misguided][bomb].

His first point is that Mail.app gives you a big warning before doing the dirty. I don’t think that excuses the bad behaviour. Warning someone that you behave badly does not excuse that bad behaviour (my ex says this rule applies in more cases than the implementation of mail clients).

His second point is that the user should have a backup; with a good backup she can recover from her mistake when all those old messages disappear. I agree that people should have backups, but I don’t think that argument has any weight because you can imagine that the answer for all bad design decisions is “you should have had a backup”, in which case there are no bad design decisions.

The problem is that Mail.app’s insistence on a POP account being a separate set of folders means a message cannot appear in the Inbox unless it belongs to an account. If you delete a POP account then you have to move the messages to the Inbox of another account just to keep them appearing in the Inbox. This does not make sense.

Suppose you have a large history of messages received via a POP account. Then you delete that account and switch to an IMAP service with a meagre storage limit. If you want to keep those old messages appearing in the Inbox you must move your the historic Inbox messages to the IMAP account’s Inbox even though that will take up space on the server (and there may not be sufficient space on the server for them anyway). The other option is to give up the idea that old messages belong in the Inbox and just move them to local folders “On My Mac”.

If Mail.app provided a local Inbox folder that appeared as part of the unified Inbox then my objections would go away. (There should also be a corresponding local Sent folder.)

IMAP and POP are different in that a POP account’s mailbox is really just a temporary queue for messages that have yet to be retrieved by the client. Mail.app should recognize that difference and stop pretending that the two types of account are equivalent.

Quite pleased that Hawk Wings even knows my blog exists. Hawk Wings is good.

[hawkwings]: http://www.hawkwings.net/
[agree]: http://www.hawkwings.net/2010/07/07/mail-apps-disappearing-pop-mail-trick/
[bomb]: http://reliablybroken.com/b/2010/07/apple-mail-bomb/

[Microsoft Entourage][entourage] is such an interesting piece of software. It evolved from (Mac) Outlook Express which was a great mail client for the old Mac OS (despite its grumpy IMAP implementation). Outlook Express itself took many of its design cues from Claris Emailer, to the extent I believe the early versions of Outlook Express were [coded by peeps who had worked on Claris Emailer][emailer].

I always liked that Outlook Express and Entourage defaulted to plain text for messages. I particularly liked the fact that OE / Entourage defaulted to bottom-posting when replying to a message – as any fule kno top-posting is a hideous convention foisted on us by miserable office mail systems back when there was still a chance that your e-mail would not be delivered via SMTP (Exchange version 5 and earlier is the primary culprit here).

I still get annoyed that when using Mail.app hitting the tab key in a plain-text e-mail inserts a tab character instead of expanding it to four spaces like Entourage.

Given enough time this post would devolve into arguments about [top-posting versus bottom-posting][netiquette], the width of [the one true tab-stop][tabs] and how [HTML e-mail][html] has turned our youths’ minds into mush.

[entourage]: http://www.microsoft.com/mac/products/entourage2008/
[emailer]: http://blog.entourage.mvps.org/2007/05/in_the_beginning.html
[netiquette]: http://www.faqs.org/rfcs/rfc1855.html
[tabs]: http://www.jwz.org/doc/tabs-vs-spaces.html
[html]: http://www.birdhouse.org/etc/evilmail.html

[Apple’s Mail.app][mailapp] has an approach to mailboxes for [POP mail accounts][pop] that has never made sense to me. At least, I can see that it is a logical approach, but I don’t think it is a good approach because it can easily lead the user to inadvertently delete messages.

The problem is related to how Mail.app stores messages for an account. For an [IMAP account][imap] (or a [Microsoft Exchange account][exchange]) Mail.app creates a folder on the local disk and creates mailboxes within that folder corresponding to the mailboxes on the server. The contents of those mailboxes are synchronised with the contents of the mailboxes residing on the server. This makes perfect sense because with IMAP because the messages live on the server – keeping a local copy of those messages is effectively a performance optimisation.

What is weird is that Mail.app uses the same strategy for POP accounts, even though with POP there is only one mailbox on the server and it is effectively a temporary store for messages, which is to say that with a POP account a message does not live on the server but moves from one mailbox to another until it reaches its final resting place, that place being on the client.

The only copy of a message received via POP is on the client. (Having said that, [Gmail’s POP support][gmailpop] muddies the waters because [issuing a DELE command][dele] does not actually delete the message from the server, but the principle is the same.)

Now when you go to remove an IMAP account Mail.app deletes all the local mailboxes for that IMAP account. This is not a problem, after all those local mailboxes are simple caches; the only reason the client keeps a copy is as a performance optimisation (as noted above).

Now when you remove a POP account Mail.app deletes all messages sent or received via that account, even though there will be no copy of those messages on the server (especially true for sent messages). This is not useful or intuitive – it is a bad design.

Why is this a bad design? It is a bad design because with an IMAP account you understand that the messages live on the server whereas with a POP account you understand that the messages live on your local hard drive. With an IMAP account you understand that removing the account removes your access to those mailboxes that exist on the server, whereas with a POP account it makes no sense that the act of stopping the retrieval of messages from the account implies that all the messages received via that account and now stored on your hard disk should be removed as well.

Earlier versions of Mail.app had an even more destructive behaviour when removing a POP mailbox. In the version of Mail.app that shipped as part of Mac OS X 10.4, if you removed a POP account then _all messages associated with that account were removed without warning_. Now imagine the not uncommon sequence of events for someone changing from POP account A to POP account B using earlier versions of Mail.app:

1. User accumulates years of e-mail using POP account A.
2. User adds new POP account B.
3. User removes POP account A.

At step 3 the user lost all her historic e-mail! Apple finally realised that this was no way to win friends and so introduced a confirmation specifically warning that messages would be lost before deleting a POP account (this change was introduced with Mac OS X 10.5).

Another unfortunate behaviour is how Mail.app handles a disabled POP account. Disabling an account stops Mail.app from using that account for sending and receiving but also removes all the associated messages from the Inbox.

It is possible to keep an old POP account enabled so that its messages are still displayed but then turn off the preference to “Include when automatically checking for new messages”. This leaves the old account available when composing a new message as a choice in the From field so one must also change the preference for “Send new messages from” to always use the new POP account in order to avoid inadvertently sending a message using the old From address (or edit the from address in the old account to match that in the new account).

[Microsoft Entourage][entourage] has a better approach to this situation: messages for POP accounts are delivered to the Inbox mail folder “On My Computer”, and they stay there when the POP account is deleted. The flaw in Entourage’s approach is that the local folders appear even when all your e-mail accounts are server-based (i.e. all IMAP and / or Exchange accounts). I think it would be better to create those local folders only when a POP account has been defined because if you have only server-based accounts then it is distracting to have a set of folders called “On My Computer” which have no purpose.

[mailapp]: http://www.apple.com/support/mail/
[pop]: http://en.wikipedia.org/wiki/Post_Office_Protocol
[imap]: http://en.wikipedia.org/wiki/IMAP
[exchange]: http://www.microsoft.com/exchange/
[gmailpop]: http://mail.google.com/support/bin/answer.py?answer=13273
[dele]: http://tools.ietf.org/html/rfc1939#page-8
[entourage]: http://www.microsoft.com/mac/products/entourage2008/default.mspx