Since updating, my Apple Remote Desktop 3.7 is not working properly.

I just want to add my name to the list of unhappy sysadmins....

I was having odd issue where I could not copy or send command to particular client and the clients were showing up with bad IPs - including one with the IP of the gateway! ( not pretty ). I'll be watching this thread for evidence that Apple provides a fix.

Can someone confirm that the current maximum client version is indeed 3.7.1 ? I thought there was a 3.7.2 that matched the 3.7.2 ARD.app ( now Remote Desktop.app ).

I was also wondering if some of this ecosystem instability is caused by this app moving to the AppStore. I recently deleted my original install of ARD and paid the price to repurchase ARD again. I thought it was going to be easier for my portable sysadmin toolkit, to add it to my AppStore purchases so I could use it on a machine as need be. I was wondering if that had caused my problems. Anyone else find this to be a possible cause?

3.7.1 is the current client. I don't believe the App Store version has any impact. ARD has always been a fickle beast, but lately it's been having some serious DHCP tracking issues. 3.7.2 is better, but not perfect

Hey Bryan,

First off let me just say...thank you! Your script has helped me so much already. I am however using it with 3.7.2 now and I am getting this error returned...

2014-04-28 13:45:00.140 osascript[7461:507] Error loading /Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: dlopen(/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types, 262): no suitable image found. Did find:

/Library/ScriptingAdditions/Adobe Unit Types.osax/Contents/MacOS/Adobe Unit Types: no matching architecture in universal wrapper

osascript: OpenScripting.framework - scripting addition "/Library/ScriptingAdditions/Adobe Unit Types.osax" declares no loadable handlers.

Any ideas? Thanks in advance!

I did not write the AppleScript wrapper, only the original shell script. The script will only work with ARD Admin 3.7.1 - it will exit with an error message if any other version is found. That's probably why you're getting AppleScript errors.

In 3.7.2 apple changed in a very significant way the data cached regarding host names and IP addresses, so the original script wouldn't be of use anyway.

I have actually been having a lot of the same problems, even with 3.7.2, and this script still works as long as you change the version check. For some reason today I booted up and ran the script this morning and all was good, no errors returned. Thanks again, Bryan.

I am still having many issues as well. Anyone have a copy of the ARDFixer script that works with this version?

This is exactly what I am using...

#!/bin/bash

SCRIPT_VERSION="1.0"

# some background info here: https://discussions.apple.com/thread/5520097?answerId=24596710022#24596710022

# verify ARD Admin version

# quit ARD Admin - if running, wait 10 seconds

# kill cfprefsd

# rename plist

# sed

plist_path="$HOME/Library/Containers/com.apple.RemoteDesktop/Data/Library/Prefer ences"

plist_name="com.apple.RemoteDesktop.plist"

plist_backup="com.apple.RemoteDesktop-backup.plist"

VerfiyARDAdmin()

{

if [ -d "/Applications/Remote Desktop.app" ]; then

version=$(defaults read "/Applications/Remote Desktop.app/Contents/Info" CFBundleVersion)

major_version=$(echo "$version" | cut -d. -f1)

minor_version=$(echo "$version" | cut -d. -f2)

bugfix_version=$(echo "$version" | cut -d. -f3)

if [[ "$major_version" == "3" ]] && [[ "$minor_version" == "7" ]] && [[ "$bugfix_version" == "2" ]]; then

echo "Remote Desktop Admin 3.7.2 installed, proceeding to fix...."

else

echo "### ERROR: Remote Desktop Admin $version installed. Requires 3.7.2..."

exit 1

fi

else

echo "### ERROR: Remote Desktop Admin not installed"

exit 1

fi

}

QuitARD()

{

app="Remote Desktop"

ignore=$(ps -A | egrep -i "$app" | grep -v grep)

isopen=$?

if [ $isopen != 1 ]; then

{

echo "Quitting Remote Desktop..."

osascript -e "tell application \"Remote Desktop\"" -e 'quit' -e 'end tell'

sleep 15 # give cfprefsd enough time to flush the the preferences

}

fi

}

