Expose option to revert Consent to previous where you could reboot or use the Windows "Switch User" without re-prompting
Previously once you received consent from a User you where able to use the Windows "Switch User" feature or reboot their machine and when it reconnected you would still have consent.
Since upgrading to the latest ScreenConnect and LabTech as soon as you select "Switch User" it kicks you out advising the user need to Consent again, this also happens when rebooting a users machine.
This is step BACKWARDS for support because alot of the time you are working on a users machine at a time that's convenient to them which means they are away from the machine and if you have to switch to your Administrator account or reboot to apply a change you cannot continue to work on the device but have to wait till they return to re-consent ... which leads you wasting more of the customers time when you could have already had it fixed / tested your fix.
Customer support service by UserEcho
We're sorry to hear about the issues you are experiencing. Please reach out to our Support team for further investigation.
I did to confirm if this was new / expected behaviour now and was basically told it must be and if I wanted an option to revert it I would need to raise a enhancement here.
I completely agree and given this a thumbs up.
We used the Windows "switch user" feature to be able to regain access to workstations or servers without the need for a user to consent us on.
This was incredibly useful for us when running scripts out of hours. We could start the script running and then switch user to be able to regain access to the server and the already open user session to gather the results of the script without needing to go through consent again.
We now need to pay a line manager to work out of hours alongside another engineer so they can override consent for the engineer or re-write the script so it can run without having to log in.
Right now we are able to access our workstations and servers, we can enter the user's credentials but then we get disconnected - waiting for the user to approve consent.
We cannot use the auto timeout feature for consent because that would breach the cybersecurity policies we have set up internally to protect us and our clients.
Thankfully we also use Datto RMM and can use this to bypass consent otherwise I would have to roll back Connectwise Control to 21.3.
Please give this some urgent attention
This was the most useful 'bug' I have ever had :(
This functionality definitely needs to be reversed, the way it is at the moment makes no sense!
Please can this be looked at ASAP and the functionality restored or extra options added to the settings for users to fine tune the consent system how they prefer it
So who thought this was a good idea? this definitely needs to be reversed or this product diminishes in functionality immensely.
Yes can this be looked at asap please, it is now a major issue for us ..
As it stands we will need to look at an alternative solution for our technicians to complete remote out of hours work where the customer is not onsite to continuously provide consent.
If someone is onsite and gives consent, a reboot shouldn't cancel that consent. Often rebooting is needed to fix problems and clients cannot continually consent each time a machine is rebooted or network change is made. They especially can't do this if they are not there and give consent after hours!
Another alternative is when they click consent, have it default to 24 hours or something, with the option for the consenting user to change it to a different time limit if they prefer via a drop down box on the consent window. That way would work for everyone and still provide security in the instance a session was left open indefinitely.
This has become quite frustrating for many of my customer's that I am having to continually call back to gain 'consent' again.
I also do a lot of maintenance work after hours which the customer does not stay back for and thus not available to click consent after rebooting. Unfortunately the tool is no longer fit for purpose if there is no work around or solution to this.
I have the same issue after migrating from linux to a windows server. I have contacted support and this is what they said:
"The behavior where consent prompts on every user switch is the intended/expected behavior, it will not be changing; if it was working like that when you were running the system on Linux, then that sounds like it is a bug and not intended, I'm sorry! That is something that I'll need to report up to development, as I could not find a registered bug report for the behavior in our system."
If you remember you can just "lock" the computer and login as the other user instead of "switch user" to get around that use case.
Hi Shannen. I just followed your instruction. I can login as another user but the end user still needs to press on consent. Thanks for the tip.