Disabling/re-enabling Remote Desktop via Jamf Pro

[James_NZ]

I've got an issue with Screen Sharing on to a lab of Macs where the screen is completely black apart from the cursor moving being visable. Using Screen Sharing via Finder or using the Apple Remote Desktop application presents this issue. 

The only fix I've found so far is to send the "Disable Remote Desktop" command from Computers > Management > Management Commands, force the device to check into Jamf Pro, then send the "Enable Remote Desktop" command to the device. After these steps, the black screen issue is resolved and screen sharing/ARD works as expected.

When this issue occurs, I can easily log into Jamf Pro, send the management command to a smart group of my lab Macs, another management command to force them to update inventory, then a third command to force them to re-enable Remote Desktop. 

Is there any way to automate this process into a policy so an engineer doesn't need to log in and manually run the commands?

[Eltord]

I've recently had to do a mass disabling of remote management and remote login services to my devices, which to do that I sent out a policy with the following in the Files and Processes -> Execute Command payload:

systemsetup -f -setremotelogin off ; /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate ; /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

You can then send another policy that reenables those services via the same payload and the following commands:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -all -clientopts -setmenuextra -menuextra ; /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

As for how to automatically trigger these policies to run, i'm not sure how you would be able to trigger off of that error type without some kind of bread crumb or push button action, that would be something to investigate further for sure. If you have anything right now, we can try to work out a set of smart group criteria to scope these policies off of.

[James_NZ]

Thanks for the awesome reply! I'll be testing this today. Legend!

[Qwheel]

That's an interesting way of handling it.

I noticed issues with Monterey and suspect it's going to be this way going forward. With Monterey, you can only enable ARD via MDM command. I spotted that if I'd already triggerred my kickstart ARD policy and then ran the MDM command, the privileges weren't applying to my admin account. i.e. Failing Unix commands and restart commands - it does get you past the black screen issue though.
In the black screen state, I didn't fancy locating the device in JAMF, sending a 'disable ARD' command and page refresh (repeated twice to it turned to enable), then doing the same with the enable command, just to be able to access a device which I'd still have to kickstart again.

I worked my own solution together that's a little bit of a faff really - but it was fun to do.

The long and short of it is: I wrote a script that checks if the device is on MacOS 12 onwards. If so, check what services are running and check if my admin accounts listed under its privs.
(Obviously if preMonterey, just run the command as is).

If RD is off and permissions arent set, do nothing (device is waiting for a MDM command).
If RD is on and permissions aren't set, run kickstart script via trigger.
If RD is on and permissions are set, do nothing.
If RD is off and permissions are set, remove permissions.
Else (unknown config).

I used the same logic to produce an extension attribute that returns the devices status. I could then use the EAs result to produce a smart group that runs the script at check-in.

A bit of the chicken before the egg sorta thing.
MDM needs to go on first, privs set afterwards.
If it's out of sync, reset.

I now flatten a computer lab, send the mass action MDM command to the devices as a group, and when they next recon, they get a 'second try' at running the kickstart command.

I don't normally need to send unix commands/restarts day 1 anyway, so I'm happy enough just having basic controls until the check-in policy kicks off and finishes the job. 

[musat]

