Jamf Remote Assist observations

[wildfrog]

Now that v11.1 is released comments are for the production release.

1) Performance still seems quite laggy. Almost unusable.

Setup - 

Control computer and target computer on the same LAN. Both on my desk. macOS firewall disabled on both. WAN is 600/40 business cable.

Actions (clicks, opening windows, etc) performed by the control computer appear instantly on the target computer - but take roughly 1.5 seconds to register on-screen on the control computer.

By comparison, under the same setup/conditions, Splashtop SOS has a lag of roughly 0.5 seconds (or less).

Looks like there's still a far amount of performance tuning to be done.

2) During a control session. . .

When the control computer moves the mouse, the cursor moves on the target computer.

When the user at the target computer moves the mouse, the cursor DOES NOT move in the control computer's session window. Items highlight when clicked by the user at the target computer - but no cursor movement. This creates two problems. . .

a) Only one person can drive at a time. I need to know if the user at the target computer is moving the cursor and preventing me from acting.

b) If i need the user of the target computer to demonstrate a problem, the inability to see where their cursor is and what it's doing really limits my ability to diagnose problems.

3) During a control session, the user at the target computer cannot capture screen shots. Several minutes after attempting to grab a screen shot, the target computer displays a dialog box stating "Your screenshot cannot be saved. Cannot write to intended destination." When not part of a remote control session, screen shots function as normal on the target computer.

4) There is no function for the user of the target computer to terminate a remote session from their end. The workaround presented during beta testing was to have the user lock their screen. This does indeed terminate the remote session, but presents a different set of problems. Many users set a hot corner to either Start Screen Saver or Lock Screen. And there's nearly no way for the admin at the control computer to know that ahead of time - unless the've enforced this setting fleet-wide, which I feel would be a bit too heavy-handed. As a result, it's way too easy for the admin at the control computer to accidentally  move the cursor to a corner which is set such that it would unintentionally terminate the session. 

[sjlo]

4) I haven't checked yet, but was told there would be an icon on the menubar where the user could terminate the session. Is this not true?

[wildfrog]

I haven’t seen anything in the documentation and nothing on-screen on the target computer seemed obvious in this regard. And if something was added, it would only have been in the last 2 weeks as there was no such functionality in the betas I tested.

[Keav]

My observations match yours. The lag is the biggest issue.

Remote clicks are instant on the target device but the remote session doesn't display them without a huge delay.

All the other things you mention are issues, too.

In its current form we won't be using it at all.

[jr139]

Aside from the lag, which we have as well. Has anyone had issues with the new tab not opening once the start remote assist button has been clicked?

I have gotten remote assist to work on my test laptop a several times, the new tab opens, I allow the session from the laptop and the session starts. But randomly when trying to start remote assist (into the same test laptop) I often get a spinning wheel on the remote assist button itself and the new tab never opens (no matter how long I wait). We've allowed popups, tried safari vs. chrome, there doesn't seem to be a rhyme or reason as to when it works and when it doesn't work. In fact, it was not working 5 minutes ago and now seems to be working again as of writing this. I would love to start training in some of our techs on this feature but it will be hard to do so until it is reliably working. 

[wildfrog]

I will say that based on the comments in the jamf-remote-assist channel in the Mac Admins slack, successfully initiating a session does seem a lot more hit-and-miss than it should.

The other issue that seems to be coming up is that unattended access simply doesn't work. What people are finding is. . .

• the control computer is prompted for an admin credential
• Control computer enters an admin credential
• the control computer is then presented with the login window at the target computer
• Control computer tries to log in, but the JRA session times out.

The problem with this is that you can't go back to the session because the target computer has been unlocked - meaning reinitiating the session requires a user to approve at the target computer. And the whole point was an unattended session because no user was present.

[jr139]

Thanks, I always forget to checkout the macadmins slack. Glad to know it's not just us!

[trevoredwards]

