This should be interesting.

I support nearly 400 macs on my own and when a class is in session and an app is broken for whatever reason or an app is missing or it needs an update, I don't have time to create a policy and then wait for it deploy. I can just download it and push it out and I am directly controlling what machines get it.

In the new world I will find myself in without JAMF Remote, if I don’t have a policy, I have to create it on the fly, scope it then wait for the class to get it and that all takes time. I have academics complaining to me that the software isn't there for the class. Let alone testing the policy first which I am required to do.

For those in a university environment I am sure you are used to this scenario the academic not requesting the software just expecting it to be there.

Sending out a script for a quick fix for a location or a configuration change to a default login profile.

Or even sending out a jamf policy command to trigger a policy for machine that didn’t get it.

I could go on, JAMF remote wasn’t perfect but without it my life will get a whole harder. I will continue to use it until it either corrupts the database or JAMF restrict access

For a corporate space or even for our own staff space, having no JAMF remote isn’t a big thing. It’s not used here at all.

Yep. This just sucks. Just upgraded our on-prem JamfPro, and now I cannot use Jamf remote. Didn't use it for screen sharing, used it for quick, on demand commands - to run Adobe Remote Update Manager, or to just refresh the inventory, or push a quick package. Scoping a policy for EVERYTHING just isn't necessary in our environment.

It seems like JAMF has been failing us over and over and over the past few months:

Giving on prem users the "auto-patching" - then taking it away and making it cloud only in the next release

Unwillingness to switch to OAuth2 for SMTP to send notifications - many companies don't allow legacy.

Now taking away the useful Jamf Remote tool.

Growing tired of this, and wondering what functionality will be crippled upon each new release.

I just upgraded too.  I missed it in the release notes for 10.42. I would have waited a bit.  I see Jamf is recommending Team Viewer.  Anyone have much success using this?

This is another bad change. Creating a policy for a one-off action is extraordinarily clunky. Troubleshooting isn't done in a vacuum, and despite what you might've heard, Macs don't always work.

Absolutely agree with  Matt_saccento 

jamf remote was so usefull to run scripts or install package or other little thing directly to one mac o a groups without create a new policy.

Please Jamf re-enable this function!

Yep, Just rolled back to JAMF 10.41 and we will have to stay here now. Without this tool I don't know what to tell management of the benifit staying with JAMF and not moving to MS Intune which we are already using for our iPads.

I can only assume the blocking is to force the use of other tools(Teamviewer).

I get the remote screen sharing part of it being un supported but the rest of the features I dont understand. I would be happy with just that part of it. Teamviewer is also a no go with our university and as added bonus as far as I am aware you need internet for it to work, which none of our macs have without logging each into our internet access portal. So unless something changes I cannot see us staying with JAMF.

you can still use the 10.39 version of Jamf Remote (still works perfectly fine with Jamf Pro 10.42 and macOS 13.x), its just no longer support or included in the Apps package download.

For our installation we have just packaged Jamf Remote independently to the main Jamf App suite so admins can still download as needed when signing into Self Service

@Mojinkii I think you will struggle trying to manage Mac's in the future with no internet, specially with Microsoft Intune as unlike Jamf Pro, it has no on-premise version as its a Azure cloud service only at all and can only ever function with devices connected to the internet.

Unfortunately doen't work 

"This account does not have privileges in the jamf pro server to use jamf remote"

but i've all permissions on my  cloud jamf pro server

😪

@claudio_provini @Mojinkii I stand corrected, I only just had our environment updated to 10.42 and just logged in to Jamf Remote for the first time now and get the same issue.

On further diagnosis I see the whole permissions tab in System - User accounts and group - user - Privileges  - Jamf Remote has been completely ripped out the JSS

Wow, that's drastic as it could have been left in (like it was in 10.40/10.41) to continue to function for those that still wanted to use it.

@garybidwell As you have seen the permissions are missing to run it. I forgot to add that in. We have Azure and we have intune working already as I mentioned, our ipads are managed through it.

I have complained about the lack of internet for some time. Microsoft traffic is allowed through without the need for the internet login. So yes, no internet is a pain

I haven't even seen or maybe I missed it why JAMF Remote was removed in the first place. 

@Mojinkii I never saw anything from Jamf listing specific reasons, but what made Jamf Remote essentially unusable for my org is that it can't connect to a Mac on VPN. Jamf Pro only collects the local IP address of the Mac and the IP address that the Mac was hitting the Jamf Cloud hosted JSS from (which will be one of the public IP addresses of our network). Neither of those addresses will allow Jamf Remote to connect.

Why in the world was Remote shut down? It was a viable local solution. It was handy and available. Why in the hell did this get pulled????

Just curious, what did Jamf Remote do that SSH, Screen Sharing, and judicial scoping of policies can't do?

