ARD Screen Sharing issue M1 Macs and Monterey

prujamf
New Contributor

Hi All,

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.

 

Cheers,

Robert.

154 REPLIES 154

junjishimazaki
Valued Contributor

How are you enabling ARD?

Bol
Valued Contributor

@prujamf I don’t have either of those scenarios setup to test but noticed this recent change note below;

macOS Monterey 12.1

  • Screen sharing can now be enabled remotely only by MDM.

https://support.apple.com/en-au/HT212586 

 

Do you enable ARD via Jamf's api as part of your workflow and not just kickstart? Also make sure the following setting is enabled and you scope a PPPC payload as below to devices.

Bol_0-1644312947820.png

Use Screen Sharing to control a Mac that's enrolled in MDM 

prujamf
New Contributor

Hello Junjishimazaki/Bol,

Thanks for responding.

Remote Management is enabled via the kickstart command for a local administrator account.

I also scope a PPPC payload with the follow settings:

 

PPPC ScreenShare.jpg

This how the firewall settings look on an Intel and M1 Mac:

 

firewallsettings.jpg

 

@Bol Thanks for suggesting enabling the three Restrictions for Screenshots, Airplay and Classroom. Unfortunately enabling these had no effect.

Oddly screensharing briefly worked on one of my test M1 Macs after updating the OS from 12.0 to 12.2. Same settings as before. Unfortunately it stopped working as soon as I rebooted the Mac.

Under the Jamf Management Commands I can successfully send "Disable Remote Desktop Command" , but don't get an option to enable again..

Best Regards,

Rob.

 

Bol
Valued Contributor

Because of Apple's changes, you now need to use MDM / Jamf to do this.

Either press the 'Enable Remote Desktop' button on the computer object in Jamf or you can script the same outcome by using the API (there's scripts on the forums you can try).

Bol_0-1644330380458.png

 

 

route1337
New Contributor II

Do you happen to have a link to a script that works with 12.2+? Aiding a remote machine today and was stuck with a black screen. Thanks

Bol
Valued Contributor

I have a script but uses basic authentication which is depreciated now, needs to use bearer tokens so i need to update.

route1337
New Contributor II

Oh the API is changing to bearer tokens. I'd love to see the script once it's updated. Maybe I can help improve on it to run it as a Lambda or similar automation.

Bol
Valued Contributor

No problem at all. I spent some time reading and testing at one site, while I got it working, I don't yet know enough to make the api do what I think it should (uuid -> jamf id).. So for now I've pieced together what I found from the community, really nice information (as usual) at Mr Flounder's blog;
https://derflounder.wordpress.com/2021/12/10/obtaining-checking-and-renewing-bearer-tokens-for-the-j...
Same again from Mr Purves site;
https://richard-purves.com/2021/12/09/jamf-pro-api-for-fun-and-profit/
Then finding what I need from the Jamf developer site;
https://developer.jamf.com/jamf-pro/reference/createcomputercommandbycommandandid

- As a test, I disabled remote desktop in Jamf
 Bol_0-1645530925479.png

- Confirmed black screen during ARD connection

- Sending this command immediately re-connected screen session

/usr/bin/curl --request POST \

--url "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID" \

--silent \

--header "Authorization: Bearer $token"


Previously, I would use this to the same effect 

/usr/bin/curl -Ssu "${jamfpro_user}:${jamfpro_password}" "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/${computerID}" -X POST 

Also to note, for whatever reason while testing on 12.2.1, it no longer displayed the warning message "Your screen is being observed”.

Previously it would show unless I reconnected in succession to the same machine. Even after a reboot and login, hilarious, I'll ignore that and save myself revisiting an old rabbit hole.

route1337
New Contributor II

How are you getting $computerID?

Bol
Valued Contributor

@route1337 wrote:

How are you getting $computerID?


Firstly you need the machine UUID;

machineUUID=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk '/IOPlatformUUID/ { gsub(/"/,"",$3); print $3; }')

Then I used this as my guide because I had exhausted my patience on how to do this straight using the api;

https://richard-purves.com/2021/12/09/jamf-pro-api-for-fun-and-profit/

 

computerrecord=$( /usr/bin/curl --request GET \

--url "${jamfpro_server_address}/api/v1/computers-inventory?section=USER_AND_LOCATION&filter=udid%3D%3D%22${machineUUID}%22" \

--silent \

--header "Authorization: Bearer $token" )

