@garybidwell I'd miss Jamf Remote if it actually worked, but with my org still having most Mac users remote it was basically useless doe to the lack of an option to specify the IP address to use for connecting to the remote Mac. With users on our corporate VPN the only IP addresses Jamf Remote would try were the local IP address of the Mac or the public IP address of the VPN connection exiting our corporate network, neither of which would result in a successful connection. 

@sdagley Similar experience here. I just never used it: I preferred ARD and Apple's Screen Sharing. We use BeyondTrust (Bomgar) as well, which is ok.

Jamf Remote was slow and clunky. That's assuming when it worked.

yeah in that scenario with VPN connected users it was a complete failure, but as I still have several thousand macOS users on-site it was always quite useful tool for anything ad-hoc

Lucky you. :-) You mentioned Apple Remote Desktop earlier,  is that no longer an option for you? Definitely not the level of integration with Jamf Pro one had with a working Jamf Remote, but in my pre-Jamf Pro days I always found it useful for pushing packages or running scripts.

I have TeamViewer Tensor now and have ARD still, but there both not as elegant to use compared to how Jamf Remote worked.
The beauty of Jamf Remote is that when you need to remote it would create an temporary Screen Sharing session using the randomised password for access and then destroy it once the session was closed (and all audited), all with a single click.
If I do the same with ARD (or Screen Sharing) I have to swapped between the JSS/ARD and takes far more steps to achieve the same.
First need to look up the user, then there current IP, then look up the specific randomised laps password it would have for that that day and then copy all that in to ARD/Screen Sharing to do the same.

It would have nice if Jamf just updated Remote to run over 443 and NAT/VPN.
I didn't mind it was a little clunky and really needed to be re-written from the ground up or just build it into the JSS ;o)

Lets hope Jamf will give rise to a new Remote feature given the addition of 'Remote Administration' under Global Management, maybe a new add-on like Connect / Protect?!

Just weighing in.

JAMF remote has never worked for us.

In domain or off domain. Having said that, there is a tiny window after imaging where it works, but that time frame is useless.

I use ARD for on campus devices, and we have Bomgar for off campus session. Due to the nature of Bomgar and ‘screen recording’ only showing up after the representative console has been launched, the Bomgar experience is terrible (I say that though having not tried the new version that’s come out… maybe it’s improved?)

I find most support I give to staff direct via Teams now. I elevate a terminal window by logging in if required: most issues are user related though.

I doubt we’ll be getting VPN access for all staff and students… as long as I have VPN though, I can use ARD to get on site.

Jamf Remote - it's my go to tool for quick testing and even deployment for computer labs.

It gives me great feedback whilst it's deploying and also in the log.  The only way I can see for deploying with that gone is to set up a policy for each and every item I need to send to the labs and wait at least 15 minutes before anything happens.  When I'm in packaging mode I'm packaging and testing using jamf remote over and over until things are working right and then I can even deploy using the same tool without the need of a policy.

It's a straight forward tool - select the machines I want and deploy what I need from Jamf.  My workload has not been improved by the removal of Jamf Remote. 

Oh ... and we don't have Teamviewer and are unlikely to ever to get it.  I don't use the "Remote" feature in which you can interact with someones screen.  Our support teams use a different product for that screen interaction partly because it integrates with our Service Desk. 

I'm not a happy chappie on this one :(

I had a love/hate relationship with Jamf Remote. When the target Mac was on the LAN and resolving correctly etc it was a handly lifesaver for in-a-pinch moments like when I needed to perform an ad-hoc package push or script execution. I enjoyed using it but it certainly was showing it's age and I wasnt surprised to see it get deprecated.

I still use ARD from time to time, but I will miss Jamf Remote for certain tasks.

We have over 400 macs at my university and I have had a good experience using JAMF remote. I use it for pushing add hock packages and scripts, as well as rebooting machines when unable to remote. I use the advanced feature mostly when I need to re run a policy when there is only a manual trigger for it. I do use the screen control part of it but it is flaky sometimes and on some occasions has to be tried multiple times for it to connect. The integration was my favourite thing about the tool. Whatever we end up doing will be more work for me.

The university I work for will not be paying for Teamviewer, so I like others will have to look for another solution.
This will definitely impact my work load. I will miss this tool.

It appears that all Jamf has done in 10.40 is stop distributing a new build of the Jamf Remote application. The 10.39 version of Jamf Remote appears to still work like it has in the past. The Jamf Pro server also still permission sets for Jamf Remote use and every computer record still has management account information that is used by Jamf Remote for the ssh connection.

Just throwing my 2 cents in, Jamf Remote has worked extremely well for us over the years. We use various functions of it such as Remoting into machines on campus and over VPN (took a little Scripting/API magic to get that to work). We can live without the remote function but the ability to send commands to computers in mass is invaluable. This can also be done in ARD but the lack of a true database for ARD made Jamf Remote superior, IMO. ARD we would have to manually add new devices to the console, but with Jamf Remote they were just "there". I really hope Jamf takes some time and develop a new and improved Jamf Remote tool as I haven't found anything that comes close to the simplicity and robustness of Jamf Remote. If they would simply figure out the IP address issue (which isn't that difficult), we would be golden. Okay, rant over. Also if someone has found something that comes close, I'm open to evaluating it. 

