This article originally appeared in TidBITS on 2004-09-20 at 12:00 p.m.
The permanent URL for this article is:
Include images: Off

Passing the Remote to Apple Remote Desktop 2.0

by Adam C. Engst

For many of us, the days of working with a single Macintosh are long gone. I regularly use my main desktop Power Mac G4, my 12-inch PowerBook G4, the 450 MHz Power Mac G4 that's our internal file and backup server, the PowerBook G3 that acts as a wireless gateway for our long range wireless Internet connection, Tonya's old blueberry iBook that's our kitchen Mac, and our Xserve at digital.forest that runs Web Crossing. Obviously, I access some of these computers directly, but sitting down at others ranges from difficult (the internal file server, which lacks a monitor most of the time), to impossible (the Xserve, which is across the continent). For such Macs, remote control software is essential.

Before Mac OS X, I used Netopia's Timbuktu Pro to control remote Macs, and in fact, I still use Timbuktu Pro 5.2.3 in Classic to control the two servers we still have running Mac OS 8.6. But about the time I became interested in examining remote control software for Mac OS X, Apple had just released Apple Remote Desktop 1.0, and Netopia didn't feel the need to respond to my requests for a review copy of Timbuktu. As a result, Apple Remote Desktop got the nod, and I started playing with it. That initial version was functional, but honestly, not very good, so I never formally reviewed it. When Apple came out with the Remote Desktop 2.0, though, I was extremely interested to see where they'd taken the program and if they'd resolved the irritations I had with 1.0.


Apples and Oranges -- One thing that becomes immediately apparent when using Apple Remote Desktop 2.0 is that it isn't just remote control software like Timbuktu. That program has always focused on the fastest possible screen sharing, and helping you move files back and forth with the specific machine you're controlling. Remote Desktop does much more, including:

You can also set whether non-administrator accounts are allowed to perform any given action within Remote Desktop, which is useful for making sure that certain people don't have full and potentially damaging control over remote machines.

To be fair to Timbuktu, the fact that it lacks some of these features is because Netopia has built them into a different program: netOctopus. And although both Timbuktu and netOctopus support Windows and Macintosh, Timbuktu costs between $50 and $100 per copy (depending on platform and quantity), whereas netOctopus starts at $65 per client, making the pair far more expensive than Remote Desktop, which costs $300 for 10 clients or $500 for unlimited clients.

< mac/>
< netoctopus/>

Remote To Do Lists -- Whereas Timbuktu Pro is designed for a one-to-one interaction, Remote Desktop is designed for one-to-many interactions. That becomes clear when you observe multiple Macs at once, of course, but as soon as you start examining all the items in Remote Desktop's Manage menu, you realize that Apple has given the program a task-based orientation. In other words, almost any task you can perform with one Mac, you can perform with multiple Macs.

This approach turns out to be wildly cool for anyone accustomed to the tedium of performing the same set of tasks on multiple machines, one at a time. For instance, if it's time to update your asset database with the current configurations of your Macs, you can just select them in Remote Desktop's main window, choose Memory from the Report menu, set the options as you want, and run the report to learn the Macs' DIMM configurations. Some reports can take a while, but a status window shows the progress, and a report window pops up at the end with all the information you need.

You can export or print reports out of Remote Desktop, and if they're the sort of thing you want to run on a regular basis, you can set them up to run on a schedule. You don't necessarily have to think in advance that you'd like to schedule a task to run regularly, since Remote Desktop tracks tasks you've run (until you quit), and you can set up the scheduling after the fact.

One particular note: the Remote Desktop 1.0 software that's built into Mac OS X 10.3 Panther doesn't work with Remote Desktop 2.0, but Remote Desktop 2.0 can update the 1.0 client software on multiple remote machines over the network, just like any other task. It isn't even necessary to reboot the remote machines after updating.

V Is for VNC -- One of the most interesting changes in Remote Desktop 2.0 is its reliance on the open VNC protocol for screen sharing and remote control. It means that the Remote Desktop client software is actually a VNC server, and the Remote Desktop application is in fact a VNC viewer.

As a result, any computer with a VNC viewer can control a Mac that has the Remote Desktop client installed and configured to allow VNC access. Since VNC viewer software is available for many platforms, this VNC support makes the Mac fit into a cross-platform network better. Of the available VNC viewers for Mac OS X, I had luck only with the free (and endearingly named) Chicken of the VNC. Why use Chicken of the VNC? As long as you've bought at least one copy of Remote Desktop and upgraded all your clients to 2.0, you can give Chicken of the VNC to people who need only remote control, all without paying for additional copies of Remote Desktop. A free Windows VNC Viewer that I tried - UltraVNC - also worked, though not particularly well.


The opposite situation is also possible: a Mac running the Remote Desktop application can in theory control another computer running a VNC server. I say "in theory" because I spent a frustrating hour trying to control my Windows XP-based PC. At first, I tried the free RealVNC (making sure to set it to use the VNC 3.3 protocol), and even though I was able to control it with Chicken of the VNC, Remote Desktop wouldn't connect at all. Then, based on a suggestion on Apple's discussion forum, I tried UltraVNC's server with no more luck. I may continue to fuss with the Windows VNC servers, just on principle, but for the moment, I'll stick with using Chicken of the VNC to control the PC.


