Archive for the ‘Apple Remote Desktop’ Category

Enabling least-privilege screensharing using Apple’s Remote Desktop Client and Screen

July 7, 2017 3 comments

In a number of Mac-using environments, there is often a need for IT staff to remotely connect to a Mac’s screen using Apple’s Remote Desktop application and work with the person on the other end to resolve a problem. However, there can be several technical and human-centric issues with enabling remote assistance:

  1. Authentication – To enable access using a username and password, that user account must be granted access rights by belonging to a group or by explicitly granting rights to a local account.
  2. Password rotation – If you’re enabling screensharing via granting access to a local account, the security requirements in most environments mandate that those passwords be changed on a regular basis. However, securely changing the account password on multiple remote Macs can be a management challenge on its own.
  3. Access privileges – A lot of folks don’t like the idea that someone they don’t know can take over access to their keyboards and screens without the remote customer saying it’s OK for them to do so. Frankly, I’ve been on both sides of this fence and I don’t like it either.

However, there is a way to enable screen sharing using Apple’s Remote Desktop Client and Apple’s Screen which does the following:

  • Removes the need for any account to be enabled for screen sharing access
  • Mandates that all screen sharing access be approved by the logged-in user
  • Does not allow screen sharing access if no user is logged in.

For more details, see below the jump.

Read more…

PATH environment variables and Casper 9.8

September 24, 2015 1 comment

In the wake of the release of Casper 9.8, where the Casper agent’s jamf and jamfAgent binaries have made their planned move from /usr/sbin to /usr/local/jamf/bin, a number of Casper-using folks who were used to running commands that referenced the jamf and jamfAgent binaries from Apple Remote Desktop (ARD) or other tools began to see errors that indicated that the jamf and jamfAgent binaries could not be found.

Screen Shot 2015 09 23 at 8 23 05 PM

Screen Shot 2015 09 23 at 8 11 28 PM

Conversely, opening a Terminal session and running the exact same command works fine.

Screen Shot 2015 09 23 at 8 21 14 PM

Why are different tools acting differently? The root cause is that they each have different PATH environmental variables, usually referred to as $PATH. For more details, see below the jump.

Read more…

Using Apple Remote Desktop Admin to help script ARD kickstart options

March 7, 2013 7 comments

Apple Remote Desktop is a tool that just about every Mac admin uses at some point. The client is built into OS X and it’s usually straightforward to turn on. It also includes a command line tool called kickstart which can be used to configure the Apple Remote Desktop client. The kickstart tool is useful because you can use it to script your configuration. That said, if you have a complex ARD configuration, getting the kickstart options correct can be tricky.

One way to help with this is to have Apple Remote Desktop Admin do the kickstart configuration work for you. See below the jump for the details.

Read more…

Fixing the Apple Remote Desktop client when it crashes repeatedly

May 3, 2010 7 comments

On a few of my servers, I’d recently begun running into a problem where the ARDAgent process (which is the process for the Apple Remote Desktop client) was crashing repeatedly. It would launch, crash, relaunch, crash, relaunch, crash, relaunch, etc. every few minutes. The common factor seemed to be that it was happening on my 10.4.x Macs (I didn’t see the problem on 10.5.x or 10.6.x Macs) and would persist across reboots, reinstalls and everything else I could think of.

I’d seen a number of folks with the same problem, but I didn’t find a solution until I ran across this Apple Support Discussions thread.


I have run into a similar problem a couple of times but today was the first time I was actually able to resolve it!

The fix I used is to remove the /Library/Application Support/Apple/Remote Desktop/Client directory and restart the client. For whatever reason the tasks.plist in the Tasks folder found inside the Client directory above seemed to be corrupt; removing it seemed to do the trick.

Restarting the Agent from the command line: /System/Library/CoreServices/RemoteManagement/ -restart -agent

Hope this helps!



I tried it out on my own servers, and it looks like it has resolved the problem! Here’s what I did:

1. Logged in with an admin account.
2. Opened Terminal.
3. Ran the following command to stop the Apple Remote Desktop client:

sudo /System/Library/CoreServices/RemoteManagement/ -agent -stop

4. Ran the following command to remove the /Library/Application Support/Apple/Remote Desktop/Client directory:

sudo rm -rf /Library/Application\ Support/Apple/Remote\ Desktop/Client

5. Ran the following command to restart the Apple Remote Desktop client:

sudo /System/Library/CoreServices/RemoteManagement/ -agent -restart

I LOVE Apple Remote Desktop today.

April 20, 2006 Leave a comment

I just got done making sure that some software needing for a training class tomorrow was pushed out to 50-odd PowerBooks. It took three hours to run the job. I was able to start the job from a PowerBook running Apple Remote Desktop remote administration software (ARD), then leave. Three hours later, I connected from home using my laptop’s ARD software to the ARD PowerBook via work’s VPN, took control of the ARD PowerBook and double-checked the training laptops to make sure they all had both the software installed and the training files. In between setting up the job and checking on its completion, I’d driven home, gotten some dinner, chatted with my future mother-in-law about a plumber visit tomorrow and talked to my best friend on the phone. Without ARD, I could have been in that training room all that time installing that software on those 50-odd machines. No thanks! Thanks to ARD, I didn’t have to. That’s why I love ARD today. 