We never ran into this last school year, but are now running into this with the new M1 MacBooks we got this year (odd since it's the same model as last year.)

@Qwheel, would it be possible to make your script available anywhere to see all of the different option you cycled through?

Thank you,

Tim

[Qwheel]

On a beach in Greece, back in a week or so!

I’ll come back and share when I’m near a computer 💁

[Qwheel]

Hi @musat,

This is probably going to be rather confusing but here goes...

Our kickstart script looks a little like this. 

#!/bin/bash

## Set whether the computer responds to events sent by other computers (such as AppleScripts and ARD reporting).
echo -e "\n## Set whether the computer responds to events sent by other computers (such as AppleScripts and ARD reporting)."
echo -e "systemsetup -setremoteappleevents on\n"
sudo systemsetup -setremoteappleevents on

## Enable remote login
echo -e "\n## Enable remote login"
echo -e "sudo dseditgroup -o create -q com.apple.access_ssh ## (this allows you to use the dseditgroup command)\n"
sudo dseditgroup -o create -q com.apple.access_ssh ## (this allows you to use the dseditgroup command)
echo -e "sudo dseditgroup -o edit -a ADMINUSERNAME -t user com.apple.access_ssh  ## (this allows you to add a specific user replace test with your user)\n"
sudo dseditgroup -o edit -a ADMINUSERNAME -t user com.apple.access_ssh  ## (this allows you to add a specific user replace test with your user)
echo -e "sudo systemsetup -setremotelogin on ## Sets remote login (SSH) on or off.\n"
sudo systemsetup -setremotelogin on ## Sets remote login (SSH) on or off.

## Enable remote desktop for specific users
echo -e "\n## Enable remote desktop for specific users"
echo -e "sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers\n"
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers

## specify users
echo -e "\n## specify users"
echo -e "sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users ADMINUSERNAME -access -on -privs -all -setmenuextra -menuextra yes -restart -agent\n"
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -users ADMINUSERNAME -access -on -privs -all -setmenuextra -menuextra yes -restart -agent

## Set whether the server restarts automatically after a power failure.
echo -e "\n## Set whether the server restarts automatically after a power failure."
echo -e "sudo systemsetup -setrestartpowerfailure on\n"
sudo systemsetup -setrestartpowerfailure on

## Set whether the computer will wake from sleep when a network admin packet is sent to it.
echo -e "\n## Set whether the computer will wake from sleep when a network admin packet is sent to it."
echo -e "sudo systemsetup -setwakeonnetworkaccess on\n"
sudo systemsetup -setwakeonnetworkaccess on

## Restart the ARD Agent and helper:
echo -e "\n## Restart the ARD Agent and helper:"
echo -e "sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent\n"
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

sudo jamf policy -trigger recon
exit 0

It's only like this as I've seen some different returning messages on macOS 11+ and wanted to be able to see what was causing it. Still works as it is though.
This is connected up to an ongoing policy available to all computers, but is only triggerable via a custom trigger/event. (In our case 'sudo jamf policy -trigger ardkickstart')

Below is a second script. This is set up similarly, scoped to all devices but only accessible via a custom trigger (in my case 'sudo jamf policy -trigger ard'). This is one that we run late in DEP enrollment. It'll check what version of macOS is installed, then filter through the logic accordingly.
If it's Big Sur or earlier, it'll just run the the 'ardkickstart' trigger as we did before. If Monterey or Ventura (haven't tested with Ventura yet), then it'll start checking status or remote desktop services and act accordingly. Previously I mentioned there being 4 conditional statements, it's been updated to include a couple more potential scenarios where a user is/isn't logged in.

#!/bin/sh
#On Monterey, Remote desktop is largely MDM enabled (but incomplete).
#Problem is, the button on JAMFcloud enables ARD for: all users, doesn't configure SHH, doesn't apply user specific permissions etc.
#Also, if we run the ARD script first, RD is listed on JAMF as being enabled, but you get a black screen and cursor. You then have to click the button and refresh 4 times to get anywhere.
#Solution: If we click the button on JAMFcloud, then run the usual ARD enable script, we get a working screen share including the permissions.
#I'll create an EA attribute using the below script to detail RD status at inventory update - this can be used to tell us which devices need the command to be sent.

swVersMajor=$(sw_vers -productVersion | awk -F '.' '{print $1}')
echo "\nMacOS version is $swVersMajor"
#If Big Sur or earlier, just run script as usual.
if [[ $swVersMajor == "12" ]] || [[ $swVersMajor == "13" ]]; then
	#Checks if the RD agent is running
	RemoteDesktopStatus=$(sudo launchctl list | grep -i 'ScreenSharing' | awk '{print $3}')
  	RemoteDesktopStatus=$(echo $RemoteDesktopStatus)
	#Checks if ADMINUSERNAME is listed in Network->Sharing list.
    LAPermissionsGranted=$(sudo dscl . -list /Users dsAttrTypeNative:naprivs | grep ADMINUSERNAME | awk '{print $1}')

	if [[ $RemoteDesktopStatus == "" ]] && [[ $LAPermissionsGranted == "" ]]; then
        echo "RD = Off. Perms = Empty.\nDoing nothing."
        #Do nothing, awaiting 'Remote desktop being enabled'
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing" ]] && [[ $LAPermissionsGranted == "" ]]; then
        echo "RD = On. Perms = Empty\nRunning kickstart ARD."
        #Remote desktop enabled, awaiting permissions.
        sudo jamf policy -trigger ardkickstart
	elif [[ $RemoteDesktopStatus == "com.apple.screensharing.agent com.apple.screensharing com.apple.screensharing.menuextra" ]] && [[ $LAPermissionsGranted == "" ]]; then
        echo "RD = On. Perms = Empty\nRunning kickstart ARD."
        #Remote desktop enabled, awaiting permissions.
        sudo jamf policy -trigger ardkickstart
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
        echo "RD = On. Perms = Set"
        #Do nothing, RD is configured.
	elif [[ $RemoteDesktopStatus == "com.apple.screensharing.agent com.apple.screensharing com.apple.screensharing.menuextra" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
        echo "RD = On. Perms = Set"
        #Do nothing, RD is configured.
    elif [[ $RemoteDesktopStatus == "" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
        echo "RD = Off. Perms = Set"
		sudo dscl . delete /Users/ADMINUSERNAME naprivs
        #Remove old permissions, I need to be flushed.
		sudo jamf policy -trigger recon
		exit 1
    else
        echo "Unknown config"
        #Do nothing.
    fi

else
	sudo jamf policy -trigger ardkickstart
fi
exit 0

Using the same logic, I built an extension attribute to report on a computers ARD status. This could then be used to create a smart group (which I discuss afterwards). You'll probably find this a bit easier to read.

#!/bin/sh

swVersMajor=$(sw_vers -productVersion | awk -F '.' '{print $1}')
#If Monterey or 'next' or earlier, report status.
if [[ $swVersMajor == "12" ]] || [[ $swVersMajor == "13" ]]; then
  RemoteDesktopStatus=$(sudo launchctl list | grep -i 'ScreenSharing' | awk '{print $3}')
  RemoteDesktopStatus=$(echo $RemoteDesktopStatus)
  LAPermissionsGranted=$(dscl . -list /Users dsAttrTypeNative:naprivs | grep ADMINUSERNAME | awk '{print $1}')

  if [[ $RemoteDesktopStatus == "" ]] && [[ $LAPermissionsGranted == "" ]]; then
    echo "<result>Off. None.</result>"
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing" ]] && [[ $LAPermissionsGranted == "" ]]; then
    echo "<result>On. None.</result>"
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing.agent com.apple.screensharing com.apple.screensharing.menuextra" ]] && [[ $LAPermissionsGranted == "" ]]; then
    echo "<result>On. None.</result>"
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
    echo "<result>On. Set.</result>"
    elif [[ $RemoteDesktopStatus == "com.apple.screensharing.agent com.apple.screensharing com.apple.screensharing.menuextra" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
    echo "<result>On. Set.</result>"
    elif [[ $RemoteDesktopStatus == "" ]] && [[ $LAPermissionsGranted == "ADMINUSERNAME" ]]; then
    echo "<result>Off. Set.</result>"
    else
    echo "<result>Unknown config.</result>"
  fi
else
	echo "<result>Pre-12.0.0</result>"
fi

I then created a smart group that utilised the returning information.
Computer group -> Member of -> "Student Computers Enrolled by DEP".
AND -> EA ARD Status -> is -> On. None.
OR 
Computer group -> Member of -> "Student Computers Enrolled by UIE".
AND -> EA ARD Status -> is -> On. None.

Members of this group would get a duplicate of the first 'ardkickstart' policy, set to run 'Once per machine', at recurring check in.

So to sumarise:
A computer lab get's imaged and starts going through the DEP process. Our ARD version check runs late during application deployment. When I get to the point of walking away, I log into JAMFcloud and send the MDM command to enable remote desktop on the devices. At this point they haven't finished DEP. As a number of applications have 'recons' attached to their application installation process, JAMFcloud is constantly reporting back via the EA on what the devices ARD status is.
The device will either get added to the Smart group and then run the ARDkickstart script to apply the permissions during DEP (check in policy). Or it'll get to the end and run the macOS version check script that determines if the device has had a MDM command and is sat waiting for permissions to be applied.

I guess it is complicated, but it's working for now!


 

[kacey3]

I was using a method very similar to this until very recently when I noticed that if I specified my admin users, it would fail, but if I simply opened up Remote Management to "ALL" it works fine. It seems like maybe there's some issue with -specifiedUsers. My script has not changed, but I can no longer remotely manage new deployments with this script unless I switch to "

kickstart -configure -allowAccessFor -allUsers -privs -all"

Obviously, for security, I would prefer to limit access, but until I figure out what's going wrong, this is my only solution.

[NicVerret]

@Qwheel Pardon the silly question, but how do I check if a device is waiting for a MDM command?

[kacey3]

Pending MDM commands can be found under both the Maintenance and the History tabs of a specific computer object.

[Left]

How to determine mac remote management on status in jamf Pro

[kacey3]

There is an Extension Attribute for that.