I’ve come across a strange issue stopping me rolling out M1 MacBook Pros to our users to replace older Intel machines.
I’m unable to use ARD to screen share onto an M1 Mac in these scenarios:
Filevault on and Firewall on
Filevault on and Firewall off
Works if Filevault is off and Firewall on or Filevault is on and Firewall is off.
I’ve tested a MacBook Pro 14inch and 16inch M1 running Monterey 12.0 through to 12.2 with the same result.
If I test an Intel Mac with the same Filevault/Firewall on, ARD works no problem.
Not sure if I’ve missed something daft on these M1 machines or a bug in Monterey on Apple silicon.
I've never come across that message sorry.
At a bare minimum, all you need for all users to observe is the config profile scoped to the device and the enable remote desktop command sent once from Jamf. If that still fails on a freshly enrolled machine then there may be some restriction / policy preventing this from working.
I was recently able to get this working in Jamf Pro, and wanted to add a couple notes for anyone looking to enable Remote Management via script in the future.
First, thank you @Bol for providing your script! It was very helpful as a basis to set this up in our environment. However, some tweaks were required to get it to work. My notes are below.
I hope this helps! Thanks again to everyone in this thread for taking the time to help get this set up for others!
The script is below. Be sure to supply the appropriate information for parameters 4, 5, and 6. Parameter 4 is your API account username, parameter 5 is your API account password, and parameter 6 is your local administrator account username.
@jkline19 No worries at all and thank you for sharing the Jamf recipe, I had not come across that at all.. Kudos!
When enabling ARD via the api, I understand it turns on remote management for all users with only observe and control permissions which didn't meet our requirements.
Pairing with the kickstart command allowed us to specify one user and their access controls.
Oh vnc, you needed to add these switches to the command line. I kept this page in the initial script so I could always reference back to it, very handy. You too, cheers!
-configure -clientopts -setreqperm -reqperm yes|no ## Allow VNC guests to request permission -configure -clientopts -setvnclegacy -vnclegacy yes|no ## Allow VNC Legacy password mode -configure -clientopts -setvncpw -vncpw mynewpw ## Set VNC Legacy PW
One trick I learned from Richard Purves on how to acquire the target computer's Jamf computer record ID using a custom MDM profile...
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
Make the pref domain in the profile something unique like "com.my-org.jamf".
This will generate an XML plist with a single key/value pair at /Library/Managed Preferences/com.my-org.jamf.plist.
Then you can read it back as a variable anytime you need it to reference it from a script/policy on the Target Mac like this example:
COMPUTER_RECORD_ID=$(defaults read "/Library/Managed Preferences/com.my-org.jamf.plist" JamfProID)
If you aren't using MDM then the only option is to enable via System Preferences, locally on the machine.
That is by design, trying to automate this remotely via script will give you the blank screen described.
I setup three Mac Mini's during the week with no MDM, enabling remote management before deploying the machine worked.
That's annoying, weird too. Well, if the target machines aren't controlled by MDM and remote management is already set I would try two things;
(If local access is an option)
- Uncheck then re-enable Remote Management. Then remove and re-add any users in the Allow Access For window, it should prompt again for permissions to be selected. Also set in the options but I think that's only if you have all users selected.
(If remote is the only option)
- Do you have remote login enabled?
- ssh into the machine and essentially do the same as above but using the command line equivalents. eg. Kickstart comand to remove ard settings / preferences and re-add users, set permissions etc.
Plenty of examples in the scripts above, good luck!
So, I ended up visiting the M1s physically and upgraded them to macOS 12.6, and unchecked/rechecked Remote Management under System Preferences -> Sharing and now the problem has gone away. Curiously enough though, when I try to use the Lock Screen feature I get an error message saying it "Could not change to Curtain Mode : An error occurred on this computer. [OK]" but it only happens on the default shared control. If I choose full control, it works fine. Not exactly something I need fixed, but thought I mention it in case others run into it. :)
Thanks for constantly checking in on this thread. The script you helped me create is working pretty well, but I've noticed that Certain functions of ARD are no longer working. I did set the "privs" to all, but I can't do a spotlight search or copy files to the computer anymore I just keep getting a "This task will fail" message. Remote controlling or viewing works like a charm, however.
Do you know if this Is something I have messed up in the kickstart command privileges or if this is a security setting that Apple has implemented in Monterey.
This is my section of the Kickstart command that I cobbled from your script:
/usr/bin/curl -s -u $apiuser:$apipass $jssurl:8443/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID -X POST
/usr/bin/defaults write /Library/Preferences/com.apple.RemoteManagement allowInsecureDH -bool TRUE
$kickstart -targetdisk / -verbose -uninstall -settings -prefs
$kickstart -targetdisk / -verbose -configure -allowAccessFor -specifiedUsers
$kickstart -targetdisk / -activate -configure -access -on -users $localUserName -privs -all -DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -GenerateReports -RestartShutDown -SendFiles -ChangeSettings -clientopts -setmenuextra -menuextra no -setwbem -wbem yes -restart -agent -console -menu
Thanks again sir!
I've noticed that Certain functions of ARD are no longer working.
I may of worked this one out... I believe permissions are reset after upgrades, although I couldn't find logs to correspond, good luck to me I say.
Testing our workflow and noticed after macOS 11 > 12, ard permissions that reported as on were; control, observe, show observe.
Also testing minor updates but I'm guessing it will be more of the same!
Anytime, happy to help and thank you!
I gotta say I did see this happen too a while back, at first I wasn't sure if one command was taking away from the other eg. MDM command setting back to observe over the kickstart setup.
I tried to troubleshoot a long time ago but found if I just triggered the policy again for that machine, full privs come back straight away.
Lastly I wasn't sure if settings are being changed somewhere else in my policies as it did take some time before a machine might do this (it was random I found as well). OR it was ARD being screwy as usual, saying it shows no permissions but after generating an admin report, full privs again.
Anyway, with the time I had spent overall I was happy to have the script trigger again and away I went. Think I had it set to monthly. Hope that helps, somehow.. and again thank you for letting me know it ended up working for you! Very happy it did in the end, nice work :D