Under review

"Screen Connect is randomly not allowing agents in support to "see" the Clients

Keith Davenport 1 month ago updated by Duc 4 days ago 11 1 duplicate

"Screen Connect is randomly not allowing agents in support to "see" the Clients screen after the client consents control to them it is remaining grey
Support Staff  Currently "

"Please wait while I access your informationJake Tomecek 11:19 AMHello Keith, how can I hel you today?Jake Tomecek 11:20 AMlooks like some of our support people are seeing some issues with remote connectionsKeith Davenport 11:21 AMSent"Screen Connect is randomly not allowing agents in support to "see" the Clients screen after the client consents control to them it is remaining grey
 Currently "Keith Davenport 11:21 AMSentI haven seen the issue but I dont use the support Guest section much.. all my people have clients. so this seems to be on the guest connect par tKeith Davenport 11:22 AMSentOkay so I see that you are on 21.4, this is currently a known issue with this version"  Ticket: 14519425
Queue: Support

ConnectWise Control Version:
Other (please specify)
Server Affected:
Host Client Affected:
Guest Client Affected:

Duplicates 1

Facing a similar issue:

We typically require consent when connecting to a client. For a few days, every time we try to connect a second time, consent is automatically refused until the client's computer is restarted.

So the first connection after a reboot is fine, the client can consent. A second attempt is automatically refused.

We found a workaround to be to try and connect to a backstage session and then switching back to the user session.

I had to temporarily disable consent as we are running 21.4 and have the same issue.  Please fix and post an update .

I am having this issue as well. The only way to work around it right now is running a command line restart, or remote desktop to the computer denying consent and restarting the ScreenConnect service. Not very fun when you have things open on the computer you need to connect to. I've tried making a command to just restart the ScreenConnect service, but it will only stop the service and doesn't restart it.

Yeah, that's because stopping the service kills the connection before the second command can be issued. See my note in this thread about how to do this with an on-demand "scheduled" task.


Same here, when a remote session is already established and then run tsdisco or switch user, the remote session is lost. It will prompt for another consent...CW please do make this priority as a lot of your customers are affected.

Not fixed as far as I can see in version 21.4.2767. It is very important for us that this is fixed.

Using Access to access certain machines with no user logged on, we are often immediately getting "Consent Refused" message. Only solution is to restart service, which can be done by running Reinstall from host, at least on the 60% of systems where Reinstall doesn't simply cause msiexec process to hang on guest (speaking of continuing problems that will never get fixed). Otherwise, we have to log onto another system on the same site to restart the service on the troublesome guest. Haven't yet had this happen on sites with only one machine, or had this happen to all machines on a site at once. Don't know what we'll do if that happens.

Once service is restarted, it seems to stay fixed for awhile (at least an hour, less than, say, four) allowing repeated connections with no problem.

This started in 21.3, when we also occasionally noticed a consent window flashing briefly on the host when we used Access to attach to an unlogged-in guest. It has gotten much worse in 21.4. We've also only noticed it on Windows 10 or equivalent server guests, although this may simply be due to the scarcity of Windows 7 guests.

OK, had this happen on a Windows 7 machine today. . .


Finally had this happen on a guest machine with client logged in and Reinstall failed. Took over ten minutes to get client connected through Support, even using phonetic alphabet from togglecase.com ("Screamcorrect?" "Which link in the list [of Google results] do I click on?"). Took less than two minutes to solve the problem once I got connected.

To avoid pissing off yet another paying client, I spent a little time cobbling together the following to restart the service. No guarantees, your mileage may vary, etc.

Enter the following three lines in the Access Command window, replacing the x's with unique ID:

IF NOT EXIST C:\Windows\batch MKDIR C:\Windows\batch
ECHO NET STOP "ScreenConnect Client (xxxxxxxxxxxxxxxx)" ^&^& NET START "ScreenConnect Client (xxxxxxxxxxxxxxxx)" > C:\Windows\batch\Restart_ScreenConnect.bat
SCHTASKS /CREATE /RU SYSTEM /SC ONCE /SD 03/25/2021 /ST 12:00 /TR "C:\Windows\batch\Restart_ScreenConnect.bat" /TN "Restart ScreenConnect"

Don't worry about the "/ST is earlier than current time" error.

After you've done that once, anytime you need to restart Screenconnect on that guest, issue the following command:

SCHTASKS /Run /TN "Restart ScreenConnect"

Now if we could just get Reinstall to work on the [increasing number of] guests where it fails. . .


Updated to 21.4 two days ago and found that bug just the next day.

As for now, we haven't noticed any issues with Access sessions. It also seems to be working fine with Support sessions when guest has admin privileges on his workstation. However, if he hasn't (like most of our users) neither manual nor auto consent works.

As a workaround I had to give our Technicians privilege to HostSessionWithoutConsent which is far from ideal.