Remote management doesn't get the right setup or stops working

New Contributor III

I use a script that configures and activates remote management. It uses the kickstart command to configure it and calls an API to activate it. But I have 2 problems.

The first one is that it should activate the remote management with all privileges for the admin account, not for everyone. But sometimes, despite the fact that I see the admin account in the "only for specific users" box with the right setup, the radio button for "All users" is active. I was thinking that it may be due to the fact that I never logged in into the admin account but it's not true as it works most of the time.

The second one is that sometimes, I get the error "Connection failed. severUnableToReadScreenMessage". I don't know how it may happen in Monterey, but it seems that a "tccutil reset All" breaks it on Ventura. I sometimes need to use that command to be sure that my pppc profiles are good and not because I allowed access to the app. Of course, I use that command in my test lab. What I need to do is to use the script again and it works.

Any help to resolve those problems is welcome !


Valued Contributor

Firstly, don't worry about the radio button as it's a graphical bug which I see as well, depending on which version of macOS i'm looking at. Doesn't effect the end result.
Are you deploying a privacy preference for the screen sharing service? as kickstart alone won't do anymore.


Finally, take a look at this rather long thread which I guarantee will cover everything you will need to get this working. Even just comparing against all our scripts may give you an idea in the right direction.
Good luck!

New Contributor III

I already read that post. I'll read it more carefully later if I missed something. Filevault is on and firewall is off. We do have to use filevault, it's not an option. I use PPPC for screen sharing too. I also tried with ARDAgent the same way as I use remote management and not screen sharing.

For the radio button, I didn't think about a glitch. I'll check if I can connect with a standard user or not. I use the kickstart commands to set up the differents configurations. But I use an API call to enable it. Maybe should I configure the kickstart command before activating the remote management ? I use a script that I found.

What is strange is that if I do a tccutil reset All, it breaks the remote management. It's still activated with the right setup, but with the error message written in my first post. How can I trace and log what happens to try to find a solution ?

Valued Contributor

Oh no, nothing to do with the filevault / firewall comments, more profile / settings / script towards the end. It's hard to comment when I'm not looking at how you have pieced it together and am just guessing but resetting your privacy preferences should not have any effect.
At first glance, that error you saw was appearing for people that had not enabled remote control via MDM / API after apple made the system changes in macOS 12.1. Have you test your workflow by manually enabling remote desktop using the button in Jamf for that device instead of api?


I would also see if a device profile assigned with the following restrictions payload helps. I run but haven't gone back to see if removing makes a difference.

If using Kickstart to specify a user and privs, are you doing this on seperate lines as apple's docs show;


Also for testing, you can delete all settings which may help if you are deploying a range of settings on machines. My kickstart function in my script looks like;

privs="-DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings"

