For those of you who are interested in or are currently using a remote assist solution, I’m curious and interested to find out:
Appreciate any feedback/thoughts/comments you might have!
I'm tagging in some people who were interested in the Remote Assist beta to provide some feedback here.
@NVergin @chadrick @racreate @dagryph @MikeHill @elior @CFaust @steven @kelly @krichard @chhetriabi @iotx86 @rlyons @Dariusnl1 @lmcfadden @kenshep @jaggrey @roscoe_matthews @dgp_orthofi @Shehwar @edan
Like someone's post? Give them a kudo!
Did someone's answer help you? Please mark it as a solution.
Ongoing remote support for troubleshooting is our primary use, but we use it heavily during onboarding remote machines as well. It's helpful for training as well.
We use it constantly. All day, every day. We have two current options, Kaseya VSA's LiveConnect as our primary. It forces a note before connecting, pops up a note to the end user on start/stop, records the whole session, and has great logging for audits. Our backup option that is MUCH more mobile friendly but less enterprise-y is JumpDesktop.
LiveConnect is incredibly powerful beyond just remote control. We need more advanced RMM features that JC currently has, but we're always trying to simplify our tech stack and lean more deeply into existing tools.
I requested access to the beta, but have yet to receive access to that. But from the initial screenshots, it appears that remote "assist" 100% required the end user to be involved in allowing access. I can appreciate that from a security perspective, but that would be a deal breaker for us. Hopefully there will be some admin side configuration options for how sessions can be initiated. As well as some granularity to allow for different policies for different systems. LiveConnect has an option to allow the end user to prevent remote access, but we disable that and make it clear in our IT Policies how we handle remote access and notifications.
Thank your for your feedback and comment @lmcfadden! The Remote Assist Beta will start this quarter I'll make sure that you are added to the list. And you should hear from us within a couple of weeks (if not sooner). I'm sure that you will provide invaluable insights and feedback during the Beta period.
Good to know that you need remote assist to be 100% without the end-user involvement or it will be a deal-breaker for you. I'll pass on that feedback to the Product Manager. We will probably need a deeper conversation with you on that. In the meantime, please continue to send me your thoughts and comments on this subject should you have them. Thanks!
Remote assistance would be used for onboarding, troubleshooting pc issues. Currently "Zoom" is our remote assistance app, but we would like something with a bit more power. In a previous org I used Manageengine which worked out quite well.
For our team we would likely be using this tool daily, since we do not have a "good" remote access tool at the moment, we are really hoping the jumpcloud provided tool will be able to remedy this.
Manageengine had some neat things where I could remote in, or in cases where I may want to gather more information before speaking with the client, I could use their tool to look at installed apps, open a remote command prompt, view processes, restart services, and pull logs remotely. these made my life easier when I wanted to remote in.
One thing I will note, is gpu acceleration is very useful for remote access. as the remote access tool can become very unresponsive without this functionality.
Thank you for your feedback and comment @bwitzig_Zen! It's great to know that you will be using JumpCloud Remote Assist on a daily basis! Your feedback on the ManageEngine's capabilities is very valuable. Would love to hear more on their strengths and weaknesses even as we built a robust remote assist solution for customers like you. Once the Beta kicks in, I'll set up a call with the PM, you and myself if you open to continuing the dialogue. Thanks!
Usage fluctuates for us, but it averages out to remote assist being used at least weekly. I make a remote connection to every new/replacement computer I deploy as part of my pre-deployment test process to ensure everything is functioning correctly. It is also often used during the actual IT Onboarding meeting with all new employees so that I can help walk them through some of their initial setup, things like enrolling in MFA for various systems, etc.
Beyond that, I use it for training and troubleshooting any sort of system/software issue that may arise. While we have an office again, attendance is 100% optional, and with employees spread out across the country, I must have a solid remote platform to have some virtual "hands-on" capabilities in supporting our team.
We use Zoho Assist as our current remote assistance platform and leverage the unattended agent option on all our systems.
I need to be able to make a connection to any of our remote systems, as needed, without end-user interaction required to make that connection. As part of IT Onboarding, I discuss this capability with all new employees, so they are assured that remote connections are not made without valid reasons, as I understand that could be a cause of concern. Under normal circumstances, the employee is the one requesting assistance via an IT ticket or slack message, and then I offer to remote in, so they are aware of the connection attempt ahead of time.
However, there are very rare edge cases where we may have to remote into a system without the user requesting assistance or without the express consent of the specific end-user. There are also instances where the end-user may step away (often going to lunch) while I am remoted into their system working on something. If the connection gets dropped or terminated, I need to be able to reconnect without them physically needing to be there so that I can continue working. Not all of our employees have the best internet connections, so I occasionally need to disconnect/reconnect to get the remote session working again. If they are required to stay while I’m working, it’s potentially inconvenient for them, and if I need to wait for them to return before I can reestablish a connection, that’s inconvenient for me.
Other things that would also be necessary to have
- Seamlessly handling prompts for elevation
- Multi-monitor handling/switching
- Ability to reconnect session after a reboot
- Session Recording
- Ability to blank the remote screen(s)
- Shared Clipboard between systems
- Direct file transfer capabilities
- In-Session Chat/Voice capabilities
I alluded to this above but to be more direct and echoing Luke... If end-user intervention is required to make a connection, that is a dealbreaker for us as well. Our policy allows for unattended access. Please provide admin controls to enable that as an option within your remote support solution. If that's not there, we won't be using it.
To be clear, I never said that I have connected without someone's knowledge. I have never done that and have not been asked to do so. There would need to be some pretty extreme circumstances for me to take that step.
I have, however, had an instance where I needed to connect to an individual's system to remotely work through removing personal data, with that individual's verbal guidance, during a termination. I obviously cannot get into details, but they could not be trusted to have any direct access or unmonitored control of the system. That was an instance where I needed to control the whole process from unlocking access to the device, performing the data removal, and then locking it again to prevent them from accessing it. The session was also recorded for evidentiary purposes, just in case. And if I would have needed to allow them access to that system in order to approve a remote session request, that would have potentially given them the opportunity to A) be slow to approve the request while they performed who knows what actions or B) outright refused the request and then had unmonitored access to the system until I realized the problem and locked it again. We couldn't risk that, so it was crucial that I could remotely connect as soon as the system was online and control the whole login process.
As I said, that is a rare edge case... But when you need those capabilities in a situation like that, they are absolutely 100% necessary.
Thank you for your feedback and comments @NVergin! Those are great use cases that you have mentioned! Love that you are already putting in those requests on what you like for our remote assist solution. The list will come in very handy with us. I'll make a note to the Product Manager about the deal-breaker on end-user intervention. One quick question that comes to my mind to @lmcfadden and you, what about a 1-time set up for end-users and then they don't have to be involved again? Like having to give initial permission, etc. Would that be something do-able or still a deal-breaker?
Looking to more feedback from you during the Beta! Hope you won't mind us reaching out again if we have questions or need more clarification. Thanks!
I've not yet seen any remote solution that requires user interaction at the enterprise level? Teamviewer and the like do offer "code" based approvals with passcodes, but those are just options, rather than the primary mechanism. That just falls apart miserably at scale for more mature IT Departments. I greatly appreciate the idea from a privacy / security perspective, but for us, if it has JumpCloud on the device, then it's a managed device and the user is made aware of our remote monitoring and management procedures.
We are internal IT, but I'd think even most multi-tenant MSP's would have that language in the MSA / agreements.
I'm definitely in favor of alerting users when their device is being accessed. We do that in VSA with pop-ups, and via JumpDesktop buy a changed / focused system tray icon.
I could see the potential need for that in a BYOD environment, but I wouldn't personally allow any remote access to a device that I own.
As a related note, *please* build in some sort of notation for remote sessions that is auditable. We require this with VSA. Hopefully remote access is rolled into directory insights or some other logging option.
Thanks again @lmcfadden for letting me pick your brain! It's always a balancing act when it comes to security and usability. Good to know that for you as long as it's a JumpCloud managed device, it covers the privacy/security aspect. And I will make a note to my PM on the auditable feature/capability. Cheers!
No, even a one-time setup is still a deal-breaker. If it's our company policy to allow unattended access or connections without explicit end-user approval and using our company-owned equipment, I do not want to have to jump through hoops or require end-users to essentially "opt in" to our own IT policy (that they have all already agreed to upon employment) via an arbitrary step imposed by JumpCloud... even if that is only a one-time thing. All that does is add complexity to the implementation by then requiring me to guide end-users during the rollout to "just click approve" or whatever... which is the last thing any admin needs to be made to do. Especially when it's not really accomplishing anything productive or serving a meaningful purpose.
I can appreciate the approach of wanting to protect end-user privacy and for some organizations requiring explicit approval or an opt-in is probably fine. But you should not require that or should at least give admins/organizations the capability to skip or pre-authorize that centrally during the implementation/rollout. Ideally, I don't want to even have to install another piece of software to implement this, so I'm hoping these capabilities are baked right into the existing JumpCloud agent in a future update. I want both the rollout and use of this to be silent and seamless for our end-users.
Another reason to allow that would be for accessing remote servers/headless systems or for after-hours support and maintenance. I'm lucky enough not to have physical servers that I need to deal with, but many organizations still do and may need remote access to them. There may literally be nobody there in person who CAN approve a remote connection to those types of systems and IT needs the ability to initiate those whenever needed and unimpeded.
I also agree with @lmcfadden that there should be a visual indicator displayed for the end-user when there is a remote connection active. Zoho Assist does this by popping up a small window pinned to the right edge of the screen. Even if it is "minimized" to the screen edge, there is always some visual element there that cannot be hidden entirely so it is clear there is a remote connection active. This window also provides information about who is connected to the system, facilitates a remote chat session between the agent/end-user, etc.
I'm definitely happy to help test this out before it is widely released, and please feel free to reach out directly to discuss further or set up a call with product/engineering!
Thanks @BScott for the heads up! Here are my answers:
When we use remote access: I use it all the time. We do new client onboarding, new hire onboarding, troubleshooting, walking through something new with a user, and more I'm sure I'm forgetting. Currently we use TeamViewer when it's up to us (some users are more comfortable with Zoom/Huddle/etc). One thing I do like about TeamViewer is the unattended access option, which requires a bit of prep work on our end to set up, but can come in very handy in places where we need it (headless or unattended machines, primarily).
As for how often, I currently use remote access daily and I do not anticipate that changing any time soon.
If I asked the rest of my company, I'm pretty sure we'd come up with the same feature set @NVergin gave, aside from unattended access, since I think that would be a hassle for us, but not necessarily a dealbreaker.
Thank you for your feedback and comments @kelly! Good to know that you use remote access all the time! I hope you will continue to leverage JumpCloud daily in the same way when our Remote Assist solution is available:) Appreciate the insight on why you like TeamViewer; helps us strive to do better in our own product everyday!
And yes, do let us know if you have other feature requests (besides what @NVergin has already shared) any time. It's actually also good for us to note that some or many of you have similar requests. Thanks!
Thank you for your response @Fulgubbe!
Would love to have you at the Beta! However, there's a process involved. Please see below.
To gain access to the betas you will need to send an email to firstname.lastname@example.org
In that email, please include the following:
This will be reviewed and product will update account flags in one batch instead of multiple submissions.
Understand, that by volunteering, you are stating you are willing to participate. There are limited seats for each beta. And not every account will be able to use every beta. For instance, if you don't have device management, you can't use Remote Assist.
The Product Manager will reach out to you to gather more information as betas become available. You may be asked to fill out more information at that time!
Other thoughts: As others have pointed out, we must have the ability to remote connect to any system at any time, with or without user approval. Without this ability we would not even consider a remote management tool as this would severely hinder our abilities to properly remotely assist our user base. We are currently at 500+ remote users and growing rapidly.
Thank you for sharing your responses and feedback @archery1998! You have a pretty good use case there. Like you, we are also looking forward to rolling out our remote assist solution. Great to see your anticipation though! And yes, please consolidate and just use JumpCloud for all your IT needs! 🙂
Also made a note on the ability to remote connect with or without user approval. Thanks!
Some background info: We are a company of approximately 100 employees, with a few locations and a fair amount of remote employees. We do not have a remote assist solution today, however it is something that we miss from time to time. It is doable with screen sharing, but not ideal.
>When would/do you use remote assist?
I use it for installing software, configuring new systems, and of course; user support.
>How often would/do you use remote assist?
In some form, I use it almost daily. At least a few times per week, at the lowest.
Since we use mostly Macs here, with a few Windows machines/servers, and a few Linux servers; I end up using a variety of remote access tools, and often. Be it RDP to the servers, or Apple Remote Desktop to the Macs. Finding a nice, consistent, multiplatform system has been.... difficult. One key feature that needs to be supported is not just for remote assistance, but remote access as well. That way IT admins can access a computer system directly, without the user being there to approve. It can put up a notification, but should have time out, much like RDP does for the console user if they are AFK. That would be a major value add.
Now, allowing a user to remote into their machine from the JC user console, would be cool; but probably out of scope for this. But talk about my dream.
Thank you for your responses and feedback @rlyons! Your challenge in finding a multi-platform system for a remote assist solution is very real and can be so frustrating. And that's something we are working to solve at JumpCloud (as you know, we support Windows, macOS, and Linux in our device management solution). I'm looking forward to your feedback during the Beta process. Will also make a note about remote into end-user machines from the JC user console to the PM. Thanks!
My use case for Remote Desktop support mirrors pretty much everyone's responses. I agree that whenever this is rolling out, making it a seamless, silent install would be ideal. Meaning if we could push it out from the admin console (via a policy or software deployment or whatever) while it continues to be it's own app (and not part of the existing agent) would be perfect.
We currently use GoToAssist that has been in a long transition period where there are two different versions of the agent. The newer console can read new and old agents which is nice. However the newer version is browser based which has it's own pros & cons. The older legacy app didn't work well with Macs so those are restricted to the newer browser based solution. Even with the Macs, they don't always show up in my admin console so I need to send them a link anyway instead of being able to initiate the connection on my end, which is an extra step.
So anyway.... looking forward to JC's solution!
We're utilizing remote access multiple times a day to do most everything. Everything from troubleshooting issues to training users.
General workflow is a user requests assistance via chat/text/call and we remote in and provide assistance, BUT multiple times a week we have situations where end user interaction is not possible. I've listed some of these below. We have to have unattended access capabilities.
Other features we use all the time
Other features we have and do use, but aren't strictly required. (several products do have this).
To add to the multi-monitor support, a lot of the remoting software that I've used has really finicky controls and support for multiple monitors. All of our users have 2-3 monitors and it's not uncommon for vertical monitors to cause really bad issues with remoting software. It's also not uncommon to deal with issues with resolution, orientation, or location changes to monitors that are already to connected "breaking" a remote session. Any kind of dynamic change to monitor layout tends to cause issues.
On the note of mobile devices, this would be exceedingly helpful when a user has a phone but doesn't have a lot of technical proficiency. Working over the phone to get something to happen can be a nightmare.
For chat and voice, we have other mediums to do this with.
Reconnect after reboot while nice isn't something we would need need. Though the amount of time it takes for our remote software to detect a workstation as online after a reboot can be really frustrating as well as the amount of time it takes from clicking the remote to machine button to the displaying and allowing controls.
Shared clipboard can be finicky at times on different remoting software I've used but rarely always works perfectly.
We also have run into the docking issue before but some remoting software allows connecting to device and allowing access when displays are off. To this note as well, there are sometimes workstations that have issues with remoting while doing graphics cards swaps or driver updates on graphics cards. There has been a case where we've had to drive out due to a graphics driver update having issues.
We don't tend to have issues with file sharing due to domain based connections, but some users are not connected to the domain when they are in the sales side of things which can make it difficult to get a file over to them.