I've used VNC software a number of times over the years, and this experience fits in with my previous encounters. I've usually succeeded in finding some combination of software and settings that works, but it often requires a significant amount of testing and tweaking before I end up with a functional setup. Consider yourself warned. I'm happy that Apple chose to rely on VNC, but as soon as you venture beyond Remote Desktop on both sides of the connection, don't assume the experience will necessarily be smooth.

All VNC enables is remote observation and control, and only with a single computer at a time. So even though you could theoretically control a PC with the Remote Desktop application, you can't include that machine in any tasks or run any reports on it, as you could do with a Mac.

Opening up access to a Mac via VNC is a security concern, even though you can password-protect a VNC-accessible Mac and the password is encrypted in transit. The problem is that the graphical session data transferred back and forth is not encrypted, so an evildoer could conceivably record that traffic and decode it to learn passwords and other confidential information. Luckily, you can tunnel the VNC connection through SSH for additional security. VNC also requires that you open up port 5900 in your firewall. You can reduce these security concerns by running Remote Desktop on only specific occasions; an included kickstart utility lets you launch and quit Remote Desktop via the command line, which you can access via a secure SSH session.

< artnum=108030>

While on the topic of controlling Windows-based PCs, note that Microsoft provides a free program called Remote Desktop Connection that enables Macs to log into and run programs on PCs running certain versions of Windows. Remote Desktop Connection uses Microsoft's Terminal Services, not VNC, and my impression is that Terminal Services works quite well when both computers are running Windows. However, I've tried the Remote Desktop Connection client for the Mac, and although I was able to get it working eventually, it was flaky and proved to be too much trouble to use on an ongoing basis. Your mileage may vary.

< pid=download&location=/mac/DOWNLOAD/ MISC/RDC.xml&secid=80&ssid=9& amp;flgnosysreq=True>

Areas to Improve -- Although Remote Desktop is a solid and capable program with entirely reasonable performance, there are areas in which I'd like to see improvement.

Although remote control performance is good (and it's of course directly related to the speed of your network connection), there is always room for performance improvement. That said, I've had no trouble controlling my Xserve over a 1 Mbps Internet connection. Also, I can't find any way to view the second monitor attached to a controlled Mac, but most of the Macs I want to control have only a single monitor (or none at all).

The most annoying aspect of Remote Desktop for my regular use is that copying files to and from remote Macs is clumsy. To copy to a remote Mac, you must add the files to a dialog (at least drag & drop into the dialog works in 2.0, which wasn't true in 1.0) and choose a location on the destination. That makes perfect sense if you're copying the same set of files to multiple Macs, but if you're controlling a single Mac and just want to slap a file onto its hard disk, you must still work through the dialog. Copying files from remote Macs is even harder; you must run an extremely slow search, and copy it from the find results dialog. Again, this approach is useful for collecting the same file from multiple machines, but insanely bad for working with a single Mac. Timbuktu has allowed users to copy to and from controlled Macs via drag & drop for many years; Remote Desktop should adopt that feature.

Also irritating is Remote Desktop's inability to share clipboard contents with a controlled Mac, something that Timbuktu has again done for years. There is a workaround: Erik Lagercrantz's donationware utility ClipboardSharing enables you to share, even automatically, the clipboard contents of two networked Macs.

< clipboardsharing/>

Although I haven't hit this personally, others find they can't even use Remote Desktop 2.0 because the program quits when launched if you have more than 29 network port configurations - even inactive ones - across all your network locations. It's a known bug that we can hope Apple fixes soon.

< artnum=108041>

Another area where Remote Desktop feels clumsy is its handling of Unix commands. You can send a Unix command to a remote Mac, but forget about getting any relevant feedback in return. The feature is useful for kicking off tasks that don't require user interaction or report back to the user, but that's about it. It doesn't have to be that way - Remote Desktop could easily integrate with Terminal. Similarly, although Remote Desktop lets you view all sorts of information about remote Macs, it doesn't let you view log files on remote Macs. Log information can be extremely helpful when troubleshooting, and once again, Remote Desktop could integrate with the Console application for presenting and searching the logs. As far as I can tell, Remote Desktop also doesn't integrate with the various server management tools for the Xserve either.

To summarize these criticisms, Remote Desktop would benefit from additional attention to the one-to-one communication capabilities that still lag behind Timbuktu, as well as some thought as to how the program could become the control panel from which you manage remote Macs in a variety of ways.

Roundup at the Remote Desktop Corral -- Despite the places where Remote Desktop feels top-heavy for remote control, I have no hesitation in recommending the program to anyone who needs more than basic remote control, particularly if you're managing more than a couple of remote Macs. The people who will most appreciate Remote Desktop are network administrators, help desk staffers, and teachers, I think, but I could easily see consultants and tech support engineers finding Remote Desktop beneficial as well. Anyone buying an Xserve without a video card would probably do well to buy a copy of Remote Desktop, and Apple should consider bundling a limited-client license of Remote Desktop with the Xserve - it would probably pay for itself in reduced phone support.

If all you need is remote control software for another Mac, Remote Desktop is probably overkill; I'd instead recommend either Timbuktu Pro or a VNC viewer/server pair. And if you need a cross-platform solution for more than remote control, netOctopus is probably in your future, expensive though it is for large numbers of clients.

Remote Desktop 2.0 requires Mac OS X 10.2.8 or later, and it costs either $300 for a 10-client license or $500 for an unlimited number of clients. There is no upgrade pricing for owners of Remote Desktop 1.2.