SetAppleRemoteDesktopViaKickstart () {
# $kickstart -targetdisk / -verbose -uninstall -settings -prefs
/usr/bin/defaults write /Library/Preferences/ allowInsecureDH -bool TRUE

$kickstart -targetdisk / -configure -allowAccessFor -specifiedUsers -privs -all
$kickstart -targetdisk / -configure -access -on -users $localUserName -privs $privs -clientopts -setmenuextra -menuextra no -setwbem -wbem yes
$kickstart -targetdisk / -activate -restart -agent -console -menu


New Contributor III

Resetting privacy preferences should not have any effect, but it does:

I manually activate the remote management through the management tab of the computer informations in Jamf or I activate it with the script below. When I control the computer and do a tccutil reset All, the connection is lost: the screen of the remote management is fix, I can't see the mouse moving inside the window. If I quit ARD and start it back, when I want to control the computer, the connection window still shows that it's connecting, but nothing happens. And once I reboot the computer, the severUnableToReadScreenMessage error dialog box appears. If I run the script (I have it in Self service for this in my test lab) or activate it with the button in the management tab, it then works again until I do another tccutil reset All. Believe me, it happens every time with Monterey and Ventura.

For the configuration profile, I have it, except that I didn't checked the third box. Do I have to check it ?

Capture d’écran 2023-06-26 à 13.43.17.png

And here is the script that I found somewhere on the net.



# Get the Jamf instance URL from the computer
jss_Url=$( /usr/bin/defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url )

#Kick start command

echo "Enabling ARD..."

# generate base64 ecnrypted password
encoded_creds=$(printf "$jamf_User:$jamf_Pass" | iconv -t ISO-8859-1 | base64 -i -)

# generate an auth token. tr truncates and removes all line feeds
authToken=$( /usr/bin/curl -s "${jss_Url}api/v1/auth/token" -H "authorization: Basic ${encoded_creds}" -X POST | tr -d "\n" )

# parse token, remove expiration date
token=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$authToken\`).token" )

# Get Mac serial number
mac_serial=`system_profiler SPHardwareDataType | awk '/Serial/ {print $4}'`
echo "Mac serial: $mac_serial"

# Get ID of the Mac from Jamf
JAMF_ID=$(curl --header "Authorization: Bearer $token" "${jss_Url}JSSResource/computers/serialnumber/${mac_serial}" -X GET | xmllint --xpath '/computer/general/id/text()' -)
#echo "Jamf ID: $JAMF_ID"

#Send MDM command to enable remote desktop for this mac
/usr/bin/curl --header "Authorization: Bearer $token" "${jss_Url}JSSResource/computercommands/command/EnableRemoteDesktop/id/${JAMF_ID}" -X POST

## Enable ARD options using the kickstart command

$KICK_START_BINARY -activate -configure -allowAccessFor -specifiedUsers
$KICK_START_BINARY -configure -users myadminuser -access -on -privs -all -restart -agent -menu

# expire the auth token
/usr/bin/curl "${jss_Url}uapi/auth/invalidateToken" --silent --request POST --header "Authorization: Bearer $token"

exit 0

I just noticed that you run 3 commands for the kickstart. I'll change that later today.

Maybe should I remove all remote management configs then set them back ? But as it happens in out-of-the-box macs, I'm not sure that it's the problem. For the radio button, I'll check that when it will happen again and see if it's just a bug like you said. I may try to activate the remote management with the API call after the kickstart commands. Anyway, this script works fine most of the time.

A last question: what is that option "allowInsecureDH in the Library/Preferences/ ? And what does that defaults write command ? It's already at 1 (true)

Valued Contributor

For the configuration profile, I have it, except that I didn't checked the third box. Do I have to check it ?

If you haven't tried it's worth a look but I don't think it would have any effect, might as well tick it off the list.

I just noticed that you run 3 commands for the kickstart. I'll change that later today.

I used to have only two lines but found when I included the options below on the last command, it wouldn't correctly apply my set permissions. Only the default Show / Observe would be in effect which is what you get from enabling ARD via api or jamf gui button on the device record.

A last question: what is that option "allowInsecureDH

From memory it's legacy, clients below a certain ard version (< 3.9 maybe) could not connected to using most up to date Remote Desktop client. Adding this allowed it until you could update the clients on machines.

In remote desktop have you tried running 'Report - Admin Settings' to see what permissions are set for your local account. Hopefully it's showing all like you are trying to apply.

New Contributor III

More info about ARD broken when I run a tccutil reset All: while I don't restart the computer, I can see what happens in ARD, but can't control the computer remotely.

Valued Contributor

Run tccutil reset All again then use the following commands to view logs;

/usr/bin/log show --predicate 'subsystem == ""' --info --last 1h

Search for: target_executable_path_URL, bundleID, static code for, result: Auth

If you have those previously mentioned profiles deployed there shouldn't really be a tcc issue but these logs should help show any errors if there.

Valued Contributor

Sorry I didn't see your above post, i hate the layout on these forums.. will take a look now

Valued Contributor

A great list for reference;