Well, for one - it was all of those in one place. Also, the ability to run a script scoped by selecting a handful of enpoints in a GUI is way less cumbersome than doing it all through the WebGUI, especially for one off pushes, or for less critical testing. Not to mention, you could see the command running in realtime, and get feedback from it immediately. No waiting for check in, and then waiting for the policy to run, and guessing if all the endpoints got the command. you could see right then and there if it failed.

For my environment, it's way handier to do things this way - we don't run a corporate environment where we just scope out and trust it'll get handled. They are classroom labs, and oftentimes I need that direct feedback behind the scenes - and having it in one app was just easier. 

I think the major sticking point is that it was a viable solution for many - and Jamf just keeps forcing our hand to Jamf cloud by taking features away

I couldn't agree with @adeane  more. You get no feedback from a policy if it's running or not, until it has actually deployed. So if it never deploys you have no idea why. I manage the macs on 4 different campuses from a central location so I can't just go visit the machine. I rely on JAMF remote so I can check what is wrong with the machine. I can run the trigger from JAMF remote on that machine and see why its not running.

The instant feedback of JAMF remote has been invaluable to me but the biggest thing is the integration to the system. Access to the groups, scripts and packages.

We use JAMF pro not cloud, so for our environment JAMF remote worked very well.

Without JAMF remote I have lost my only sticking to point for JAMF. Unless something changes, we will unfortunately be moving to Intune in the new year.

Again though, for a corporate space it really isn't a big loss. It's not used in our staff environment at all.
In saying that, our staff environment will be moving to Intune. Hence why I'm being pushed into it.

I personally think JAMF have made a mistake with this. Management now days are very much cost orientated. We lost a lot of students due to covid and it hurt the Uni as I am sure it did everywhere else. So I am sure a lot of places will be facing the same thing as I am. Not a choice I want but I don't make the choices.

Jamf Remote was a great tool that worked well in our environment, it gave our IT helpers a quick and easy way to help people. I'm beyond frustrated it has been removed as this will slow down our ability to help people and I'll have to give access to policies to our lower tier technicians because what could possibly go wrong there, right? Now our only hope is Apple Remote Desktop. So yeah, no hope.

But hey, it's all good, with Jamf Remote out of the way they can focus on other excellent user experiences like pointlessly redesigning the Settings panes for the 25th time. 

I used JAMF Remote for many things including instant installs for whole lab areas instantaneously when I clicked start I didn't have to wait for a 5-minute window to start.  Also, it was easier to take care of some of my lab updates making sure that they were finished and not waiting for something to check-in.  Sort of a piece of mind thing, I've had many crashes using the web interface as opposed to using the JAMF remote.

Why is it that JAMF and other companies like them don't check with end users before doing insane things like this..  I guess I'm just tired of corporate thinking instead of end-user needs.

For the first time since Jamf killed off Remote, I am trying and utterly failing at updating University computer labs in which all computers are frozen Deep Freeze. Being able to push out scripts and updated packages instantly, I was able to get all of my lab computers updated in 2 -3 hours. I've been working for 7 hours on one lab with 11 computers and STILL NOT UPDATED!!! Totally flying blind since you have no idea when a policy is running until it's completed. The best part is I speak with a Jamf support specialist to see if they have ideas, espcially that 2 out of 11 computers wouldn't check-in, I was told to update the jamf framework using the API which totally killed the Jamf connection forcing me to wipe them and re-provision. I've even tried using Apple Remote Desktop to push unix commands to have the policies run since you at least get data back on what's happening but that is clunky as hell. Why there isn't a way to send mass remote commands to have policies run is insane to me.. especially when your killing off the Jamf Remote functionality... Some of us used Remote for other than screen sharing. 

I totally agree to your frustration. It’s senseless that no one from JAMF management never asked anyone in the community how they use the Remote tool. It’s almost understandable I too use it to push all my rooms in a short period of time. Now you have to play the waiting game to checkin to install. Also, I had some Adobe failures using this process which I never had using the old process with Remote. 

You might be able to do this a little easier with making a script file utilizing custom triggers. The command would look something like:

/usr/local/jamf/bin/jamf policy -trigger <triggername>

And just set up your custom trigger in the policies. Utilizing custom triggers in this way, you'll see their progress in the Terminal window that pops up so you have some visual feedback to go off of. Granted, this still requires touching all the computers by hand, but it's a step above turning them on and waiting for the annoyingly random check-in to occur. 

The issue with that is you still need to do it as a policy and the only feedback you get on a policy is "pending" or "completed". Doing what you suggested with a policy trigger is what I was trying with Apple Remote Desktop but super clunky and within my environment, I have to have my computer on the same vlan which is very limited and having remote management on will make my security team flip a lid.

I haven't even started Adobe updates. That doesn't start until wednesday for me. The labs i'm trying to update just have 14 app updates and OS updates... shouldn't be that hard.

We've been using Apple Remote Desktop since the beginning of our Apple deployment in 2004, and yes, it has always been abhorrently buggy and unreliable. How Apple can't fix this tool to work better with native macOS capabilities is absurd, but that's a discussion for another board. ;)