Tuesday, March 7, 2017

Apple Remote Desktop 3.9 update

So you came here because you updated your clients?
You really installed the Apple Remote Desktop 3.9 Client ?

And so now some of your clients are accessible via Screen Sharing but fail to do anything else?

No packages installable? No UNIX commands executable? No reports generatable?

I had the same problem.

But I think I was able to fix it.

At least I got it running on my blocked clients.

What I did, was to execute this script on the client machines:

# Fix ARD 3.9 clients 
rm -Rf /Library/Application\ Support/Apple/Remote\ Desktop/Client/privatekey
rm -Rf /Library/Application\ Support/Apple/Remote\ Desktop/Client/publickey
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -restart -agent -console
exit 0
That's it.

The first two commands delete the client's certificates.
Kickstart is then used to regenerate the certificates needed.

Maybe the clients have to be readded to the Remote Desktop Admin

From then on, they worked as expected....

Wednesday, February 15, 2017

PrinterProxy & Restrictions

So, if you got here, you are looking for a solution to find out how you can prevent you users from being able to start applications from any location while still being able to print.

The big problems are:

  • macOS using restriction profiles seems unable to handle relative paths. In earlier versions of OS X you could use these paths such as '~/' for the home folder to for example deny execution of applications from within the home folder
  • In order to print, macOS needs to create these 'PrinterProxy' apps in the users home directory under 'Library/Printers'.

Why these PrinterProxys habe to be located within the home directory is out of my reach.
Also I don't think this is logic. Even if the printer is assigned to the machine, the folder containing those PrinterProxys is still located in the home directory of the user.

But anyway.

I tried al sorts of redirections, creating a PrinterProxy folder in /Library or /tmp and then creating a symlink that would point at these folder.
Forget it. It won't work.

So, in the end I ended up doing this:

For every file share that contains user home directories, I created an entry in the 'Allow Folder' section of the profile.

These entries look like this:

By using the payload variable '%short_name%" inside the path allows you to use the users short name as is most often done for the name of his home directory.

The rest of the path has to correspond to the path that you get when entering the command
in the terminal when logged in as an example user.

I hope this helps others to save some time and prevents them from going all the way again.

This procedure was verified using macOS 10.12.3