Add the ability to set an alternate relay address
Our situation :
We have 3 offices in Canada (HQ, A, B)
HQ-A have MPLS link between them,
HQ-B use VPN over internet.
All location have independent internet access.
We use access session on all system in all location, but the relay is located in the HQ.
1 DNS name to the server that resolve to an external IP when out of the local infrastructure and an internal IP when inside the infrastructure.
- This way system on our internal network dont use the public internet access, it more secure, reduce the global bandwitch and load on our front end firewall.
The issue, if the inter-site link go down, the access session will not be able to connect, as the DNS will still resolve to the internal IP, resulting in disconnection.
Our need, be able to setup 2 URL for the a access session, as such when the 1st is irresponsible the client can try connecting to the second one, with a retest every X to go back to primary.
With this we could setup our client with a internal URL as primary and an external URL as secondary and still reach our system if the VPN or MPLS go down, but not the internet.
Customer support service by UserEcho
We have just installed a backup VDSL connection and would love for ScreenConnect to have installed a secondary DNS name to try, e.g Backup.company.com to allow the clients to connect to if the main connection is lost.
This means we don't have to wait for the DNS change to replicate is we go to a dynamic system, even then we'd have to reinstall all the clients to a new DNS name anyway.
Really looking forward to this!
This would also need to have alternate ports in case the network a device is on has restrictions preventing the default port from working (such as mobile users, or one-off systems on networks you don't have control over).
Do you have any update as the status change a lot on this request (from Completed, to Started, then Planned and now Pending Review)
Here's another application for this feature... My SC server hosts other applications using both IPv4 and IPv6. I would like to be able to provide specific IPv4 and IPv6 addresses for both the relay and web server to listen on. While I understand I could use the "WebServerAlternateListenUri" parameter to specify and IPv6 address, I am currently using that for port 80 so my users can just enter the server's FQDN and not have to type in "https" in the URL when accessing a support session.
I would like to see an option for fallback addresses similar to how LabTech does it. remote.mydomain.com|backup remote.mydomain.com|184.108.40.206 etc. You can add additional names/ip addresses in order you would prefer it to check in.
Yes, that would be useful, being able to add an IP address would means that even without DNS machines would still connect.
@kirsten Martinez : what does that mean under review, it is a progression or a setback versu considering for future release ?
It means we are revisiting the topic and will have discussions around it. Usually, these discussions are centered around how we can possibly design and build the feature/enhancement into the product. If it plays out well, we'll schedule it on our roadmap.
For whatever it's worth, failover capability would be a strong incentive for me to renew my license next year. I've only had to make a domain change very suddenly once so far, but it can happen and it was both memorable and time-consuming to manually update all of my clients. Being able to use a secondary to simply go "here's a new config with the new primary, queue update all" would have saved a lot of messing around.
Any update on this we are in the process of planing change to the port and domain we used when did the original setup. We are looking at a way to completed an update without breaking anything.
Right now I’m planing to use some form of port redirection to kept the old configuration working when the client are receiving the updated information but this feature will help a lot.
This would be super helpful for us as well. We host our CWM instance in-house. We have a failover internet circuit, but Control can't take advantage of it. As Control is our primary means of connecting to our client machines, if they can't checkin to the Control server, it's perfectly useless. Having the ability to have a secondary IP for the clients to try to connect with would be a hugely beneficial enhancement.
Failover WAN is a must have in todays Remote Support World and getting a secondary Cable Modem is cheap. Please add this feature ASAP, cannot be that hard to code just have a Primary DNS Name and a Secondary DNS Name and have the client poll when it does the Screen Update in the Console. We had an issue today with an outage and were unable to connect until I updated our external IP and we had to call remote customers to reboot their PC's, this is not an efficient method to explain to customers why. Please add a multihomed Client so we can add in Primary and Seondary DNS Names.or IP Addresss.
Thank you for Consideration.
Please make the port adjustable for the second host. i.e primary relay://domain.com:443 secondary relay://domain.com:80 This would allow us to attempt a connection on port 443 by default and then failover to port 80 for sites that do packet inspection on 443 and block the relay from connecting.
It would be nice to be able have the IPs from the Cloud tenants pushed out to the clients as well -- so the primary connection can be via DNS, but if for some reason DNS resolution isn't working it could still connect via IP.
I understand that the IPs on the cloud side can change from time to time and that I believe as things stand now, the config in question would only be refreshed when the client is installed... so understand that this might not be as simple of a change, but I think it would provide a great value..
At a minimum the ability for the client to try to connect to the last known IP if for some reason DNS isn't working
This should have alternate relays similar to how CW Automate works. We have had several situations where DNS failed and the control clients will not connect. If there was a backup/secondary via an IP address, it would have saved us a lot of grief.
I could be wrong, but connecting via IP sounds dangerous unless your SSL certificate has your IP address inside of it. Otherwise the control agent would have to accept invalid SSL certificates which could be bad if someone is preforming a MITM attack.
As far as I know, CWC does not use an ssl cert to communicate with the server. Neither does CWA. They use other methods of authentication.
Good point, I forgot that the control portion is using the relay address and is AES encrypted.
Dear Sean Keown, Please let know where I have to do the adjustment you indicate.
Any progress on this?