An Apple Remote Desktop Critique
Volume Number: 20 (2004)
Issue Number: 12
Column Tag: Programming
An Apple Remote Desktop Critique
ARD is Much Better in Version 2.1, But Still Needs A Lot of Work
by John Welch
As you can tell from the title, this article is going to be a critique of Apple's remote system
management tool, Apple Remote Desktop, or ARD, to the, well, ARD cognoscenti. While it is,
especially in version 2.1, a much improved tool over earlier versions, (it's actually useful to more
than just K-12 lab Admins now), it still has a few critical areas that need work if it is to move
into the next level.
ARD needs to be bundled with Mac OS X Server, period. To sell a server that can handle thousands
of clients, and then give no way to manage those clients without laying out another few hundred
dollars is silly. If I'm buying an Xserve, I need client management tools. It's not like Apple has
to license it, and there's no problem with selling it separately, but it needs to be shipped as part
of Mac OS X Server. I still see people on mailing lists trying to do things manually, when ARD would
be a great help, but after having spent money on Server, there's sometimes a bit of a hurdle getting
another P.O. approved because Apple doesn't' think you need client management tools as a part of
their server. Compare this to Active Directory, which ships with basic client management as part of
Windows Server. Bundling ARD with Mac OS X Server would fill a basic need of network administrators
everywhere. (Yes, Apple does ship SSH with Mac OS X, and they do have excellent command line tools.
However, the documentation for those tools is a bit...shall we say light.)
Even better: integrate ARD in with Server Admin and Workgroup Manager. This would allow an
administrator, when setting up a remote client or user in Workgroup Manager, to easily bring up the
client in an ARD window, and test out the various login settings, MCX settings, etc. Integration
with Server Admin would allow administrators to better deal with various tools that work better when
you can see the screen, or allow administrators who are not yet comfortable with the command line to
not have to start swimming in the deep end of the pool, with the drain suction on 'high'.
Another issue for the enterprise is the pricing. At first glance, ARD is one of the cheapest
tools out there. However, that's more for if you have a single, or very limited number of
administration workstations. In a large network, or an enterprise setup, that's not always going to
be the case. If you need multiple administration machines, ARD's price starts to go up in $500US
increments. What is needed is perhaps an "Enterprise" version that would allow for unlimited
administration workstations in a root domain, so for example, you could have unlimited
administration workstations for company.com, and that would include all the subdomains a company
might have, like nyc.company.com, etc. This could be based either on DNS, or (more logically), Open
Another area where ARD suffers is in automation. True, you can now run shell commands directly on
clients, but that's a rather manual process. There's no provision for kicking off other commands
based on the results, because the ARD itself cannot be scripted, via shell, or AppleScript. Which
means that while I can run softwareupdate -l on 500 Macs, I can't have the results of that kick of
any automated update process. Automation is critical to administrators, because as your client base
goes up, your workload tends to increase by multiples of that increase. A tool that almost lets you
automate, or forces you to have manual steps with what little automation it allows you to do is
almost a hindrance, not a help.
ARD needs full OSA and shell support, so that automation can happen independently of language
provisions. Mac OS X is living in a world of shell, AppleScript, python, Perl, and . While it would be ridiculous to expect Apple to create interfaces for a dozen different
languages, full OSA support, (including the ability to directly use shell as an OSA language,
something long overdue in OS X), would create the interface so that administrators could use
whatever language they feel most productive with, or need to use for their specific workflow.
By implementing OSA support in AppleScript, ARD would become a much better, and more capable
tool. If you look at almost any other administration tool on any other platform, they're all
scriptable. In fact, there are sites devoted to custom implementations of things like Active
Directory tools, Nagios, MRTG, etc., and almost all of them are collections of scripts that someone
else decided to donate to a larger community so that their work could benefit others. This kind of
community is critical to administrators using those tools, but there's no way to do this kind of
thing in ARD.
Directory Service Integration
Mac OS X Server is based on Open Directory, so is Mac OS X. Open Directory is at the heart of
everything Apple does for managing machines, yet ARD is resolutely ignorant of Open Directory.
Again, yet another way that ARD makes life harder than it should be on its users. There needs to be,
as part of integration with Server Admin, a setting that allows you to assign usage privileges to
ARD based on user and group settings. So you could create an ARD administrator group or groups, each
having different levels of access. This way, creating a new ARD user is a matter of drag and drop in
Workgroup Manager. This doesn't require the upcoming ACL structure in Mac OS X 10.4, aka Tiger.
Those of course, would make it simpler, because ARD privileges could be a separate ACL setting,
which could be applied across a directory.
This is not to say that ARD should require an Open Directory setup to function. That would be
just as big of a mistake in the opposite direction. But the need for a client management tool to
plug into the client management infrastructure is too obvious to ignore.
Interface and Functional Issues
The rest of any problems with ARD are interface/functional issues. For example, while copying
files from the administration workstation to clients is quite simple, copying files from the client
to the administration workstation forces you to do a find, find the files you need in the result of
the find, click copy, then pick the destination. While this is great if you need to copy one or two
files from a couple hundred workstations, that's not how that particular operation works in a large
percentage of cases. (Where you see that particular model used the most is in a lab setup. However,
Apple networks aren't just for K-12, or Higher Ed labs anymore, and tools like ARD need to reflect
this.) For a single file, or folder, ARD should just let you drag it from the client workstation to
the administration workstation the same way that you would move files and folders from a network
share to your local hard drive. This is also where a scripting interface would be more than a little
handy. Being able to use the Unix locate or find tools with ARD would not make administrators cry.
While it's great that Apple is using VNC as the low-level protocol, they haven't done a lot to
help ARD users who are not familiar with VNC to more easily get ARD talking to Windows or Linux
boxes running VNC. Again, the mailing lists are full of the same kind of question, which shows the
difference between merely making a feature available, and making it useful. Spending a little more
time to make using the VNC feature easier would pay off quite well.
ARD also needs to talk to other installers. Yes, in a perfect world, (or at least Apple's
definition of one) we all use drag and drop disk images, or Apple's Installer. However, in the real
world that we all have to work in, we don't. For example, since Installer VISE is cross platform,
and Apple's Installer is not, it makes little sense for a company like Adobe, where you have a great
deal of similarity between the Mac and Windows versions of their software, to not use an installer
technology that saves them time and money by allowing them to use one tool for all their installer
needs. Apple needs to recognize this, and either integrate both Allume's Stuffit InstallerMaker, and
MindVision's Installer VISE into ARD, or build a plugin architecture into ARD with a proper API so
that third parties can extend ARD as needed. (The plugin architecture, while not the best short -
term solution, ends up being the better long-term solution for this problem, and every other problem
that we haven't even encountered yet. Just ask Adobe and Quark about how beneficial plugins are.)
The "just install and image" or "just install, then repackage" arguments are workarounds for NIH,
not solutions for the enterprise, (whatever your definition of 'enterprise' is. I worked at MIT,
I'll put their network up against any similarly sized corporate network any day of the week. '.edu'
does not mean 'tinkertoy'.)
Another issue is security. ARD needs to be able to connect through SSH tunnels as a basic
functional part of the client and the administration workstations. SSH ships with Mac OS X, and
should be integrated into the connection setup by default. Any kind of administrative connection
across a network of any kind needs to be secure by default, and by known, trusted measures. Since
Mac OS X and Mac OS X server ship with multiple secure authentication and encryption methods, (SSH,
SSL, Kerberos), and Apple uses SSL in its other administration tools, such as Server Admin, there's
little reason for not having ARD plug into these methods as well. It's one thing to say "It's
secure, trust us" and another thing to say, "It's secure, here are the industry standard methods we
use". (Note: Yes, I'm aware that you can manually tunnel ARD or anything else through SSH. That's
not the point. It shouldn't require manual or even shell scripted setup. It should be an
enabled-by-default checkbox on the install, enabled by default in the client and administration
configuration, and enabled by default in the usage. Secure modes of operation need to be the
unconscious default, not the manual option.)
Again, ARD has steadily improved throughout its history, and the features in version 2, now 2.1
are enough of an improvement for me to switch over to it from Timbuktu. The integration with VNC was
brilliant and obvious, and I'm glad to see that Apple agreed with everyone else on this.
Most of what I base this critique on are things that constitute the "last 20% of excellence".
(From the idea that the first 80% of work on a product make it functional and 'good enough', but
it's the last 20% that make it "insanely great". Microsoft is the master of the first 80%, but Apple
is the master of the last 20%, and that difference shows in almost everything they do.) ARD is so
close to being one of the top - notch client management tools on any platform (and on every platform
with VNC), and with just a little massaging, it'll get there.
John Welch (firstname.lastname@example.org) is an IT Staff
Member for Kansas City Life Insurance, a Technical Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt,
(http://www.tackyshirt.com/. He has over fifteen years of
experience at making Macs work with other computer systems. John specializes in figuring out ways
in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior
administrative platform, and teaching others how to use it in interesting, if sometimes frightening
ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.