Like others, the loss of Jamf Remote is going to hurt for lab deployments. Being able to ad hoc tasks to specific subsets of computers has been a staple of managing our multiple labs across campus.

Behind the scenes, Jame Remote is creating a policy. I would guess Jamf's replacement is to create more policies. I liked the one-off nature of Jamf Remote, but ultimately, you can do the same tasks from the Jamf Pro GUI by creating/editing policy.

You would still need to wait for the Policy's trigger to activate before that policy is run, where as with Jamf Remote the policy is run on-demand (via SSH of course) which we do not have the ability to do from the Jamf Console. Now if Jamf implements some way to run ssh commands from the web that would work as well. 

I feel like I'm the only person here that doesn't use Jamf Remote for the screen sharing function. I can use that in the screen sharing app. I can get the IP from either the JSS or our network controller. I couldn't give two sheets about TeamViewer. All our devices are on the same subnet and Screen Sharing works perfectly fine.

We actively utilized Jamf Remote's ability to push commands, packages, and scripts in bulk. We actually have an active need for this app, and Jamf is taking it away with absolutely zero offer of an alternative. I contacted support and was told that I just need to make a policy in the JSS each time. This is not an acceptable answer. They're taking away my power tools and telling me that the new norm is to use hand tools. You're taking a monumental step in the wrong direction, Jamf.

A perfect example is what I'm working on today. I now need to manually create a student account on 600 macbooks. This used to be a trivial matter. I would have all my techs set up the laptops at the same time, and push one command from Jamf Remote to create a new user. After 30 minutes of work, 600 laptops have student accounts which adds them to the student smart group, and then they automatically begin running all the policies attached to the student smart group.

I've been manually adding the student account on these computers for 2 days now... Thanks Jamf!

I'd just like to add a 'me too' regarding the quick test of deploying. packages.
There is no way I'll be allowed to use TeamViewer in our organisation. I do use Apple Remote Desktop how the quick and easy test of a new package or script, Jamf Remote is my go to! There are also a number of other tasks that I use it for by default - Binding to AD, Quick Inventory update of a machine, creating a new local user on a machine plus others on occasion.
All our machines are on site, so do not have an issue with networks, when we did go into lockdown and some users were working from home we used AnyDesk temporarily.

Has anybody submitted a 'Feature Request' to re-instate Jamf Remote via https://ideas.jamf.com ?

I feel Jamf have dropped the ball on this one and really need to listen to their customers better!

It will be interesting to see what if any chat about it is at the JNUC 2022 next week!

I didn't see a request, as AlanSmith suggested, so there is now https://ideas.jamf.com/ideas/JN-I-26370

I'm honestly glad to see Jamf Remote go away. Sorry, but pushing a package isn't the same as scoping or trigering or Self Service-ing a policy.

Pushing a package is like your waiter brings your steak to your table, and leaving behind the potatoes, beans, wine, desert, coffee.

Sorry to beat a dead horse, but unless the goal is to turn the clock back twenty years and creating monolythic packages again...

Good to hear that the 10.39 version was still working with 10.40. We are still running 10.39 right now. Curious to know if you upgraded to 10.41 and if 10.39 continues to work ok ?

I have not been able to use Jamf Remote at all since the 10.40 update (cloud hosted). It will correctly gather the computer, package, script, and printer info from the JSS.... but when you try to push any kind of task, it just returns a 502 error. It's as if the JSS allows Remote to read the database, but it's actively blocking it from running tasks.

I've been using  Jamf Remote v10.34 for both my on-prem (10.37.2) and Cloud (10.41.0) instances. No issues for me with either environment.

So just on update on my disappointment on the deprecation of Jamf Remote, it does look like Jamf was listening to admin feedback and there is light at the end of the tunnel for the remote access feature at least.
For anyone who missed the announcements prior this years JNUC 2022 that Jamf had purchase of several other companies, one of them being ZecOps security and another one mentioned was company that was focused on MDM solutions for MPS's.
One of its notable features of this MDM product was is its web base remote support ability, that was mentioned will coming over to Jamf Pro later sometime in 2023

I couldn't find a Jamf press link for this announcement but it was widely talked about at this years JNUC so I have left it unnamed.

But to quote from this MDM's web site:

Remote Control - Web Based

Access from any type of device ! xxxxxx enables access to any mac from any computer/smartphone/tablet... WITHOUT the need for PPPC user approvals.

If they can really do remote access to a Mac and view the screen with no user approval then I'll expect Apple to fix that ASAP. There isn't supposed to be any way to pre-approve screen recording, and user consent is required by design.