Summary

Accessing Mac OS X Remotely Using Apple Remote Desktop

One highly useful, but oddly unsung (except in the halls of system administrators) application for accessing and managing Macs remotely is the Apple Remote Desktop application, or ARD. ARD was born of a desire to provide a flexible way for administrators to manage (possibly many multiple) remote machines, in an environment where large portions of the interface require graphic interactions. The basic question was to find a way to share screens, keyboards and mice, so that an administrator sitting in her office could attach to a remote machine and interact with it as though she were sitting at its keyboard, viewing its monitor.

This question, and possible solutions to it, have been through several iterations over the years, but Apple seems finally to have settled on a solution that not only makes the Mac easy to administrate from a remote location, but also makes it easy to interoperate with the ubiquitous VNC shared-desktop solution that is available for Linux, Windows, and most other operating systems. With the release of ARD 2, Apple's solution is clean, elegant, interoperable, and provides many features that go beyond simple desktop sharing, and that makes ARD an indispensable tool in any administrator's arsenal. Apple's own documentation of ARD spans 116 pages, and might be considered light on detail in many places, so we can't hope to cover all ARD features in which you might be interested in this book. Instead, here we will hit the highlights that can help you decide whether ARD is for you, and if it is, try to cover some of the details that might help with remembering some of the less expected features.

Understanding the Features and Limitations of ARD

