Just making my views public on the decision to deprecate Jamf Remote app in Jamf Prop 10.40 as I personally feel its the wrong decision.
Jamf Remote has been removed from Jamf Pro.
This includes the screen sharing workflow using Jamf Remote. Jamfrecommends to use TeamViewer for remote administration. For instructions on how to integrate TeamViewer with Jamf Pro, see TeamViewer Integration in the Jamf Pro Documentation.
Having just completed a large deployment of the TeamViewer Tensor and its integration to Jamf Pro and Microsoft Intune, its really a poor substitute to the usability of Jamf Remote.
While Jamf Remote lacked support for NAT and accessing devices off local LAN is made up for it for ease of use and its integration to Jamf Pro (it had a very similar ease of use like Apple Remote Desktop) and its ability to ad-hoc install a package or perform certain functions without creating a policy in the JSS makes it a extremely useful tool.
The TeamViewer integration into Jamf Pro is a real mess in its usability, so much so that in its current state I would go as far as saying its a waste of time as the user experience is so poor you may as well just use TeamViewer Tensor as a standalone product without any integration at all.
From deployment, updating the agent and to its hoop-jumping with Self Service its not a very pleasant experience for both the end user and for the admins.
This is even before you get to the licensing model and the added expense of purchasing TeamViewer to replace the previous "free" ability of what Jamf Remote provided.
I'll make sure this is fed back to our Jamf success manager, but surely I not the only one that's going to miss Jamf Remote in the future?
@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.
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'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.
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.
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.
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.
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'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...
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:
Access from any type of device ! xxxxxx enables access to any mac from any computer/smartphone/tablet... WITHOUT the need for PPPC user approvals.
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.
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.
@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.