With the recent announcement of the removal of Back to My Mac and Apple's recommendation to use ARD as a replacement, I was hoping to see some love tossed ARDs way. However, I am hearing rumblings that the kickstart command may also be in the crosshairs for removal/nerfing in the near future. As of Beta 8, I am seeing an ominous cloud on the horizon.
Setting the config and activating appears to go as expected with an added twist:
kickstart -configure -users user -access -on -privs -all -activate
Returns the following results:
Warning: macos 10.14 and later only allows control if Screen Sharing is enabled through System Preferences.
Activated Remote Management.
user: Set user remote control privileges.
user: Set user remote access.Done.
The Warning has me troubled.
At this time, Beta 8 is allowing the use of the kickstart command but the command and the System Preferences user interface are not aligning. Nor do I have full control from kickstart. For example, the command above should have checked all the options in the Options... UI. However, when working directly on the machine (including after a reboot), no options are enabled. Yet I can observe the machine. Yes, kickstart started the service and granted me observe rights but not control. Likewise, I can run UNIX commands, copy files, and likely use every other feature of ARD other than control, or let users know when I am observing.
To the end user, the service is on. Yet no options are enabled. Yet I can observe and not show the user that they are being watched. Something is very wrong here.
It is not until physically touching the machine and checking the Remote Management service that control is granted.
For those of us doing fleet deployments, the kickstart command is heavily leveraged during initial device setup to enable and configure the service, commonly through a script delivered by the management tool. Sure the command's syntax is weird and funky, but it is what gives it its charm and it works and has worked for years. To have that function removed would be very impactful. Forcing the physical touching of devices to enable the full function of the service is not an option. This is as bad as the start of 3rd party kernel extensions.
Isn't the entire point of the nexus of DEP, VPP, and an MDM to be able to avoid physical contact with, and manual configuration of, individual devices? With the hoops introduced with secure token and 3rd party extensions, it feels like there is more touch these days then there should be. And now the guidance appears to be to touch every device to enable remote control?!?
Tell me there is a profile in the works to control and enable this service? Removing a function without offering a reasonable replacement seems like a poor decision. Likewise, if ARD is changing, perhaps a beta release with detailed Release Notes telling the community what your vision for the product is would be a good idea. Or, tell me this service is going to be included in a DEP authorization process, allowing DEP enrolled devices the ability to allow an admin at an MDM console to configure and activate this service. Non-DEP'd machines are not my concern. Please don't make fleet deployment more difficult.
Thanks for reading.