+29
Started

6.9.20755.6879 - Guests Disappear until restarting services

ben 5 months ago • updated by William Chilcote 3 weeks ago 63 2 duplicates

Since updating to 6.9.20755.6879, we noticed that some guests disappear until restarting the ScreenConnect Web Server and ScreenConnect Relay services.

ConnectWise Control Version:
6.9
Server Affected:
Host Client Affected:
Guest Client Affected:

Answer

PINNED

(Edit) Mar 19: Fix in the 19.0 pre-release.

In the meantime, a workaround for this issue is to either 1) restart the services when the issue appears, or 2) simply disable the session expiration feature entirely.

For option 2, ensure that the three *SessionExpireSeconds settings in your web.config file (found at the root of your ScreenConnect folder) are set to 0. This will prevent sessions from disappearing from the list due to an incorrect connection status.

(The easiest way to make these changes is to use an extension like Edit Web.Config AppSettings or Advanced Configuration Editor.)

Duplicates 2

Waiting for information

Do these specific Guest machines have anything in common?  Are they all offline often?

Also, within the web.config on the ConnectWise Control server, to what value is the setting "AccessSessionExpireSeconds" set?

Hi Scott,

They don't appear to have anything in common. All different sites/machines. Even some in our own office.

The value for "AccessSessionExpireSeconds"  is set to 86400.

Sorry for sending this twice. Trying to find out why it still says "waiting for information" when it's been 5 days.

Hi Scott,

They don't appear to have anything in common. All different sites/machines. Even some in our own office.


The value for "AccessSessionExpireSeconds"  is set to 86400.

Hi, 

This is continuing with version 6.9.20991.6893

+1

We are seeing the same behaviour on 6.9.21027.6898.

Restart ScreenConnect services on our on-prem server they all come back and then disappear approx 24 hours later.

I just posted a new BR on this exact issue as well. I have ~75 hosts that disappear until I restart the ScreenConnect server. This did not happen in 6.7 ... only happened immediately after upgrading to 6.9

Same here, I've had to schedule periodic service restarts to keep Control working...

@scott - what information do you still need?

Waiting for information

Do all your sessions disappear, or just some of them? Is there anything in common among the disappearing clients that might be interfering with connections? (Antivirus software, for example.) Also, do the disconnected clients report any error messages?

Please contact support if you need interactive assistance.

Here's what I see.


  1. After rebooting the Screenconnect Server, everything will work fine for approximately 24 hours.
  2. After 24 hours, many of the remote sessions will 'disappear'.
  3. Some sessions will reappear in the access list but will appear 'grey' on the remote side
  4. When the server is rebooted, all will appear well again.

I have more than 60 such sessions spread across PC (Servers and Desktops) and Mac. There is nothing in common except your software. This did not happen in 6.7 at all. The only thing that changed was upgrading to 6.9.


I replied to your other post, but again, please contact support so a tech can examine this issue. (I have not seen it on any of our development installations.)

+1

@scott - I'm about to start reposting this until someone there changes the status of this to something other than "WAITING FOR INFORMATION". This is a major issue as I shouldn't have to restart the server every day so that I can work!

We are still waiting for information that will enable us to replicate this issue. If you haven't already, please contact support for interactive assistance. This forum is mainly for prioritization and gathering information about possible issues.

Thanks for reaching out to Control Support. This issue has been reported and currently being investigated by our development.

SCP-33461

Hosts can connect to Guests that appear offline on host page

This issue is made worse with a setting called AccessSessionExpireSeconds. Determines the number of seconds before which a disconnected Access session expires from the list So with the above bug, sessions appear offline and then with this setting, they are hidden.

Development is still working on a resolution however, if you download Advanced Configuration Editor extension. You can update the

Session Expire Seconds setting so sessions are not hidden.

1. Install and open the Advanced Configuration Editor extension

For more information, see our page on the Advanced Configuration Editor. Open the Administration page, then click the Configuration tab.

2. Select Web Configuration > Session Settings

3. Session Expire Seconds, set to 0

You will then be able to connect to the sessions that show as disconnected. We hope to have this bug resolved asap.

+2

Thanks for reaching out to Control Support. This issue has been reported and currently being investigated by our development.

SCP-33461

Hosts can connect to Guests that appear offline on host page

This issue is made worse with a setting called AccessSessionExpireSeconds. Determines the number of seconds before which a disconnected Access session expires from the list So with the above bug, sessions appear offline and then with this setting, they are hidden.

