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
samehuz  
#1 Posted : Thursday, February 4, 2016 5:46:00 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Hi,

Living through a week of joy due to unplanned server migration by ISP and, now that most other (DNS etc) issues seem to be resolved, I cannot get SC started.

According to the application event log:

[Relay] Failed to start service: System.InvalidOperationException: Unable to listen on end point: xxx.xxx.xxx.xxx:80 ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted

[ScreenConnect Web Server] Failed to start service: System.Net.HttpListenerException (0x80004005): Failed to listen on prefix 'http://xxx.xxx.xxx.xxx:80/' because it conflicts with an existing registration on the machine.

Nothing should have changed except ip addresses in the web.config which I have cross-checked 13 ways from Sunday. Also cleaned up whatever I could find with netsh but I don't know what else to check. There's zombie data somewhere but I can't find it.

[My SSL cert coincidentally expired yesterday but I can't imagine that would have any bearing, right?]

Can someone please help?

Thanks!

Scott  
#2 Posted : Thursday, February 4, 2016 6:17:40 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)
Do you have IIS installed on the server by chance? It looks like the services aren't able to bind to the ports.
ScreenConnect Team
samehuz  
#3 Posted : Thursday, February 4, 2016 6:35:55 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Yes I do but they happily co-existed on the previous incarnation of the vps and I rechecked all the bindings except those part of the ISP standard install. Can you suggest what I should be looking for?

Thanks for the quick reply, by the way.
jonmcknight  
#4 Posted : Thursday, February 4, 2016 8:18:06 PM(UTC)
jonmcknight


Rank: Advanced Member

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

Joined: 1/30/2015(UTC)
Posts: 47
United States

Was thanked: 7 time(s) in 5 post(s)
Last year I was having an issue where IIS was using my ScreenConnect IP address even though as far as I could tell no IIS sites were bound to the IP. My final solution was to create a batch file with the following code and setup a task to run the batch file 5 minutes after every reboot. Try creating this batch file and run it manually to see if it'll work for you as well.

**Note: Don't forget to replace the IP address.

Code:
net stop "ScreenConnect Relay"
netsh http delete iplisten ipaddress=192.168.1.1
net start "ScreenConnect Relay"
netsh http add iplisten ipaddress=192.168.1.1
samehuz  
#5 Posted : Monday, February 8, 2016 7:33:06 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Thanks Jon, your response helped me to think straight and focus on the root causes of my issues. I'm going to document them here in a longish post because I didn't find much help online for my use case and it might be helpful to others.

This only applies to users who are sharing a Windows server with IIS-hosted web sites or self-hosted services and ScreenConnect. In addition, I am using an SSL certificate to secure the ScreenConnect Web Server service.

My problems started when my ISP summarily relocated my VPS (and assigned new IP addresses) with a day's notice, screwed up a couple of settings and subsequently 'reset' my custom configuration using 'CPanel' or equivalent support tool. I had also neglected to record all the required setting and couldn't figure out what had gone wrong. Here is what you need to know to resolve this situation (or build a ScreenConnect site from scratch while co-existing with IIS):

1. By default, IIS manages all available IP addresses and allows 'wildcard' bindings for sites, meaning that any address can be allocated at runtime. You can see the managed IP's like this from the command line:

C:\Windows\system32>netsh http show iplisten

IP addresses present in the IP listen list:

127.0.0.1
192.168.30.212
192.168.20.143
192.168.0.141

2. You need a dedicated IP address for the ScreenConnect Relay service. You can free it up like this:

C:\Windows\system32>netsh http delete iplisten ipaddress=192.168.0.141

IP address successfully deleted

C:\Windows\system32>netsh http show iplisten

IP addresses present in the IP listen list:


127.0.0.1
192.168.30.212
192.168.20.143

3. Something that was confusing but obvious in retrospect was that the address I had [mentally] reserved for ScreenConnect was showing up in netstat as being listened-to by process ID 4 (System) even though no sites were actually bound to that IP after I cleaned up the wildcard bindings (by assigning explicit IP's in IIS Manager). This (below) is normal if an IP is on the IP listen list (even if unbound) as shown in item 2 above:

C:\Windows\system32>netstat -aon |findstr 141
TCP 192.168.0.141:53 0.0.0.0:0 LISTENING 1488
TCP 192.168.0.141:80 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:80 68.243.35.137:48252 TIME_WAIT 0
TCP 192.168.0.141:80 50.206.138.180:1127 TIME_WAIT 0
TCP 192.168.0.141:443 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:4430 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:4435 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:4440 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:5985 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:8172 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:9001 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:9002 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:9003 0.0.0.0:0 LISTENING 4
TCP 192.168.0.141:47001 0.0.0.0:0 LISTENING 4
UDP 192.168.0.141:53 *:* 1488

4. Once I completed step 2 only the following was left in netstat:

C:\Windows\system32>netstat -aon |findstr 141
TCP 192.168.0.141:53 0.0.0.0:0 LISTENING 1488
UDP 192.168.0.141:53 *:* 1488

5. The post-migration IP settings in the ScreenConnect web.config file had to be changed as follows (note that the IP addresses are listed explicitly and the WebServer IP is shared with IIS):

<add key="WebServerAddressableUri" value="https://myservice.myserver.com:443/" />
<add key="WebServerListenUri" value="https://192.168.20.143:443/" />
<add key="WebServerAlternateListenUri" value="http://192.168.20.143:80/" />
<add key="RelayAddressableUri" value="relay://relay.myserver.com:80/" />
<add key="RelayListenUri" value="relay://192.168.0.141:80/" />

6. The SSL certificate in my case expired during the migration snafu but even if it hadn't it would have had to be bound to the new IP manually since you don't have a handy 'website' to manage in IIS. You can remove the old binding and add the new one using the thumbprint of the certificate. ScreenConnect recommends using a string of zeroes for the Application ID field in the command line argument below:

netsh http delete sslcert ipport=old.ip.address.port:443
netsh http add sslcert ipport=192.168.20.143:443 certhash=a0c4e7540d61098358a081ed2d412cdbf668a46e appid={00000000-0000-0000-0000-000000000000}

7. The ScreenConnect Web Server will NOT operate with an expired SSL certificate because it cannot secure the session to it's satisfaction. You set this up by specifying https in the web.config file as in step 5 above so do not assume that you can simply ignore the warning.

8. In addition to being unable to get the Web Server and Relay services started (with the event log errors above) I had additional issues with IIS IP/port bindings. One way to troubleshoot this is to stop IIS from the IIS Manager, successfully start the ScreenConnect services and then restart IIS. Sites with clashing bindings will not start properly and this will be graphically indicated in IIS Manager. You can then go in and change those bindings to a free IP address. In my case, that 'CPanel' type 'Portal' site did not want to share port 80 with ScreenConnect Web Server so I simply pointed it to my primary IP (I have three, a primary and a secondary by default and an additional one for ScreenConnect). If you have a plain vanilla windows server with standard websites on port 80 and a free port at 443, two IP's should be enough. Note that using a port other than 443 may backfire because it may not be accessible from behind corporate firewalls.

9. In my case, firewall exceptions for ScreenConnect migrated successfully but you may want to recheck them before using the ScreenConnect Administration page to verify your installation.



jonmcknight  
#6 Posted : Monday, February 8, 2016 8:26:03 PM(UTC)
jonmcknight


Rank: Advanced Member

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

Joined: 1/30/2015(UTC)
Posts: 47
United States

Was thanked: 7 time(s) in 5 post(s)
Glad to hear you found a solution. Just out of curiosity, have you rebooted your server since you made these changes? Did the ScreenConnect server start up correctly after the reboot?
samehuz  
#7 Posted : Monday, February 8, 2016 9:32:43 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

I just rebooted successfully to confirm but, again in retrospect, none of the required modifications was volatile so I'm a little curious why you asked...
jonmcknight  
#8 Posted : Monday, February 8, 2016 9:55:22 PM(UTC)
jonmcknight


Rank: Advanced Member

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

Joined: 1/30/2015(UTC)
Posts: 47
United States

Was thanked: 7 time(s) in 5 post(s)
On my current server setup I performed more or less the same actions as you, (minus the SSL certs), and couldn't get the ScreenConnect relay to consistently start after a server reboot. Sometimes it would start, more often it wouldn't. So I gave up and created the batch file I mentioned earlier and setup a scheduled task to run the batch file 5 minutes after every server reboot. This workaround makes sure the relay is up and running 5 minutes or so after every reboot. Not how I would have preferred it, but good enough for now.

Server configuration and management isn't really my strong suit. I lean more heavily towards software programing.
samehuz  
#9 Posted : Monday, February 8, 2016 10:24:10 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Well I'm a jack of all trades myself so I can't add much light to that situation :-) although I'm tempted to guess that it's because the IP is not 'available' or resolvable at boot for some reason related to the DHCP/gateway etc. - I had something like that happen once with my own product in a situation where all the customer machines were being automatically rebooted at midnight on Sunday.

One possible alternative to the macro would be to try setting the service startup type to Delayed Start (Automatic)...
rmmccann  
#10 Posted : Monday, February 8, 2016 10:48:08 PM(UTC)
rmmccann


Rank: Advanced Member

Medals: Level 2: Lent a Helping Hand! 10 Thanks!

Joined: 12/16/2012(UTC)
Posts: 184
Location: MN, USA

Thanks: 17 times
Was thanked: 21 time(s) in 18 post(s)
I'm not familiar with the netsh command you guys are using, but in your IIS config is there a wildcard binding on port 80? If so, you can remove that and specify the IP/port/hostname (optional) combo you want enabled for the websites you run in IIS. Alternatively, you can simply disable the default website and create new ones with the above information.

The long and the short is you do need a dedicated IP for SC if sharing port 80 with IIS, but you should be able to tell IIS to not use that IP address at all.
samehuz  
#11 Posted : Wednesday, February 10, 2016 2:53:41 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

I'm not an expert on this but I believe that listening on all IPs port 80 is the default behavior as of IIS7, even if there are no sites bound explicitly or via wildcard (*), and that there is no GUI alternative to netsh within IIS Manager - if anyone knows of one, please share.

Ref:
https://support.microsoft.com/en-us/kb/954874
http://djlab.com/2012/10...p-bindings-from-iis-7-5/
rmmccann  
#12 Posted : Wednesday, February 10, 2016 7:01:27 PM(UTC)
rmmccann


Rank: Advanced Member

Medals: Level 2: Lent a Helping Hand! 10 Thanks!

Joined: 12/16/2012(UTC)
Posts: 184
Location: MN, USA

Thanks: 17 times
Was thanked: 21 time(s) in 18 post(s)
Odd that I've never encountered it before, of course I'm using IIS to redirect port 80 to 443 on my SC installation so it doesn't apply to me.

If it's an issue of "who gets the binding first" - perhaps you could configure your SC services to Automatic Start and configure the W3SVC (IIS) service to Delayed Start. That would at least give SC a chance to bind to its IP addresses if the netsh command doesn't seem to stick.
samehuz  
#13 Posted : Wednesday, February 10, 2016 8:04:55 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Uh-oh... I just came back because I saw an update and this time I noticed a problem with Jon's macro. That 4th line is a sort of infinite loop problem - the 'delete iplisten' allows Relay to start in line 3 but the 'add iplisten' after that sets IIS up to 'recapture' that IP for the next reboot. Which is why you need to run the macro again.

I'm not sure but I would expect to find a warning in the event log when you do the 'add iplisten' after starting Relay since, this time, it's IIS that can't take ownership of the IP. The point, I guess, being that even if something were causing you to independently need lines 1-3, line 4 is almost certainly redundant.

If you didn't already have it working and also didn't have better things to do, I would suggest running the 'delete iplisten' once manually from the command line and trying for a delayed start on Relay.
RGgusnowski  
#14 Posted : Wednesday, February 10, 2016 11:39:51 PM(UTC)
RGgusnowski


Rank: Advanced Member

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

Joined: 4/22/2014(UTC)
Posts: 97
Canada
Location: Edmonton

Was thanked: 7 time(s) in 6 post(s)
I know that you said that IIS coexisted happily before the migration, but sometimes simple is better.

Do you have a specific need for IIS? If you do, then I'm sure that there is some sort of work around, but if you don't, why not uninstall the component?

It does sound a bit drastic, but sometimes the KISS approach has its advantages. On my ScreenConnect install, (Server 2008) I chose not to install IIS and I have ScreenConnect configured to listen on port 80 and use port 443 as the relay address: it makes going through firewalls simple.

The one risk I am taking however is passing my login credentials in clear text. That risk could be mitigated by enabling Two-Factor Authentication. Another option would be to buy an SSL cert and flip the ports. As with most things in IT, there are usually multiple options when it comes to solving a problem.
samehuz  
#15 Posted : Thursday, February 11, 2016 2:07:47 PM(UTC)
samehuz


Rank: Newbie

Joined: 2/23/2015(UTC)
Posts: 8
United States

Kinda surprised this thread is still alive since there is a fairly comprehensive resolution at post #5...

Thing is, if you have a hard requirement for a single server that can simultaneously and securely support ASP.net web sites, WCF services AND remote access/meetings then ScreenConnect works great, you just have to rent an extra IP address and configure stuff appropriately and - unlike this genius - remember or record the configuration settings, which are about as simple as they can be given the requirements.

Also, if you install a $~10 SSL certificate from namecheap.com and dedicate port 443 for https then customers will be able to securely connect to a meeting or support session from behind corporate firewalls with about 1 command line statement and 3 edits to the web.config file (see post #5).

Edited by user Thursday, February 11, 2016 4:50:04 PM(UTC)  | Reason: typo

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.