@taugust04 that is exactly why I chose to pull my post from the Jamf forum and repost on ADC. I highly encourage people to check out the post and respond to it there if you are an ADC member. Only Apple knows the future of what I discussed there. I’m honestly hoping enough of us will “Me too” that post explaining the situation and maybe just maybe someone official will say something.
When my Apple rep sent me the KBase article explaining the changes in ARD, within a day, I gave him the same write-up I posted on ADC. I hesitate to push anyone at Apple more than that, but it's all I can convey without breaching NDA on pre-release software.
Now that Mojave is out NDA is over. It looks like on the shipping build, the directory services technique I referred to in this post was shut down and it was actually as late as Friday seemingly that it was shut down from the timestamps. I was kinda hoping that technique didn't run aground of Apple's new guidelines, but figured it wouldn't last long. Hopefully they will release some sort of profile to allow for that. It's about the only way out now.
It looks like the kickstart method is still working at least in 10.14.0.
I tested it today with both a fresh install and an upgrade.
Have just tried it and you CANNOT enable screen sharing/ARD via the kickstart command. You are met with:
Warning: macOS 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.
Im seeing the same results as @allanp81 with Mojave 10.14.0 (18A391). Kickstart no-worky.
Looks like I need to leverage Jamf Remote and TeamViewer more.
Anyone figure out how to get control working? I set up a computer manually and checked all the buttons to turn on it on, tried to connect from another machine and.....was only able to observe.
On my deleted posts, I had originally noted that it worked during testing despite the gnarly warning. I got my inspiration from a post on Rich Troutons blog. Sadly this got shut down in the shipping version.
In reality, our IT group is fine with Jamf Remote alone, but I actually still have teachers that use ARD to interact with lab students. Setting that up now will require turning Remote Management on by hand in the Sharing pane as an admin and setting the permissions on each client in the lab. Any good ideas for that kind of setup?
I use screen sharing on a daily basis so not being able to enable this will massively affect my ability to work. Thanks Apple!
So much for zero touch deployments. This really is a inconvenience.
Has anyone opened a ticket with JAMF support to see what their stance is on this?
I can understand restricting this on a consumer device but to not give admins the ability to enable this is ridiculous. Fingers crossed they'll be a config profile setting that will be able to enable it.
I’m hoping for a profile soon myself. I’m also watching the developments on Apple Classroom on Macs. For IT purposes, I know we are on our own unless a profile shows up. For instructional tasks though, this is going to be messy to get a lab up and going.
This is quite confusing. On Mojave release we just went through a DEP enrollment and the kickstarter binary enabled remote management and I can connect via vnc:// and also through ARD to control the machine. Why are folks seeing different results?
@sullrich
We're seeing differently. I'm uncertain why, although we do get an explicit notice when enabling via kickstart that it is not supported on 10.14+
>Warning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.
We can connect just fine through VNC but can't drive.
Complain to your Apple reps, please. This is just stupid on Apple's part. There's no grandiose plan here, it's pure stupidity.
Btw, you can still turn on everything BUT CONTROL using the same old commands. I suppose that's something.
Are they trying to make me switch to Windows? I'll do it! I swear I'll do it! HOLD ME BACK BROS
@sullrich, there are no different results. People did not test thoroughly.
There are two situations:
1) Computer was upgraded to Mojave, in which case the settings carry over and everything is great. Works
2) New computer, you cannot script enable ARD CONTROL. Keyword, control won't work but you can view, using the old commands.
Simply checking and unchecking the Remote Management box in system preferences is a fix.
I was doing some testing on this today and I'm willing to bet money you can get this script enabled. I bet it can be done with applescript. Keep trying boys!
@tnielsen
So the kickstart commands can still enable all functionality other than screen sharing/control options? Packages can still be installed, Scripts run, ARD fields populated, etc?
Can you clarify - not working for me.
Clicking in the preference pane is not a viable option in my environment (plus, I lock the Sharing pre pane anyway).
I contacted my rep. No feedback yet.
Does Jamf Remote screen sharing work in Mojave on a system that doesn't have remote management already manually enabled? From 10.7.1 release notes:
Further Considerations
Because of increased user data protections with macOS 10.14, you cannot enable remote management remotely using the SSH protocol. To enable remote management on computers with macOS 10.14, the user must click the Screen Sharing checkbox in System Preferences.
I haven't had a chance to test yet as I haven't enrolled a factory install of Mojave into Jamf Pro yet. Added to the list.
Would be interested to see what people come up with, we have a fleet of ~650 macOS machines of varying ages and we use Bomgar as our remote desktop software.
It seems that we have the same issue as everyone else, we can view but cant control natively on 10.14.
I haven't looked into if JAMF Pro 10.7.1 allows any extra control of this or not, it certainly cant be done in 10.4.1.
it seems apple has a longer term strategy/roadmap that they aren't ready to reveal. Over the years I've noticed they take these small steps which seem to be counter productive at the time, but once the grander vision rolls out over the next months/years it starts to make sense, or at least you can see why they did those things.
To comment at what @jwojda posted above, I heard of a rumor that the Classroom App will be able to control Macs and IOS Devices simultaneously soon. (Classroom App for Macs to control iPads is already out I believe) This is exciting news for EDU. We are currently using Impero Edu Pro, its usable, but still buggy and slow. If Classroom App can do the same thing what Impero does natively, cant wait!
@dstranathan
So the kickstart commands can still enable all functionality other than screen sharing/control options? Packages can still be installed, Scripts run, ARD fields populated, etc?
Can you clarify - not working for me.
The behavior you're seeing is view screen only, all other functionality is no-go?
Here is what i am getting on fresh install of 10.14.0 DEP enrolled mac. Fully formated drive and clean install from USB. Remote control is working
Executing Policy ANZ: Enable ARD
Running script EnableARD...
Script exit code: 0
Script result: Clearing ARD Settings
Starting...
Removed remote control privileges for all users.
Done.
Starting...
Setting allow all users to NO.
Done.
Starting...
local-admin: Set user remote control privileges.
local-admin: Set user remote access.
jamfmgmt: Set user remote control privileges.
jamfmgmt: Set user remote access.
Done.
No admin group specified skipping directory authentication config
Starting...
Set the client options.
Done.
Starting...
Activated Remote Management.
Stopped ARD Agent.
Done.
Here is my script:
#!/bin/bash
###################################################################################################
#
# enableARD.sh Ashley Stonham <reddrop>
# v1.0 - 06/12/2016
#
# Enables ARD for specified users and optionally configures for
# directory based authentication.
#
#
###################################################################################################
ADMINUSER="$4";
ADMINGROUP="$5";
DEFAULTADMIN="jamfmgmt";
KICKSTART="/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart";
createARDAdminGroup() {
dscl . -read /Groups/ard_admin > /dev/null 2>&1
if [ $? -ne 0 ]; then
echo "Creating group ard_admin";
dseditgroup -o create -r "ARD Admins" ard_admin;
else
echo "Group ard_admin already exists";
fi
}
addAdminGroupToARD_admin() {
echo "Adding $ADMINGROUP to ard_admin";
SAVEIFS=$IFS
IFS=$(echo -en "
")
ADMINGROUPS=$(echo "$ADMINGROUP" | tr "," "
");
for AGROUP in $ADMINGROUPS; do
echo "GROUP; $AGROUP";
dseditgroup -o edit -a "$AGROUP" -t group ard_admin;
done
IFS=$SAVEIFS
}
if [ "$ADMINUSER" == "" ]; then
echo "No admin user specified";
ADMINUSER="$DEFAULTADMIN";
else
ADMINUSER="$ADMINUSER,$DEFAULTADMIN";
fi
echo "Clearing ARD Settings"
$KICKSTART -uninstall -settings
#ENABLE ARD FOR DEFAULT ADMINS
$KICKSTART -configure -allowAccessFor -specifiedUsers
$KICKSTART -configure -users $ADMINUSER -access -on -privs -all
if [ "$ADMINGROUP" == "" ]; then
echo "No admin group specified skipping directory authentication config";
$KICKSTART -configure -clientopts -setreqperm -reqperm yes
else
createARDAdminGroup;
addAdminGroupToARD_admin;
$KICKSTART -configure -users ard_admin -access -on -privs -all
$KICKSTART -configure -clientopts -setreqperm -reqperm yes -setdirlogins -dirlogins yes
fi
$KICKSTART -activate -restart -agent
exit 0;
I could possibly be because i am using ard_admin groups rather than specifying the users. Apple might have overlooked that hole and will be patched eventually.
If i try to run the script locally on my machine it fails. It only works when pushed out via Jamf.
I do also have the Jamf Config profile to allow the Jamf Agent increased privacy controls and I am also running 10.7.1.
Privacy Control Config Profile here: https://github.com/jamf/JamfPrivacyPreferencePolicyControlProfiles
Tried your script and still get the warning that it can't be enabled.
Maybe it works for DEP enrolled devices only? I can't test this yet unfortunately.
If i try to run the script locally on my machine I cant. It only works via Jamf.
I do also have the Jamf Config profile to allow the Jamf Agent increased privacy controls and I am also running 10.7.1.
Privacy Control Config Profile here
I just tried on a non DEP enrolled Mac and it showed the warning. So it looks like DEP is the reason it is working for some and failing for others.
However despite getting the warning i was still able to remotely control the mac.
Just wanted to come back and post this article here in case anyone else is searching for it:
Use the kickstart command-line utility on macOS Mojave 10.14
https://support.apple.com/en-us/HT209161
If the device is enrolled in MDM, kickstart can still be used to enable full remote control with the addition of a Privacy Preferences Policy Control payload.
