Jamf Remote Black screen On Catalina

[AdamCraig]

We are trying to use Jamf Remote on Catalina, we have a profile installed that enables Kickstart ARD, and a script linked to a self service policy to turn on Remote Login and Remote management in system preferences to so we can use Jamf remote to screen share and provide remote support to our users.

With the computers we're testing on Catalina we can remote screen share, but we only see a black screen. If we manually enable the options in system preferences everything works normally. However many of our users are not admins so they are unable to manually enable those options. Is there a way around this?

EDIT: For some reason the quoted script Bolds the lines that I commented.

#!/bin/bash

# script is designed to check the remote login and remote management boxes in System preferences>sharing
# this should enable jamf remote to log in.

# Referenced these links in creating this script
# https://www.jamf.com/jamf-nation/discussions/29233/enable-remote-management-full-control-in-mojave#responseChild184447
# https://www.jamf.com/jamf-nation/discussions/33575/jamf-+-pppc-+-catalina

## Turn on Remote Desktop Sharing, allow access for all users, and enable the menu extra:
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -privs -all -clientopts -setmenuextra -menuextra yes

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

# remove the existing SSH access group (revert to all user access)
dseditgroup -o delete -t group com.apple.access_ssh

# ensure SSH is back on
systemsetup -f -setremotelogin on

jamf startSSH

exit 0

[GregE]

Came looking for a solution as well. We've been able to VNC from Windows DameWare to our Macs in 10.14 but are now hitting this black screen issue in 10.15.2. My guess is that something (vncagent) needs to be enabled in Security & Privacy -> Screen Recording in order for it to work.

I'm using:
Config Profile to enable "com.apple.screensharing.agent"
Then:

#!/bin/sh
#Enable Screensharing
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -allUsers -access -on -privs -all -clientopts -setmenuextra -menuextra yes -setvnclegacy -vnclegacy yes -setvncpw -vncpw passwordgoeshere
#Restart the ARD Agent and helper:
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent

[el2493]

Did anyone figure this out? I'm having the problem myself in Catalina. If I use Jamf Remote to connect to a VM that's in Jamf I can only see a black screen with a mouse in the Screen Sharing window, but in the VM window I can see the mouse is being moved over the regular background. I had a similar issue with GoToAssist, and that definitely did require enabling screen recording and a few other options.

[AdamCraig]

We gave up on jamf remote when we got busy with other projects.

[el2493]

In case anyone else experiences this, I was able to resolve it by going to the computer I was trying to connect to and running the tccutil reset ScreenCapture command in Terminal. There was seemingly no reason why this should've worked (I hadn't denied access to any prompts, and even if I did I think the app should've appeared unchecked in System Preferences>Security>Privacy and there was nothing listed there as either approved or denied), but it did. When I tried to connect with Jamf Remote again it immediately worked, though it didn't prompt to allow Screen Recording and there was still nothing listed as approved for Screen Recording in System Preferences. I had opened a ticket with Jamf Support because they said something SHOULD be listed as approved under Screen Recording, but as of now it seems like something somehow got denied in PPPC even though after resetting it there was no way to either approve or deny it (it just worked).

[JCMBowman]

Thanks for this tip! running that command fixed a machine I just wiped and reimaged and got the black screen when using ARD.

[kwoodard]

This post wins the internet cookie of the month. Been pulling my hair out trying to fix this.

[prepapps]

This really helped us-- but we're having the "black screen" issue in Apple Remote Desktop. We've gotten past the black screen issue with the help of el2493's tccutil reset ScreenCapture command...but now that we can see, we still can't control through ARD. Anyone have further thoughts? I might start a new thread...

[el2493]

@prepapps do you already have a PPPC profile created to approve the Screen Sharing application for PostEvent? If not, look at this thread https://www.jamf.com/jamf-nation/discussions/29233/enable-remote-management-full-control-in-mojave, and scroll down to 5/11/2019 (jared_f's post).

[NoahRJ]

I did some additional digging from the TCC.db when Remote Management is programmatically enabled (many thanks to @el2493 for the suggestion to reset ScreenCapture perms) and I can see corresponding entries for kTCCServiceScreenCapture + com.apple.screensharing.agent in the DB.

Sure enough, running a tccutil reset ScreenCapture removes that entry, but it seems like you can't target any combination of com.apple.screensharing.agent or com.apple.screensharing to specifically remove that entry. That's a problem if you're reenabling or reenforcing Remote Management on a machine where somebody may have already allowed Screen Capture access for Zoom, Skype, etc.

Probably nothing to be done outside of resetting all perms, since tccutil is the only option to modify perms in the DB, you can't allow Screen Capture with PPPC, and of course modifying the DB directly is protected under SIP.

Yet another terrific change from Apple...

[ooshnoo]

I just hit the Enter/Return button and black screen goes away

[franton]

Basically the old CLI tools for enabling Screen Recording don't work as expected anymore. They actually give error messages to that effect when you run them.