computerID=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$computerrecord\`).results[0].id" )

 

burdett
Contributor II

I haven't seen a 'Enable Remote Desktop' button on the computer object in Jamf.  I do have the PPPC payloads that bol and prujamf suggested that fixed this issue when Catalina came out. 

I ended up creating in JAMF inventory an advanced search of all my macOS Monterey devices. Then in
the Search opened view -> Action -> Send Remote Commands -> Set Remote Desktop (macOS 10.14.4 or later) -> Enable

The answer displayed was,

Complete

The remote command failed to send.😕

😀 However Screen Sharing was enabled, the 5 or 6 system that I reached out with using JAMF Remote or Apple Remote Desktop or screen sharing, and they all properly shared the screen.  

Not sure how I can send a MDM command to a new device when it is enrolled.  Any suggestions would be welcome.

 

I tried this...still getting black screen. :(

kwoodard
Contributor III

Any update on this? I would love to create a profile or policy that I can scope my computers to to get this turned on.

Bol
Valued Contributor

@kwoodard wrote:

Any update on this? I would love to create a profile or policy that I can scope my computers to to get this turned on.


You can use this if basic authentication is still enabled;

/usr/bin/curl -Ssu "${jamfpro_user}:${jamfpro_password}" "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/${computerID}" -X POST 

Otherwise, this command enable's remote desktop;

/usr/bin/curl --request POST \

--url "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID" \

--silent \

--header "Authorization: Bearer $token"

 Jamf - Creates a new computer command using command name and device IDs 

kwoodard
Contributor III

I must be doing something wrong, this did nothing except pop out errors with using curl etc.

@Bol do you recommend scripting it and running after enrollment or Files and Processes?

Bol
Valued Contributor

@rcole wrote:

@Bol do you recommend scripting it and running after enrollment or Files and Processes?


Sorry I missed this, yes I script and run on startup, once per month. 

After enrollment reboot allows this policy to be run second to bootstrap escrow. Previously I ran kickstart in Files and Processes but theres too many lines now to keep in there for me!

burdett
Contributor II

I opened a ticket with support, they said JAMF remote is deprecated and suggested using team viewer integration??  I guess I'll just use MS teams, or send the MDM command to a device using an advance search so I can use ARD or Screen Sharing.  

dstranathan
Valued Contributor II

Can TeamViewer be easily set up for unattended access? We have a lot of headless Mac minis for testing (Intel, and ARM) that we like to use ARD on.

Hello all.  I think I'm having the same issue.  The behavior I'm experiencing is that I can ARD to the machines.  It indicates that it's connected and on the client end it's "being observed."  However, on my end the screen is completely blank.  I found that the quick fix is to manually toggle the System Preferences/Sharing/Remote Management OFF and ON again.  I had never had an issue until Monterey.  Same issue?  Any suggestions?  

This is what I'm using.  

(Special thanks to "RossMadness."  Source Link: https://www.reddit.com/r/macsysadmin/comments/f2recc/apple_remote_desktop_and_jamf_pro/fhec8aj/)

==================

#!/bin/sh

#enables screen share for specifiedusers then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers -restart -agent

#specifies user then sets permissions for specified user then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users [user1],[user2] -access -on -privs -all -clientopts -setmenuextra -menuextra no -restart -agent

==================

I preload my system admin profiles (user1, user2, etc.] during the pre-stage enrollment.

@HappyTrails @Did you ever find a solution?

Bol
Valued Contributor

This is by design and the changes are noted here;

Bol_0-1650499569529.png

Your script will handle the ARD settings and allow you to connect fine. Although the blank screen can only be fixed by enabling Remote Desktop via MDM. Add into your script an API call to do this and it will work again.

I have this setup after enrollment as a policy / script and allows me to ARD to a machine, erase & wipe, then after enrollment my original ARD window reconnects again. Not that helpful but it works :D 

 

HappyTrails
New Contributor III

Hello Bol.  First off, thanks for the quick response.  I appreciate yours and everyone elses' feedback on this post.  'Still new to this.  This has given me something else new to try.

"Although the blank screen can only be fixed by enabling Remote Desktop via MDM. Add into your script an API call to do this and it will work again."  -So does this look about right?

==================

#!/bin/sh

#enables screen share for specifiedusers then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers -restart -agent

#specifies user then sets permissions for specified user then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users [user1],[user2] -access -on -privs -all -clientopts -setmenuextra -menuextra no -restart -agent

computerrecord=$( /usr/bin/curl --request GET \

--url "${jamfpro_server_address}/api/v1/computers-inventory?section=USER_AND_LOCATION&filter=udid%3D%3D%22${machineUUID}%22" \

--silent \

--header "Authorization: Bearer $token" )

computerID=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$computerrecord\`).results[0].id" )

==================

 

My tests so far:

  1. So from what you did, I disabled remote desktop to my Test-1 machine in Jamf.
     HappyTrails_0-1650557415013.png
    • I noticed immediately that it did in fact disable it when I checked my ARD console: I couldn't remote in.
    • I also noticed that in Jamf on my Test-1 machine, after a refresh, there was no "Enable Remote Desktop."
  2. Afterwards following the steps you took, I created a Policy with the following script: unfortunately failed.  Maybe I wasn't doing it right.

==========

/usr/bin/curl --request POST \

--url "${jamfpro_server_address}/JSSResource/computercommands/command/EnableRemoteDesktop/id/$computerID" \

--silent \

--header "Authorization: Bearer $token"

=========

   3.  So I then I saw your reference to the Richard-Purves post on the API script and created another policy with the following script below.  

 ==================

computerrecord=$( /usr/bin/curl --request GET \

--url "${jamfpro_server_address}/api/v1/computers-inventory?section=USER_AND_LOCATION&filter=udid%3D%3D%22${machineUUID}%22" \

--silent \

--header "Authorization: Bearer $token" )

computerID=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$computerrecord\`).results[0].id" )

====================

  • When I scoped this to my Test-1 machine, it ran and appeared to have been applied (the machine log indicated that it executed).
  • However in Jamf Pro it indicated that it failed.
  • BUT!  Interesting enough though... My Test-1 machine in Jamf now shows that Enable Remote Desktop.  I clicked it and it worked.  Once I did that, it does not show “Disable Remote Desktop.”  
  • Is this a normal behavior?
  • How can I disable it so I can test if the my script above will work?

HappyTrails_1-1650558480091.png

 

@HappyTrails sometimes I have to press enable and disable twice, refresh the page, twice, and then it will show an updated status of Remote Desktop. However, the command seems to execute after the first attempt, even though the console does not reflect that. I figured this was due to cache or something related to the browser and the way Jamf communicates back to Management tab. 

HappyTrails
New Contributor III

Thanks.  Good to know.  'Sounds like a normal behavior.  So far this is just a work-around until we figure this out.  This is definitely better than toggling Remote Management off/on locally on a machine.

Super curious about your script @obola. Especially, because it allows you to ARD to a machine and do that after enrollment. How did you avoid the black screen issue? Or, do you run this script with an "Enrollment Complete" trigger and then also press the. button to Enable Remote Desktop as well? Is it a two part process for you now?

Bol
Valued Contributor

I think what it tripping this all up is even without using the API call to enable / disable remote desktop, you ARD code will still change the button behaviour in Jamf Pro.

eg. Will say that it's been enabled but you are still seeing the blank screen. You want your script to first enable via API, then make ARD setting changes after this and it should work.

At a guess I think your script needs to have a variable set for the machine uuid, i couldn't see that in your examples and is required to pull the jamf pro id from API like you have added.

machineUUID=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk '/IOPlatformUUID/ { gsub(/"/,"",$3); print $3; }')

 

HappyTrails
New Contributor III

Hello.  I'm just getting back into this.  Man... Work just get in the way.  I finally had a chance to do more testing.

 


@Bol wrote:

I think what it tripping this all up is even without using the API call to enable / disable remote desktop, you ARD code will still change the button behaviour in Jamf Pro.

Yeah...  Actually you're right.  I tested this out on a couple of machines with just the original code I had below.  As mentioned it works, but it goes blank when I initiate an ARD session.   

#!/bin/sh

#enables screen share for specifiedusers then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers -restart -agent

#specifies user then sets permissions for specified user then restarts agent
#replace [user1],[user2] with your local account 

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users [user1],[user2] -access -on -privs -all -clientopts -setmenuextra -menuextra no -restart -agent

So in Jamf Pro, I went into a computer's Management tab and clicked Disable Remote Desktop button, refresh my screen, then do it again, a few times (which I thought was quirky) until I get the Enable Remote Desktop button.  Once I got that, I was able to ARD into the workstation as normal. 

HappyTrails_0-1651535430671.png

HappyTrails_1-1651535648908.png

More testing...

I was trying to figure out why the API call was failing.  It's still not resolved.  I still kept on getting errors.  I tried what you said, with my limited experience in any API calls.


@Bol wrote:

You want your script to first enable via API, then make ARD setting changes after this and it should work.


So tried to place it on two Policies to "first enable via API" then my ARD script:  Failed.  

I even added all in one Policy: no go.

#!/bin/sh

# required to pull the jamf pro id from API 

machineUUID=$(/usr/sbin/ioreg -rd1 -c IOPlatformExpertDevice | /usr/bin/awk '/IOPlatformUUID/ { gsub(/"/,"",$3); print $3; }')

# API 

computerrecord=$( /usr/bin/curl --request GET \
--url "${jamfpro_server_address}/api/v1/computers-inventory?section=USER_AND_LOCATION&filter=udid%3D%3D%22${machineUUID}%22" \
--silent \
--header "Authorization: Bearer $token" )
computerID=$( /usr/bin/osascript -l 'JavaScript' -e "JSON.parse(\`$computerrecord\`).results[0].id" )

#enables screen share for specifiedusers then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers -restart -agent

#specifies user then sets permissions for specified user then restarts agent

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users [user1],[user2] -access -on -privs -all -clientopts -setmenuextra -menuextra no -restart -agent

 


@Bol wrote:

 

My workflow is roughly;
Generate Token
Get Jamf Computer ID
Set Apple Remote Desktop via API
Set Apple Remote Desktop via Kickstart
Expire Token


Wow!  That's a lot.  I'll have to dig into this further.


@Bol wrote:

 

https://richard-purves.com/2021/12/09/jamf-pro-api-for-fun-and-profit/


To be continued...

Bol
Valued Contributor



@HappyTrails wrote:

Wow!  That's a lot.  I'll have to dig into this further.


:D It was a lot less originally, two lines with kickstart but then had to add api call, now bearer tokens! Nice sluething, it's all sounding very familiar to me again.

You pretty much have it but think you may of forgot to generate an auth token before making a call to the api. If you add that in, early in the script I believe it should work. Let me know if not!

HappyTrails
New Contributor III

Thanks for having a look.


@Bol wrote:



... generate an auth token before making a call to the api. 

How do I do that?  Did I miss it?  What line sample was that?  -I'll have to give it a shot.

 

kwoodard
Contributor III

Does anyone have this setup and working properly yet?  Seems like there are a few different things suggested now and none seem to completely work. I know that the old script that I used to kickstart the service as well as the script I had been using to fix the black screen issue no longer seem to work. I use ARD a lot, so not having it working to screen share properly is a big productivity blow for me and the few other guys that work on Macs.

Bol
Valued Contributor
@kwoodard wrote:

I must be doing something wrong, this did nothing except pop out errors with using curl etc.


The snippet above works but you still need to declare those variables curl is using. eg. jamfpro_server_address = "https://xxx:8443"

By just cut and pasting those lines, yes it will give you errors. You can still maintain your kickstart script and settings, you will just need to add enabling ARD for each computer via MDM (Jamf API). This article will step you through encoding your api credentials / obtaining & invalidating api token, then you can use the code above to enable ARD.
https://richard-purves.com/2021/12/09/jamf-pro-api-for-fun-and-profit/

My workflow is roughly;
Generate Token
Get Jamf Computer ID
Set Apple Remote Desktop via API
Set Apple Remote Desktop via Kickstart
Expire Token

kwoodard
Contributor III

I get the workflow. It makes sense. I’m not a programmer (I use mostly the GUI, but I do have some smaller and less complex scripts for some things), so I’m banging my head on my desk trying to get the coding sorted out. I’m not seeing how to turn on Remote Management via the API and I don’t know how to integrate the token into it (and the kickstart) to make this work. Can you share your code?

Working on this also. If I find a solution I will post it. Similar reasons.

Bol
Valued Contributor

@kwoodard @rcole My head just can't get around the layout in this forum sometimes, sorry I missed your replies.
I generally step through any line of code I haven't written and my script had a few things specific to my environment that I wasn't sure if necessary anymore.

I will post my script today and just explain a couple of things you might need to consider. Hopefully it will get things working again for you.

kwoodard
Contributor III

@Bol  Would love to see your script and any other policies/PPPC that you are using.

kwoodard
Contributor III

This seems far more complex than it should be. I shouldn’t have to be a programmer to get something like this enabled. Should be a check box in a configuration profile. I’m so glad there are people that know how to do this kind of programming and willing to help. This one has me lost. Injecting a bearer token is just words to me. 

Bol
Valued Contributor

This is a Jamf thing to remove security issues in the product and move to a more modern api I believe. Im new to it all too, can be overwhelming but the community is full of great minds / bloggers which helps me alot :D  

rcole
Contributor

I agree 100%. These little changes have big impacts on workflow. Speaking of @kwoodard  and @HappyTrails, have you found a solution?