Matches my experiences as well. 

This is definitely not a production ready feature. 

The lag ruins the entire experience. Not being able to initiate an unattended session has been a huge L.  

[acb95978]

To piggy back off of this with our testing this morning, the initial prompt for the control computer to an unattended machine must be credentials to a local account, but it doesn't have to be to an Admin. However, if you don't use the exact same credentials at the second screen - the actual Mac login window - the approval dialog box appears preventing the connection, admin or not. You've just unlocked a remote computer, possibly with admin privileges, with no method of locking or restoring communication remotely other than the "Lock Computer" mdm command. Someone who had not seen this behavior would have no idea they've left a machine logged in. 

[wildfrog]

This was reported on the JRA channel on the Mac Admins Slack as well. Multiple folks report they'd initiate an unattended session, enter a credential, and it would sit at the macOS login screen until it timed out. Then after that, they couldn't re-initiate an unattended session because the computer was no longer in an unattended state.

I'm not sure I heard anyone report successfully doing an unattended session.

[bcbackes]

I have a case open with Jamf on this - seems to work fine for some devices but not others. I've provided some logs to them. They said it seems like Jamf thinks the device is offline. Even though it is actually online - I used Apple Remote Desktop to connect to it 5 minutes prior and could run a policy and recon command without issues. I've uploaded new logs for them to checkout so I'll see if they find anything new.

[wildfrog]

Yeah. . .so far my testing with JRA has just been my MBP as the control computer and another laptop on my desk as the target computer. And even in that best-case scenario I saw more than enough to make it clear that JRA was not ready for us to use. 

[lightumcc]

Yes, I also have this issue, I would very much like to know why this is, there is no error reported or useful information, I even tried reinstalling Jamf Remote Assist to no avail!

[AVmcclint]

As jamfcloud users, we just got our 11.1.1 update over the weekend. I immediately enabled Jamf Remote Assist and tried it out. My Mac and my test Mac were on the same network on my desk (both on Ethernet). I was glad to see that the user interaction was only as simple as clicking the Allow button. However, I also noted that it was very laggy. But I think the worst part is that I kept getting disconnected after a few seconds. Out of a dozen test sessions, the longest I was able to stay connected was 55 seconds.  I really have high hopes for this to be a viable replacement for GoToAssist/Resolve in the coming year, but right now, it is more of a proof of concept than anything else.

[AVmcclint]

ALSO ... After I completed my testing, I wanted to turn off Remote Assist so I unchecked the box in Settings > Computer Management > Security to automatically install profiles for Remote Assist, but the profiles it did install were not removed. It doesn't appear to uninstall the profiles once they are installed. I'm sure our security team might not be happy about that.

[techfan42]

I also got updated on our cloud over the weekend and was looking forward to trying this. Six computers so far have received the profiles but when I click on Start Session it just spins and nothing happens. I tried in Safari, Chrome, Edge and Firefox, the last three on both Mac and Windows. It looks like this service is in an early Alpha and probably shouldn't have been advertised.

[user-HHhlaAyKBB]

Running into the same issue this morning; super frustrating.

[Jason-]

Same for me.  Going to let this feature cook a bit longer before spending more time troubleshooting.

[Tonydig11]

We experienced the same as well. No need to go into details. just read above comments.

[bfrench]

Also seeing that unattended is not working at all.  Another odd thing I'm seeing, after trying to use Remote Desktop to view a computer I now see on that device "Install Jamf Remote Assist Settings Profile" over and over in Management History.

[bfrench]

Have a case open and sending lots of data.  At least we still have Remote Desktop set up...

[mline]

Is anyone having a better experience yet?
Ours is so laggy, that it's unusable.

[wildfrog]

Considering that as currently constructed, JRA essentially just streams an ongoing series of screenshots. So the lag seems to be baked in to how the tool is built. I honestly don’t know how they’d get acceptable (IMO) performance without a ground-up rewrite.