The only way to avoid the black screen is either 1) enable by hand or 2) enable via Jamf MDM command. You can find that button in the computer inventory records.

You're running into the screen recording restrictions basically. The above two methods are the most effective way of dealing with this. Keep an eye for changes coming in Big Sur too.

[GregE]

We've been fine since using an API to push the 'enable screen recording' option in Jamf.

[cris_lehman]

@GregE Can you expand on this? How are yall doing that?

[GregE]

Create a standard user account that has:
- Jamf Pro Server Objects -> Computers -> Create & Read
- Jamf Pro Server Actions -> Send Computer Remote Desktop Command

Then use the script to get your API to send the "Enable Screen Sharing" Management Command from Jamf (we've got it smart grouped for users who don't have screen sharing enabled).

#!/bin/bash
#
#Variables
apiURL="https://your.jamfcloud.com/JSSResource/computers/"
apiUser="yourAPIuser"
apiPass="yourAPIuserpassword"
privs="-DeleteFiles -ControlObserve -TextMessages -OpenQuitApps -ShowObserve -GenerateReports -RestartShutDown -SendFiles -ChangeSettings"
#
# Get the Serial Number of the Machine
sn=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}')
echo "Serial Number: $sn"
####
#Get ID by looking up Serial Number
echo "Getting computer information"
answer=$(/usr/bin/curl -s -H "Content-Type: text/xml" -u ${apiUser}:${apiPass} https://your.jamfcloud.com/JSSResource/computers/serialnumber/$sn/subset/general )
echo "Getting Jamf ID"
jamfID=$(echo $answer | xpath '/computer/general/id/text()' 2>/dev/null)
#
echo "Jamf ID $jamfID"
#Removing existing settings:
echo "Removing existing settings"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -verbose -uninstall -settings -prefs

#Send MDM command to Enable Remote Desktop
echo "Sending MDM command from JSS"
/usr/bin/curl -s -u ${apiUser}:${apiPass} https://your.jamfcloud.com/JSSResource/computercommands/command/EnableRemoteDesktop/id/$jamfID -X POST

#Preferences
echo "Enabling for specific users"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers 
echo "Limiting access to youradminaccount"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -access -on -privs -all -users youradminuser
echo "Setting option to show connection"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -clientopts -setmenuextra -menuextra yes
echo "Restarting the ARD Agent"
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -restart -agent -console
echo "Finished"

[EdenJAMFAdmin]

The script that @GregE posted works like a charm, with a caveat.  Initially the script was not working on Monterey, and potentially Big Sur as well.  Looks like Apple has made some changes to the xpath command so it wasn't parsing the JAMF ID out of the $answer.  As such, I still have my old plain Kickstart script for Big Sur and older machines, and then I scoped this script to Monterey and newer with the following change.

Original command:

echo "Getting Jamf ID"
jamfID=$(echo $answer | xpath '/computer/general/id/text()' 2>/dev/null)

Updated command:

echo "Getting Jamf ID"
jamfID=$(echo $answer | xmllint --xpath '/computer/general/id/text()' -)

I guess you could consider coding a version check and include both versions of the command, just not what I needed.

Thanks to this post, https://community.jamf.com/t5/jamf-pro/request-for-a-renaming-script/td-p/237781#responseChild210111 that helped me figure out that change.

[el2493]

I use this function in a script to account for differences in xpath:

xpath() {
    # the xpath tool changes in Big Sur 
    if [[ $(sw_vers -buildVersion) > "20A" ]]; then
        /usr/bin/xpath -e "$@"
    else
        /usr/bin/xpath "$@"
    fi
}

 I don't think I came up with it but not sure where I got it from. Essentially just put it at the beginning of your script and then any time the xpath command is called it'll use the function to determine the appropriate command.

[upkeepjc]

@GregE could you elaborate a little bit more on creating a JAMF standard user?

[GregE]

@upkeepjcin your JSS head to Settings -> Jamf Pro User Accounts & Groups -> New -> Create Standard Account.
Create a username/password that you want to put in the script above, and make sure it has (and probably ONLY has) permissions to do the above commands that you want. ie: if that account was compromised and someone got in to your JSS with it - you want to limit what they could/couldn't do.

The API then uses that account to essentially "log in to Jamf and manually send the 'Enable Remote Desktop' command" without you have to do it for hundreds/thousands of devices.

[upkeepjc]

@GregE thanks so much for the clarification/instructions.  I will give it a shot and let you know.

We use BeyondTrust remote support here so will this essentially check the box for that application within Security & Privacy -> Privacy -> Accessibility for the jump client?

[medmason]

All of these are very elegant solutions. If you are like me and needed a quick and dirty way to get a stubborn 11.6 machine to cooperate, here's what I did:

`tccutil reset ScreenCapture` over SSH, then in Jamf, under Management, disable, then re-enable Remote Desktop with the buttons at the top of the Management Commands pane. In fact, you could probably skip the tccutil part, but I have not tested that approach. 

Definitely going to investigate and implement one of these more elegant solutions when time permits.