QuitCFPrefsDaemon()

{

echo "Quitting CFPrefs Caching Daemon..."

killall cfprefsd

}

ProcessPList()

{

echo "Backing up Remote Desktop plist..."

cd "$plist_path"

mv -f "$plist_path/$plist_name" "$plist_path/$plist_backup"

echo "Converting plist to XML...."

plutil -convert xml1 "$plist_path/$plist_backup"

echo "Editing Remote Desktop plist..."

pattern1="<key>hostname<\/key>/<key>blah_1<\/key>"

pattern2="<key>hostnames<\/key>/<key>blah_2<\/key>"

pattern3="<key>networkAddress<\/key>/<key>blah_3<\/key>"

pattern4="<key>networkAddresses<\/key>/<key>blah_4<\/key>"

pattern5="<key>primaryIdentfier<\/key>/<key>blah_5<\/key>"

sed "s/$pattern1/g;s/$pattern2/g;s/$pattern3/g;s/$pattern4/g;s/$pattern5/g" "$plist_path/$plist_backup" > "$plist_path/$plist_name"

echo "Converting plist to binary...."

plutil -convert binary1 "$plist_path/$plist_name"

}

clear

VerfiyARDAdmin

QuitARD

QuitCFPrefsDaemon

ProcessPList

exit 0

Having upgraded to Mavericks I can no longer install ARD from my CD installer v3.3 so I downloaded 3.7.1 and upgraded to 3.7.2 from software update.

Failed completely. Can't verify any of my computers so can't do anything with the clients at all....

Ho folks, I'm also waiting for Apple to come with an update for this not-working version op ARD. I talked to David Cronin of Apple Support in Curk, Ireland and he told me that the engineers ware working on it, as from half of April already... It;s very anoying that an update on such a piece of software takes SOOOOOOOO long. Hope they come with the solving update soon!

So, I was having the same black out problems all of you are having. I work at a school and manage 350 Macs ranging from brand new to 5 years old. When upgrading to 10.9.4 and ARD 3.7.2 all my labs when trying to view them in ARD where black and when clicking on them a dialog box would pop up and then an network error saying :

"Please make sure that Screen Sharing (in the Sharing section of System Preferences) is enabled on the computer to which you are attempting to connect. Also make sure your network connection is working properly".

After making sure all the setting had been set right and rebuilding our lab images from scratch and still having the problem a colleague and I started to test every single application we use in our build to see if it was either an application or hardware problem. Every application we installed we would immediatly restart and check ARD to see if we could see and control.

On a side note we could get the computers to show up in safe mode therefore bypassing all basic applications (holding shift on start up).

With all this said the application that was the culprit was a version of MCAfee Antivirus which was required by the institution:

This is the name of the dmg:

EPM210-RTW-1085.dmg

Take a look at you antivirus!

Sorry ZakAttack451, it isn't resolved.

Sure isn't. I've been using ARD for years and currently struggle to do anything with it.

I currently have ML and Mavericks clients on my higher ed network. I'm running Mavericks and the latest ARD on my admin station.

The ML clients are behaving as expected: They remain verified and active in the scanner list day to day (see screenshot). The Mavericks clients, once they go to sleep, are lost causes.

Right now I am trying to re-awaken a lab of 21 clients that I was just accessing a little while ago. I'm having to spend 20 minutes just re-verifying them all so I can do more work with them. EVERY TIME I want to access the computers again I have to do the re-verify dance, which fails the first time on every client consistently and does not apply the same name and password to all stations which would be helpful... (see screenshot)

So this is either an ARD problem or a Mavericks problem or both.

I see this thread has been Branched to a new discussion. But I am unauthorized to view it (??).

Hi folks, what I did is replacing ARD 3.7.1 from a TimeMachine backup and everything works fine now. Only Apple Software Update is coming with the anoying announces of the update to 3.7.2...