Volume Number: 20 (2004)
Issue Number: 12
Column Tag: Programming
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 Directory domains.
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
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.
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.
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 (jwelch@provar.com) 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.