ARD comes in two simple-to-assemble pieces: the ARD client, which is installed by default on all Mac OS X Tiger (and Panther) workstations, and the administrative application, for which Apple charges the princely sum of $299 for 10 clients, or $499 for unlimited clients (http://www.apple.com/remotedesktop/). For the home user who simply wants a way to monitor or control a remote computer, these prices might seem steep, and a simple, freeware solution such as VNC (http://www.realvnc.com/) might be a more appealing option. For the administrator who needs to manage multiple machines, the additional features of ARD make it a must-have application that would be cheap at 10 times the price.

In addition to providing a way to share desktops and controls with a client computer (a task that can be easily accomplished with VNC), ARD allows administrators to observe an (almost) unlimited number of remote desktops simultaneously, or to completely take control of a remote machine and to lock the controls so that the person actually at the keyboard can only observe. Alternatively, the administrative user can also share her desktop out to the client computer to observe, for those instances where demonstrating something on a local machine is easier than doing it on theirs. Or, if it's a different remote user who can demonstrate the task best, you can select one remote user's screen, and share it to other remote users for viewing.

ARD also provides a number of nonobservation remote-control features that are, perhaps, even more important than the raw ability to interact with the remote computer graphically. These include functions such as sleeping, waking and restarting target computers; sending pop-up-window messages to remote computers; Locking the screen of remote computers; copying files to remote computers; running pkg/mpkg software installers on remote computers; running Unix shell commands and shell scripts on remote computers; specifying startup information on remote computers; collecting a wealth of system information on remote computers; and searching for files on remote computers; and many others. Although most of these might sound like things that you have learned how to do with a remote terminal session, the important feature here is that each of these actions can be performed on one remote computer or on any number of selected clients simultaneously. Even better, the actions can all be scheduled such that they happen (or repeat) at a particular time, so you don't even need to be there to press the button when they happen.

Need to reboot all of your machines at 10:00 p.m. because a server will be being rebooted then? Select them all, click the reboot button, and schedule the action for 10:00 p.m. Go to dinner and a movie, and check your ARD status at midnight when you get back. In the morning, you can impress your boss with your diligence for staying late and running all over the company hitting reboot buttons.

Just got a call that there are possibly malicious network probes coming from one of the lab machines you oversee, the machine's on the other side of campus, and it's raining? Either click the Observe button and take a look at what's going on, select the machine and shut it down, lock the screen, kick the current user off the machine, or whatever remedy you prefer. If there are multiple machines at the same location, select them all and lock them all down for good measure if you have a physical intruder you don't want them just moving over to the next computer on the bench!

Need to install the latest iChat update on your client machines so that you can do a better job taking service calls over the network? Select the targets, click the Install Packages button, and toss in the iChat update. You can even roll your own mpkg installers using the Developer Tools PackageMaker application, allowing you to bundle up multiple pkg installs into a single sendable install action.

All in all, ARD provides features that could make it one of the best tools in an administrator's toolbox. It does, however, have some peculiar quirks, some annoying misfeatures, and one glaring omission that prevents it from being a one-stop-shop for administration goodness.

Among its quirks are the fact that it's oddly slower than standalone VNC clients, even though it seems to use VNC as a base transport, and that it has a peculiar sense of which keypresses should be interpreted as keyboard events to send to the remote machine and which are intended to go to the ARD application itself. For example, if a view of an ARD client is the frontmost window on your screen, and you press Command-Q, what do you expect to quit? So far, the actual behavior quitting the frontmost application on the client computer, has not been the behavior that my fingers were expecting, although one could excuse this as a user-training issue. On the other hand, if you're viewing a client screen, and you press Command-Shift-3 to take a screenshot, do you expect a screenshot of the client screen, or of your screen, viewing the client screen? If you guessed that it'd take a screenshot of the client screen, you win the consistency-in-user-interface-design award, and lose the predicting-what-it-actually-does competition.

Chief among the misfeatures is the fact that ARD defaults to VNC screen ID zero, and provides no way for you to change this default. VNC was originally designed for the X Window System (refer to Chapter 17, "Using X Window System Applications"), and the X Window System display abstraction allows that there can be multiple displays attached to a single computer. As a matter of fact, it expects multiple displays, some of which may be local and some remote, and that any given user may not have permission to see some or all of the displays.

Therefore VNC incorporates the idea of screen IDs to allow the system to identify what screen and GUI a user is trying to connect to. On PCs, and Macs that aren't running an X Window session, ID zero is a fair bet for what ID VNC might grab for itself, but on a machine that's X Window capable, such as a Linux box, or an Mac OS X machine running the X Window System, ID zero will rarely be available, and a user's VNC session will almost always be something other than zero. ARD currently provides no way to connect to these non-zero-ID displays, and so can effectively only be used with non X Window System machines. Circumventing this limitation is possible at the client (by making VNC and X Window System run on nonstandard screen IDs, or by using a hokey VNC client that attaches to screen zero, rather than creating a new one for each user), but even using atypical VNC configurations that can attach screen zero, ARD will be incapable of connecting to any alternate VNC screens that may be available on the machine.

The glaring omission, which despite the fact that ARD is quite useful, limits it to being far less useful than it potentially could be, is the lack of any way to share the clipboard between machines. This is oversight is so fundamentally wrong, that one would be forced to the conclusion that the lack of functionality was either a bug, or a misunderstanding, except for the number of ARD users who are all unanimously cursing this problem. The only workaround we've stumbled on so far is to run iChat between your administrative machine and the remote machine as well, and use iChat as a copy/paste buffer for things you need to move. It feels rather stupid to sit there and have a conversation with yourself just to move URLs around between computers, but so far, it's the only solution we've found.

Activating Remote Desktop in Tiger

The ARD client module is activated by a simple check box in the Services pane of the Sharing Control Panel. Like other services on the services pane, check the check box, and ARD switches on, and connections are enabled. If you select the Show status in the menu bar check box that appears when select ARD, another status menu is added to the right of the menu bar. The icon for this looks like a pair of binoculars, and depending on other settings, provides a visual notification to the user that his machine is being watched or controlled.

To configure what remote ARD administrators can do, select ARD in the Sharing pane and then click the Access Privileges button that appears. Figure 21.16 shows the interface for configuring access privileges. On this sheet you can select what users are allowed to connect using ARD, and what they are allowed to do when connected.

Figure 21.16. In the access privileges sheet for ARD, you can configure a number of privileges or limitations on the administrative user.

For each user on your system, you can enable and disable her ability to connect from a remote machine running the administration interface. Unlike desktop sharing applications like VNC, this setting does not enable a different login and session for each of these users, but rather, whether each (or any) are allowed to connect to and to view the desktop for any user who is currently logged in at the console. Against expectations (although completely logical in terms of how the interface is shared), the only setting/limitation that ARD takes from the account settings of the particular user that you select is the username and password. That is to say, you can have a user who is a severely limited managed user, with restrictions to the Simple Finder, and many Parental Controls engaged, and if that user connects using ARD while you are the user logged in at the console, the screen that user gets is yours, and access limitations to which that user is restricted are the ones configured for your user and the ones configured in the access privileges sheet in Figure 21.16.

The ARD administrative interface makes a nod to trying to ameliorate this disconnection of privileges and users, by allowing the ARD administration software to be configured to deny access to anyone who's not in the admin group on the computer. Unfortunately, Apple's default setup of making every computer owner into an admin-group member reduces this limitation to insignificance. Anyone who can boot a machine into a mode where they are the owner, and therefore an admin-group member (as in a default install of Mac OS X, perhaps booted off of an iPod), can tweak the settings on ARD to allow them complete control of a remote machine, even if they have only managed-access while physically at that remote machine.

CAUTION

To reduce the obvious risks involved, Apple recommends that special ARD-only users be set up on ARD client computers, and only these ARD-specific users given permission to access the machine remotely. This eliminates the problem of a low-privilege user being able to connect to the running session of a high-privilege user, but it is security that's entirely dependent on you configuring it properly, rather than something that Apple configures properly from the start.

Other privileges that can be configured (on a per-user basis, in terms of who can connect, although there is currently no provision in the ARD administrative interface to have multiple user configurations for a single machine), are as follows:

• Generate Reports When enabled, the selected user can use the reports function of the ARD administrative tool to pull down rather detailed reports about the settings, contents, and status of your machine.

• Open and Quit Applications When enabled, the selected user can launch applications through ARD. Note that this is a different meaning of launch applications than simply clicking on the application on a remote-controlled desktop. Even if this is disabled, a user with Control permission can still use the Finder to launch applications. Enabling the open/quit apps option allows the user to target this machine in the remote ARD interface for an application launch task. Using these tasks, a remote administrator can launch the same application on an entire room full of (ARD Client) Macs, simultaneously.

• Change Settings Again, this doesn't limit what the user can do though a controlled session, but rather whether the user can tell the ARD administrative interface to change the ARD settings on this client computer, as part of a Change Settings Task.

• Delete and Replace Items Whether the user is allowed to issue Copy, Install, and Empty Trash tasks from the ARD administrative interface. This must be enabled if you want to be able to upgrade client ARD versions automatically from within the ARD administrative interface.

• Send Text Messages Whether an administrator, connected as this user, is allowed to send pop-up messages, or invoke the Chat function.

• Restart and Shut Down Whether an administrator, connected as this user, is allowed to issue Sleep, Wake, Restart, and Shutdown commands. This must be enabled if you want to be able to upgrade client ARD versions automatically from within the ARD administrative interface.

• Copy Items Whether an administrator, connected as this user, is allowed to target this computer with Copy Items and Install Package tasks. This must be enabled if you want to be able to upgrade client ARD versions automatically from within the ARD administrative interface, or if you want to be able to change the client ARD settings from the ARD administrative interface Change Settings task.

• Observe Whether an administrator is allowed to view the current desktop using this user's username and password. There are degrees of observation available. Selecting Observe alone allows the administrator to watch, but not otherwise interact with the current desktop session.

• Control Whether an administrator, connected as this user, is allowed to control the current desktop session. A user with Control privileges can not only watch what's happening on the desktop, but can also take control of the mouse and keyboard, or lock the screen and lock out the current user. This must be enabled if you want to be able to upgrade client ARD versions automatically from within the ARD administrative interface.

• Show When Being Observed Whether the ARD status menu icon should change when this user connects, to reflect that the machine is being observed or controlled. The use of this, like the configuration of the users, is counter-intuitive. You might imagine that if you're an admin-group user on the local machine, you'd want to know if someone was watching your machine using ARD, and that if you were configuring managed users, you might not want them to know they were being observed. Unfortunately, there appears to be no way to enact that control. If you try to use this check box in that fashion (and more than a few ARD admins have tried), what you'll do is configure your machine so that any time your admin-group user is watching the computer remotely, anybody who's at the console is immediately informed, and any time your limited-access managed user is watching, nobody will know.

In addition to per-user controls, you can configure several general ARD client settings:

• Guests May Request Permissions to Control Screen When selected, the ARD client will allow remote administrative users to request control, even if they don't have a local user ID and password with which to connect. You can use this setting to allow, for example, help-desk people to connect momentarily to your machine to make a quick configuration change or to help find a well-hidden setting in a program with which you aren't familiar.

• VNC Viewers May Control Screen with Password ARD seems to run over VNC (http://www.realvnc.com/) as a base transport system. This is convenient in two ways: It allows the administrative interface to view and control VNC client computers in addition to ARD client computers, and it also allows ARD clients to serve their screens out as VNC sessions to which a VNC viewer can connect remotely. This means that even if you don't have the ARD administrative software, you can still install a freeware VNC viewer, and (if you've selected this check box) take remote control of your machine. You won't have access to any of the ARD administrative interface niceties, but you will be able to view and interact with the current desktop session from remote.

There are also four user-configurable text-string settings that you can use to provide helpful identifying information in the reports, so that you aren't left trying to find the physical machine that's attached to a virtual desktop, armed only with an IP address.

TIP

Remember, ARD is stuck on VNC screen ID zero, so you'll need to point your client software at this ID to connect.

CAUTION

Be aware, if you enable VNC access, that the default VNC network transport is not secured in the same fashion as ARD, and that the password, as well as any interaction you do between the machines, can be sniffed off the network with relative ease. Apple claims that traffic between native ARD clients and the ARD administrative interface is encrypted with 128-bit AES, but we've seen very little documentation or discussion of this topic.

Controlling and Observing Remote Desktop Stations

The administrative interface component of ARD is simple, and with only a few exceptions, intuitive to use. Administrators are presented with either a list of configured machines, or semi-live screen views of a selection of machines. Selecting one or more machine in either interface will allow you to target them for ARD administrative tasks such as installing software or generating reports. Although the same administrative tasks are available from the menu bar in each view, the tasks that are available in the icon bar of the screen-views machine list, is very limited compared to the tasks that are available in the machine list view.

Figure 21.17 shows ARD viewing semi-live (updated about once every second or so) screens from three computers. The one in the upper left is a VNC session coming from a Linux box, whereas the other two are ARD clients in Tiger. In the Toolbar across the top of the screen are icons that let me configure the way the semi-live multi-screen view works and take control of any of the machines I'm viewing. At the left of the screen, the binoculars, concentric-circle target-like icon, thumb-tacked document, and lock icons, respectively allow me to observe (in closer to real-time) a selected machine, take control of a selected machine, send a pop-up message to any number of selected machine, and lock the screens on selected machines. At the top right of the screen are sliders that control the color size of the live previews, the refresh rate for the previews, and the color-representation quality on the previews. If I have enough live previews going that I can't see them all on the screen at the currently selected size, the left/right arrow buttons in the very top-left corner activate, and I can page between multiple pages of previewed screens.

Figure 21.17. The multiscreen live view window (created by selecting multiple machines and clicking the View icon), lets you view the running desktop from multiple machines simultaneously.

Figure 21.18 shows ARD viewing the list-view of configured machines. This view doesn't provide the friendly live-preview feature, but it also consumes far less network bandwidth to produce, and it provides additional useful details regarding each machine. In this list you can see that I have one VNC client, two ARD clients to which I can connect, and one ARD client that's currently refusing access. Apple uses many graphical cues and icons to condense various status information into digestible bits many more than can be documented here. The interested reader is directed to the ARD manual that comes as part of the help system for the software.

Figure 21.18. The List view of machines is used to view various identifying parameters for the machines, as well as to issue a larger number of one-click task assignments to clients.

In addition to viewing screens and taking control, the Toolbar in this interface (by default) allows you to send your own screen to target computers; sleep, wake and restart target computers; send pop-up messages to target computers; lock the screen of target computers; copy items to target computers; install pkg or mpkg packages on target computers; execute Unix commands on target computers; configure target computer startup disks; get a system-overview report from target computers; and search all target computers for a particular file or files. The tasks that can be sent directly from the toolbar are configurable from a Configure item in the Window menu.

At the bottom of the window is a list of recent and pending tasks that have been executed by this administrative interface on the client computers. Several tasks have finished. One that's searching for a file is still working on generating a report, and one is queued up waiting for the file search to finish. These tasks can be saved for future re-use, or re-executed (possibly with minor modifications) as needed simply by double-clicking them, selecting the Duplicate Task option, and sending the duplicate off to be executed again.

At the left of the window is a panel that manages lists of things. This panel is one of the least intuitive aspects of the ARD interface. It is primarily devoted to managing lists of computers, but it also is the place to go to look for the list of saved Tasks. The lists of computers themselves are also not entirely identical in intent, creating a hierarchy of functions between them with no way to impose the hierarchy onto their display.

For example, you can only view and control machines that have been added to the Master List. You configure these machines by either dragging them out of the default scanner (if the default scanner can find them) in to the Master List, or by double-clicking them in the scanner. Either way you will be prompted for a name for the machine, and a username and password with which to connect. This is the user and password against which the permissions configured in the Services/Remote Desktop/Access Privileges sheet on the client, are compared. If the default scanner cannot find the computer, you need to create a new scanner, and give it enough information to find the computer you want (configuration of scanners is a complex topic, and interested readers are referred to the ARD manual for more information). This situation is confusing because the machine list produced by a scanner is almost identical to the machine list displayed for the Master List, and even interface features such as the Toolbar remain the same, but the behaviors and functions that are available when you select a computer are different.

Selections of machines that have been added to the Master List can have additional machine lists created to hold just them, conveniently allowing them to be selected and acted upon as a group. There's no good way to filter the machines on the Master List to select related machines that you might want. So, peculiarly, if you have lots of machines to work with, the most effective way to group them is to add them to the Master List, create a custom scanner that finds just the group you want, select them all from the Scanner, and create a custom list from that. Because they're already added to the Master List, they'll go into a custom list as a group, without further configuration effort.

Another point of confusion is that there is no way to configure multiple instances of the same machine in the Master List. Because you can configure multiple users with different permissions in the ARD client interface, it would make sense that you might want to be able to select among these in the administrative interface, perhaps using a user ID that has been assigned only nondestructive permissions for most day-to-day interactions with your clients, and reserving connections as an administrator with all privileges enabled for those times when there is more drastic work that needs done.

Alternatively, you might want to have two different users that have the Show When Being Observed option set differently, so that you can monitor your computers without detection when it's appropriate, and also have the option of letting users know that they're being observed, for normal operations. So far, this capability is missing. If you want to change the user you're using to connect in the ARD administrative interface, you need to Get Info on the configured computer in the Master List, edit the settings, and change the userID and password you're using to connect. You then need to close any open connections to the machine and re-open them. We hope Apple decides to change this in the near future because it's number 2 on our dumb omission list, right behind the lack of copy/paste functionality.

Double-clicking a machine in either the multimachine live view, or the List view of machines, opens a control window directly to that machine. Figure 21.19 shows a monitored client machine, as seen in an ARD administrator's window. The client's actually running a 21'' monitor at 1600x1200, and my laptop is only capable of 1280x854, but ARD scales the remote display nicely, allowing it to run surprisingly well in a window on my laptop. Across the top of the window are buttons that configure the type of interaction I have with the remote machine. Clicking the leftmost one would allow me to take control of the machine (right now I'm just observing, although it's difficult to tell that the control button is deselected in a black-and-white printout on paper).

Figure 21.19. Watching a client computer using ARD. From this interface I can view the client without interfering at all, or take complete control of the interface, as necessary.

If I am controlling the machine, I have the options of locking out the user at the keyboard and controlling it exclusively, or of sharing control with the user at the keyboard. The second button at the top left of the window configures this behavior. The button with the four diagonally pointing arrows, configures whether ARD should scale the remote screen into my local window or deliver it at full size, and let me scroll around to get to the parts that don't fit in the window. I find the scaling option to be surprisingly useful for most situations, but if you're trying to help a remote user do pixel-perfect object placement in PhotoShop, there's no substitute for a real 1:1 look at what's happening on their machine.

Finally, at the right of the Toolbar is a quality slider that lets me control whether the remote screen is delivered to my administrative interface in full color, surprisingly good reduced color, grayscale, or dithered black and white (which will give you an idea of what the original Mac display looked like, although the GUI controls are obviously not well designed for living in this mode today). To keep the display interactive, while not putting too large a burden on the network, I've usually found it useful to use the grayscale option, or sometimes even the dither black and white setting. This improves the interactivity of the display considerably, at the cost of losing legibility of interface elements that depend on color or on shade. Depending on the task at hand, though, you might find more color to be more important. You can adjust this setting on the fly, so it's not a problem to turn up the quality to address an issue where color matters, and then turn it back down again to conserve bandwidth and improve speed.

A surprising limitation of the control view for a machine is that all the menu-based ARD task-assignment functionality is disabled while looking directly at a remote screen. For example, If you want to copy a file to the machine you're looking at, you have to put the screen aside, go back to the list or multiscreen machine view, select the machine again there, and then set up the file copy task. This again is a bizarre inconsistency on Apple's part, and it's one that we again hope will be fixed in the near future.