When doing a remote support session I am not able to click, scroll or execute some, not all files on the remote computer and I have to ask my client to do it.
I have a Windows 10 computer with 24 GBRAM.
Thank you for your feedback.
It is by design if your rescue applet was not running in Windows System Service mode and the currently logged in user was not admin on their PC, than you cannot click or execute on programs remotely that is needed to run as an administrator.
You can restart the Rescue applet in Windows System Service mode if it is not disabled in the Admin Center and you or the customer know the actual admin credentials to solve this issue.
We have run into this twice now. There is an option to restart the applet as a system service. That typically works fine, but we get this pop up message with two of our customers.
We know that users need to have administrative rights. Why does this pop-up appear? This user does have administrave rights on their Windows 10 system. Is there something else that it could be?
I'm a bit confused, so I have to ask some further details about the issue.
Did you take that second screenshot from the end user's side or the technician side?
The fact that a technician is logged in as an administrator to their computer is irrelevant to the applet (end user) side.
If the logged in end user is not an admin, than the technician may restart the applet in a Windows Service mode. To be able to do that the technician has to enter an admin credentials that is valid on the end user's computer. If that credential is not a valid admin user in the end user's computer, than a warning window will be popped up (screenshot 1).
This is for the end user. End user is logged in as administrator.
We understand how to restart the applet in a windows service mode. That is what we typically do. This is a rare situation
Thank you for the clarification. I assume that those rare situations only occurs on Win10?
Could you try our Beta applet on those end users? When you create a new private session you should change the URL from https://secure.logmeinrescue.com/R?i=2&Code=123456 to https://beta.logmeinrescue.com/R?i=2&Code=123456 before sending it to the client.
As far as I remember we have fixed a similar issue in the Beta applet.