Development is still working on a resolution however, if you download Advanced Configuration Editor extension. You can update the

Session Expire Seconds setting so sessions are not hidden.

1. Install and open the Advanced Configuration Editor extension

For more information, see our page on the Advanced Configuration Editor. Open the Administration page, then click the Configuration tab.

2. Select Web Configuration > Session Settings

3. Session Expire Seconds, set to 0

You will then be able to connect to the sessions that show as disconnected. We hope to have this bug resolved asap.

We are on 6.9.21027.6898 and this has been happening for a couple weeks. What information does ConnectWise need to turn this away from "Waiting for Information"? We are having to globally restart ScreenConnect services to get our sessions back. @Jefferson thanks we'll look in to that fix.

+1

My guess is many of the devs are sidelined by the holidays. According to the ticket that I filed with support, they are aware of the bug and are in progress to fix it in a forthcoming release.

Makes sense, thanks again @Jefferson!

Any update on this? Can someone change this edition from Stable to NOT. I always wait for a stable release but this is clearly not one of them.

Apologies for the trouble, but we're still working out the cause of this issue. Have you set the AccessSessionExpireSeconds to zero? This should restore the incorrectly-removed sessions to the list, although they may still appear as offline.

Thank you Eric for starting work on this.

My ticket #11392191 has been great craic. First person I spoke to had no idea and just got me to restart the services even though they knew it was going to take 12hrs+ for the clients to disappear - 7AM UTC must have no actual ScreenConnect support available. I was then told the fix was going through the latest round of QA and should be pushed out shortly. The latest update is "It is under investigation as a high priority issue, but we do not have an ETA for a fix/release date.".

Further more when I pushed to see if this release would be taken off the website as a stable build I was told "I apologize on the delay. I was able to discuss with my Team Lead on this. While we understand your frustration; this bug is not something that's happening to all or even most of our partners." so I guess thats a no.

500 access sessions, 50 concurrent support sessions - Now I have to explain to 300 support staff that even if the machines are showing disconnected to just go ahead and try and connect anyway. Currently I am restarting the services every 12 hours in quiet times, when I can ensure there are no sessions - which in it self means ensuring that support services to customers stop for the duration.

I have changed the AccessSessionExpireSeconds to 0 as per this thread. Also just to add I have recreated the session db which made no difference.

Real stable release guys. My number is on the ticket if anyone wants to call me.

@Adam Browne - big respect for trying to work through their process. I can't see how they can say that it's not happening to everyone. It happens to anyone that has access sessions.

To be completely transparent on this - I've had a developer contact me and I'm providing access as soon as they would like. Hopefully this helps create a resolution to the bug.

PINNED

(Edit) Mar 19: Fix in the 19.0 pre-release.

In the meantime, a workaround for this issue is to either 1) restart the services when the issue appears, or 2) simply disable the session expiration feature entirely.

For option 2, ensure that the three *SessionExpireSeconds settings in your web.config file (found at the root of your ScreenConnect folder) are set to 0. This will prevent sessions from disappearing from the list due to an incorrect connection status.

(The easiest way to make these changes is to use an extension like Edit Web.Config AppSettings or Advanced Configuration Editor.)

Are you looking for an instance where disruption has already occurred or will occur? I can consistently reproduce it at about 30 hours after a reboot. I just rebooted this morning, so next disruption will likely be sometime after tomorrow night midnight.

I'm looking for a case where the disruption that would be caused by debugging is something that the partner can tolerate.

Can you confirm that you haven't already set AccessSessionExpireSeconds to 0? (If so, this would be the first report I've had of the issue persisting after that change.)

I'm happy to. I expect to see several offline on Monday morning. Let me know how to reach you when it happens.

Eric,

We are on 6.9.21415.6941 and have our AccessSessionExpireSeconds set to the default of 86400. About 50% of the machines we have Connect Access sessions installed on are experiencing this problem. We would like this issue resolved so Eric if you want to jump on a remote session just let me know and we can set something up.  We can use the AccessSessionExpireSeconds set to 0 work around but this seems like an issue that needs to be caught live so that the development team can sqaush this bug.  

Eric, please PM me if you want to do a remote session for debugging.

I can confirm this exact same issue has been happening to us.  Setting AccessSessionExpireSeconds to 0 is a work around.  I just updated to the latest version (6.9.21415.6941) today and set the AccessSessionExpireSeconds back to 86400.  Will see if that works for us.

@Roddy
Does the new version (6.9.21415.6941) fix access session fluctuation issue?

It did not for us.  After 24 hours, we had the same issue everyone else is having.

Yup on the latest patch as well,encountered the same agent list fluctuation issue under CW Control Portal.

We are experiencing this issue as well and have been for about a month now. Have to restart all services to get it to show all sessions.

It happened again this morning. Im currently starting a support chat so you can run what ever diagnostic tools you need.

FYI. Eric ran diagnostics on our server. Just so everyone knows they are actively working on it.

Same here, i am on version 6.9.21027.6898 and since i upgraded from 6.1 to 6.9.21027.6898 i have had nothing but weird issues. Evey night after the database maintenance i would loose 400 some clients. The access sessions would decrease slowly and jump up (e.g 754 sessions count down to 700 then start quickly counting up to about 954 them immediately back to 754 and slowly down again). To repair, i would kill all network states to the On-Premise server and then all the clients will reconnect and we are back. I found that faster then stopping and starting the service. I really hope this issue is at the top priority. Everyday there seems to be a new

ditto, version 6.9.21027.6898

hope this gets fixed soon...

This is also happening to us. Currently on the latest stable release--been happening since we upgraded to 6.9.

Eric jumped in my system as soon as it started. He is grabbing data now.

Happening to us since last week 1/18 after updating to 6.9.21415.6941 to fix another issue I was having. Of course this is much worse as I have to watch the access tab like a hawk and restart services. We were on 6.8.20124.6845 prior and having weird resource issues and lag with connections starting. Upgrade to 6.9 fixed that but now we have the session disconnect issue.

why do you have to watch it like a hawk? Can't you just restart the service *when* you find that a session is missing?

They all start to disappear at the same time and I have to restart. I have a team of people who use this to access remote systems for support of our customers so when they drop, it causes a work stoppage. I suppose I could have just set the services to restart at 1AM every night, but if they don't start properly, I'm in it even deeper.

+1

That makes sense. We're all in close proximity. So when one disappears, someone just hollers "They're dropping like flies again!"... and I restart the services. :)

Yeah, if they were all at the same location and close to me it wouldn't be as big of a deal but our company president even uses it to access machines as he still has his hands in technical systems at times, mostly new customer acquisition.

Seeing this exact same issue since we upgraded from 6.8.20124.6845 to 6.9.21415.6941 a week ago. Hundreds of guests will suddenly begin to vanish in the morning hours. We use the on-prem Linux version of SC if that helps in hunting the root cause down. Also, we have our relay configured to port 443, and we have a separate node doing NGINX reverse proxy w/ SSL sitting in front of the SC node. Not sure if anyone else is doing anything similar and maybe some or all of these variables cause this issue to express itself.

We're running 6.9 latest stable on win2016 with same issues.  Having to restart server every day or so to resolve.

-3

Hi...Logged on to the server this morning, and it prompted to be rebooted to finish installing windows updates.  Rebooted the server, and one of the
RAIDs was degraded. Rebuilt the RAID, and the core services start up, but none of my devices are there.  Repositories are available on the local drives, but can't see them from within Appassure

Micheal helped me with settine the accesssessionexpireseconds to 0, which brought the list back along with a gazillion ancient accounts. Kudos to the workaround. Looking forward to the fix. 

This happend to me when using the setting of 0. How do I get rid of all those sessions that are several years old now?

+1

Scott,

You have to select the ones to nuke and then end them. I have been using "End Only" since the other two options try to uninstall.

+1

So the last update was a month ago. The fix was in QA so I expected it to be published and fixed. Not sure if this report will be updated but has the fix indeed been made and a new build posted? I don't see anything in the output stream post from 3 days ago.

+1

I should have put the date on there. It just went to QA today.

Eric, does the new release (2019.0) contain the fix that was sent to QA 1 month ago?

Yes, the fix is in yesterday's pre-release. I'll update the top post to reflect this.

New build rolled out...

Does anyone still have issue with access list for new version 6.9.21870.6964?

Yes, this has not been fixed in that build as it is from 1/25/2019. The fix is in QA as of 2/11/2019 but has not been released in a new build yet.

@Rylos - Thanks for the update here, that was helpful. So I'll wait for the new release

We are having the issue as well with 6.9.21870.6964.  Support said that it is fixed in the pre release as of 3/26/2019