Categories: Apple Remote Desktop

Script-only installer packages for download.

April 2, 2006 4 comments

I had a request from Michael Augustson on the Apple Remote Desktop mailing list if I can post a link to a collection of the script-only installer packages that I’ve used with Apple Remote Desktop 1.x and 2.x. Since I’m a nice person, I’m doing just that. For all those who are interested, I’ve saved a disk image with a number of script-only installer packages, with some other additions that I’ve found useful, up to my .Mac account at
Here’s what’s on the disk image: 
Script-only Installer packages for use with Apple Remote Desktop 
Clear Caches.pkg – Clears the following files from the target Mac’s boot disk, then restarts the Mac: 
All files in /Library/Caches/ 
All files in /System/Library/Caches/ 
All files in ~/Library/Caches/ 
Software Update.pkg – Runs the following commands on the target Mac: 
Repairs permissions on the target Mac’s boot disk 
Runs the softwareupdate command with the -q, -i, and -a flags to quietly install all available software updates from the Software Update server. 
Repairs permissions on the target Mac’s boot disk again 
Restarts the Mac 
Software Update – No permissions repair.pkg – Same functions as Software Update.pkg, but without the permissions repair (Useful if dealing with Macs with iTunes 6.0.3, which hangs up permissions repair.) 
Software Update with cache clean.pkg – Runs the following commands on the target Mac: 
Repairs permissions on the target Mac’s boot disk 
Runs the softwareupdate command with the -q, -i, and -a flags to quietly install all available software updates from the Software Update server. 
Repairs permissions on the target Mac’s boot disk again 
Clears the following files from the target Mac’s boot disk: 
All files in /Library/Caches/ 
All files in /System/Library/Caches/ 
All files in ~/Library/Caches/ 
Restarts the Mac 
SSH_start.pkg – Starts the SSH service on the target Mac 
SSH_stop.pkg – Stops the SSH service on the target Mac 
Other Installer packages 
Repair Permission script install.pkg – installs a script into the /etc/periodic/daily, to repair permissions on the target Mac’s boot drive as part of the Mac’s daily maintenance tasks that are run at 3:30AM. 
Virex Script Installer packages 
Virex 7.2 Scripts folder – contains installer packages for Bruno Corbage’s Virex 7.2 scripts (more information available at
Virex 7.7 Scripts folder – same scripts, updated for use with Virex 7.7 and 10.3.x/10.4.x 
Other Applications 
Slipy – Application to use with making custom 10.3.x installer DVDs (no longer available from author.) More information available from 
Use them in good health! 

Script-only installer packages

July 3, 2005 3 comments

Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle so that I could send them over ARD. The way I found was to use script-only installer packages. Installer packages are Apple’s preferred way to install software, and what their applications show up in. Since Apple also builds ARD, they built in the ability to install software on remote machines using the Install Packages function. The neat thing about packages is that you can have them run a Unix shell script before or after the package is installed. You can even set up a number of scripts and have them run in the order you want them to. Best of all, you can build a script-only installer package where the only payload inside the package is these scripts, with no software to be installed. So, when I needed to run a Unix command on one or more of my OS X boxes, I’d normally build a script-only package and use the Install Packages function to push it out over ARD. 
Now, with ARD 2, Apple listened to the piteous cries of its users and built a Send Unix function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a script-only installer package. This is a Good Thing, but I’m still more a fan of script-only installer packages. Here’s why: 
Using an install package to do what you need to do, vs. using ARD’s send Unix command, gives you a couple of advantages: 
1. You only need to build it once – I have a couple of packages to 
handle turning SSH on or off on ARD-managed Macs. I distributed them for 
use by my team. I didn’t need to tell them the command, and I don’t need to remember myself. I just need to push the package called “SSH_On” to turn SSH on, then push the package called “SSH_Off” to turn SSH back off when I’m done. I have a number of packages like that, but that’s the general idea. 
2. Shell script packages – Using script-only install packages, I can write 
an entire shell script which doesn’t need to stay resident on the target 
Mac. For example, I have a Software Update script-only install package. It 
does 4 things: 
1. Repairs permissions 
2. Use the command line softwareupdate tool to get all updates from Apple for that Mac. 
3. Repairs permissions again. 
4. Restart. 
I can run all of those tasks separately via Send Unix, but doing it with a package means each machine can run it at their own speed and I don’t have to wait on the B&W G3 to finish while the G5’s been waiting for 10 minutes for my next command. I can push once and be done with it.  
3. Send Unix doesn’t doesn’t allow for shell scripting, unless the shell script is already resident on the target Mac – This for me, is the killer advantage script-only installer packages have over Send Unix. You can kick off a previously copied shell script via Send Unix, but you can’t use it without the shell script already being there on the remote Mac. With a script-only installer package, the script is along for the ride. 
Send Unix has its place, and I use it frequently. For some ARD functions, however, you can’t beat knowing how to make and deploy a script-only installer package. 

%d bloggers like this: