logo

The ConnectWise Control forum has moved to ConnectWise University! This forum has been locked and is in read-only mode. Click here for instructions on how to access the new forum.

Welcome Guest! You can not login or register.

Notification

Icon
Error

Options
Go to last post Go to first unread
martinzenith  
#1 Posted : Tuesday, April 14, 2015 7:10:40 PM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

When we reboot our screenconnect server (Windows version 5.2.874) the unattended clients/access sessions do not automatically reconnect until somebody accesses the computer itself.

This is obviously a big problem for us as the vast majority of the unattended connections are servers.

Are we doing something wrong here?

Thanks.

Martin.

martinzenith  
#2 Posted : Tuesday, April 14, 2015 7:22:02 PM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

Actually just an update - they just appeared there, approximately 30 minutes after the server reboot - is this delay normal expected behaviour?

Thanks.

Martin.
powellap  
#3 Posted : Tuesday, April 14, 2015 9:05:50 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 99
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
I went through support with this issue too. Its expected behavior. As time passes while your server is off, the remote sessions slowly increase the amount of time between checking back in with the server. I have seen it take up to 40 minutes for all my sessions to reconnect. (and as little as 1 minute)

When I spoke with support we discussed adding a maximum checkin time, but as far as I know, this has not been added.

Edited by user Tuesday, April 14, 2015 9:07:11 PM(UTC)  | Reason: Not specified

martinzenith  
#4 Posted : Wednesday, April 15, 2015 12:56:04 PM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

Well it doesn't make sense that a simple server reboot puts a twenty to thirty minute lag on an unattended/access client reconnection. At the very least this should be configurable.

If anybody from SC is reading this, lets please have a more agile reconnect policy please!

Thanks.

Martin.
Scott  
#5 Posted : Wednesday, April 15, 2015 12:58:27 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,862
United States

Thanks: 3 times
Was thanked: 351 time(s) in 303 post(s)
Everytime a client calls back to the server and doesn't reach it, the interval between the next callback attempt increases. It does cap out at around 30 minutes I believe, but it's not necessarily out of the ordinary to take a little longer.

Without knowing what was happening on one of the client machines it's hard to speculate what the issue was. If this happens again, double-click on the ScreenConnect icon in the system tray and take a look at the Last Error Message field, that will give us more information about what's going on.
ScreenConnect Team
martinzenith  
#6 Posted : Wednesday, April 15, 2015 1:06:31 PM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

We've about thirty clients currently and I can see that since the last reboot its been 41 minutes - the only two that have reconnected are my own laptop which I am currently using and the actual server that SC is running on.

I will look at the clients and see if there are any error messages.

Thanks.

Martin.
relentless  
#7 Posted : Wednesday, April 15, 2015 5:17:37 PM(UTC)
relentless


Rank: Newbie

Joined: 2/8/2014(UTC)
Posts: 6
United States
Location: North Miami

Since upgrading to 5.2.8694.5556, I too have noticed this problem. It took well over 1 hour after our last reboot for the majority of the clients to check-in.

We've also had two incidents where SC just crashed - and crashed so hard that the entire VM was inaccessible, and this ultimately led to crashing Hyper-V management service, which then had the domino effect of making me shut down the other 5 VM's and force restarting the host. Prior to 5.2 I was on 4.3 or 4.4 versions for a long time and had never experienced either issue. Reboots saw agents check-in within minutes, and not even a single reboot on the SC server for months at a time.
martinzenith  
#8 Posted : Wednesday, April 15, 2015 8:51:32 PM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

This is definitely a bug - just tried again earlier and the reconnect time was on average 2 hours :-(

For unattended/access sessions this is simply unacceptable.

Can we ask SC that this is looked at?

Thanks.

Martin.

p.s. Scott, there were no errors in the last error portion of the client, just that the status was "waiting for host....."

Edited by user Thursday, April 16, 2015 7:28:46 AM(UTC)  | Reason: Not specified

MannyTC  
#9 Posted : Thursday, April 16, 2015 9:14:02 PM(UTC)
MannyTC


Rank: Advanced Member

Medals: Bug Buster Level One: Spoon!Level 3: Shirt off your back! Received 25 Thanks!

Joined: 2/19/2015(UTC)
Posts: 262
United States
Location: AZ

Thanks: 6 times
Was thanked: 52 time(s) in 45 post(s)
I just had a need to reboot the server where we have ScreenConnect installed. After seeing this post I thought I would watch closely to see what happens and how long things take. I was able to fully access the ScreenConnect Host page about 5 minutes after the reboot. After that I was able to watch all of our roughly 250 access unattended clients connect up within about 3 minutes.

ScreenConnect server is running version 5.2.8694.5556 on a Windows 2008R2 VPS
martinzenith  
#10 Posted : Friday, April 17, 2015 8:22:16 AM(UTC)
martinzenith


Rank: Newbie

Joined: 4/14/2015(UTC)
Posts: 6
Location: UK

Over the weekend we will run a few more tests and report back to this thread. We're at fifty now and this is something I'd like resolved before we hit our target of approx 750.

Thanks for the replies everybody.

M.
shawnkhall  
#11 Posted : Sunday, April 19, 2015 8:50:01 PM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
Have you tried setting the service recovery options to restart on failure?
sc restart on failure
shawnkhall  
#12 Posted : Monday, April 20, 2015 8:16:01 AM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
So is it that you haven't tried it, then, or that you're not interested in trying to see if it fixes the problem?

There are several other threads about connectivity issues causing the SC client to fail to reconnect or to die. In my experience this setting change has resulted in my clients staying connected more reliably, especially after a server reboot or SC server update.
WJTech  
#13 Posted : Monday, April 20, 2015 2:11:30 PM(UTC)
WJTech


Rank: Member

Medals: ScreenConnect Advisor: Focus Group MemberLevel 1: Random Act of Kindness! Received One Thanks!

Joined: 1/27/2015(UTC)
Posts: 30
Man
United States
Location: Birmingham, AL

Thanks: 4 times
Was thanked: 3 time(s) in 3 post(s)
Originally Posted by: shawnkhall Go to Quoted Post
In my experience this setting change has resulted in my clients staying connected more reliably, especially after a server reboot or SC server update.


Is there an easy way to do this at the domain level or some other bulk fashion?
shawnkhall  
#14 Posted : Monday, April 20, 2015 4:40:28 PM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
You can run the following service changes via the service control app:
Code:

sc config "ScreenConnect Client (!scapp!)"  start= delayed-auto 
sc failure "ScreenConnect Client (!scapp!)"  actions= restart/60000/restart/60000/restart/60000 reset= 86400


Replace "!scapp!" with the ScreenConnect client installation ID, which you can get from the path of your installs. If you've used a consistent user account for building ALL of your installers, then you can simply replace it with that. Otherwise you may need to parse it at runtime, which you can automate with something like this (depends on GREP and maybe on English language OS):

Code:

sc queryex type= service state= all | grep SERVICE_NAME: | grep ScreenConnect >"sctmp"
FOR /f "tokens=1,2,3,4* delims==() " %%a IN ('type "sctmp"') do (
	IF "%%b"=="ScreenConnect" (
		SET scapp=%%d
		ECHO SCApp: !scapp!
	)
)
del /q "sctmp"

shawnkhall  
#15 Posted : Monday, April 20, 2015 4:56:11 PM(UTC)
shawnkhall


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/6/2014(UTC)
Posts: 316
Man
United States

Thanks: 6 times
Was thanked: 33 time(s) in 29 post(s)
Also be aware that the service recovery options will need to be re-assigned after every client update. The recovery options are not preserved during an upgrade.
Scott  
#16 Posted : Thursday, May 14, 2015 2:50:03 PM(UTC)
Scott


Rank: Administration

Medals: Level 4: Wise Old Owl! Received 100 Thanks!

Joined: 3/28/2014(UTC)
Posts: 2,862
United States

Thanks: 3 times
Was thanked: 351 time(s) in 303 post(s)
Sorry to leave this thread hanging for so long, but I have noticed some similar behavior with some internal sandboxes we have and we are investigating. Unfortunately it seems to be sporadic in occurring, so if anyone knows of a way to make it happen each time, please let me know.
ScreenConnect Team
powellap  
#17 Posted : Saturday, June 6, 2015 6:14:59 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 99
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
Is there any new news on this? Most times when the server is restarted, waiting 30 minutes or more is not that big of a deal in my environment. However, on a few occasions in the past and then today, it was driving me nuts waiting for all the clients to come back online.

Could you guys please consider adding a MaxCallBackTime value?
powellap  
#18 Posted : Tuesday, June 27, 2017 10:06:32 AM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 99
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
As a follow up to this thread. In the 6.1 Release Notes, there is this...

Quote:
Made polling interval configurable in the app.config (MaxRetrySleepMilliseconds)


Is MaxRetrySleepMilliseconds the value that would limit how long the client waits before trying to reconnect?
Is this how it should look in the app.config for a max of 10 mintutes? Specifically is it a sting value or something else?

<setting name="MaxRetrySleepMilliseconds" serializeAs="String">
<value>600000</value>
</setting>

Thanks

Edited by user Tuesday, June 27, 2017 10:12:12 AM(UTC)  | Reason: Not specified

powellap  
#19 Posted : Tuesday, June 27, 2017 3:14:13 PM(UTC)
powellap


Rank: Advanced Member

Medals: Level 1: Random Act of Kindness! Received One Thanks!

Joined: 2/16/2014(UTC)
Posts: 99
United States

Thanks: 3 times
Was thanked: 8 time(s) in 7 post(s)
Here is the settings for app.config



<configuration>
<configSections>
<section name="ScreenConnect.SystemSettings" type="System.Configuration.ClientSettingsSection" />
<section name="ScreenConnect.UserInterfaceSettings" type="System.Configuration.ClientSettingsSection" />
</configSections>



<ScreenConnect.SystemSettings>
<setting name="MaxRetrySleepMilliseconds" serializeAs="String">
<value>1800000</value>
</setting>
</ScreenConnect.SystemSettings>
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.