Community


can I use self-hosted server without a license?

Links used in this discussion
Athar Company, User (Posts: 4)
Aug 06, 2020 7:27:18 am EDT
Support level: Free or trial
can I host self-hosted server on my vps server with unlimited concurrent techs supports unlimited endpoints without purchasing a license? if cannot, how does RU check the number of concurrent techs and endpoints used by the viewers when connections are passed by the self-hosted server?
Conrad Sallian, Support (Posts: 3033)
Aug 06, 2020 1:26:32 pm EDT
Hello Athar,

Thank you for your message.

Unfortunately, using our free self-hosted server does not imply unlimited use of Remote Utilities. For using Remote Utilities you need a license anyway. You can, however, integrate RU with RU Server regardless of the license type that you use, even the free license will work.

Hope that helps.
Thomas Inman, User (Posts: 4)
Sep 18, 2020 12:25:51 am EDT
Support level: Free or trial
After reading this thread, I'm still confused about licensing a Self Hosted server.  Searched the Community and Knowledge Base and did not find any clear answers about limitations of self hosted server on a VM licensing, limitations, or anything else.

Could you explain in concise terms if this configuration is free and unlimited?  Or, if it is limited in some way, how exactly?

Thank you
Pauline, Support (Posts: 2860)
Sep 18, 2020 5:45:49 pm EDT
Hello Thomas,

Thank you for your message.

Despite the fact that only the Viewer module is registered with the license key and Host and RU Server modules do not require registration, this does not imply that the RU Server can be used unlimited. There are built-in methods in the software that can keep track of the license usage.
This way, when it comes to a Free License - it allows you to add up to 10 remote computers in your Viewer address book and 1 concurrent tech which means that only one Viewer registered with the free license key can be actively running remote sessions at a given time (i.e. you're not restricted to a specific workstation, but it's only possible to work from one Viewer at a time). In addition, please note that according to our EULA, only one free license key is allowed per individual, company, or organization.

To summarize, when using the free license, you can connect to up to 10 remote Host machine from 1 Viewer at a time using the self-hosted RU Server solution.

Hope that helps.
Thomas Inman, User (Posts: 4)
Sep 18, 2020 7:54:13 pm EDT
Support level: Free or trial
I have been struggling to make RU work reliably, even after installing the beta2 version recommended elsewhere.  Machines go offline/online periodically, and most of the time do not respond when I try to initiate a remote session using Full Control or RDP.  It appears as if connections can only be made if the wind is blowing a certain direction.  I'm at a loss to explain how this could be so unreliable.  RU has been around for years, so I'm shocked, frankly, that maintaining contact with remote machines is so sketchy.  If RU isn't reliable, then how am I supposed to use it to manage my customer systems?  Other services I have used were all exactly the opposite, meaning they have always been ultra-reliable, rarely leaving me unable to access a remote machine.

I've read all of the documentation, countless messages in the community forums, youtube videos, google searches for answers, etc, etc.  Other than the release of the beta2 version, I have not found any viable answers as to why connections to any machine work 20% of the time, if at all, whether it be on my own LAN or the LAN of any of my customers.  Something is seriously wrong here, and I wonder if you can shed some light on this on-going issue.

Thank you
Pauline, Support (Posts: 2860)
Sep 21, 2020 4:40:27 pm EDT
Hello Thomas,

Thank you for your message.

Could you please clarify if the issue occurs when you use Direct connection only, Internet-ID connection only, or both? Have you tried the solutions listed in these KB troubleshooting guides for Direct connection and Internet-ID connection respectively?
In case if the issue occurs when using both Internet-ID and Direct connection, then there might be something on the Viewer's side that might be causing such behavior.

Could you please clarify if you have any antivirus software installed on the Viewer's side, perhaps, with some add-on like a VPN client? For example, we've been recently reported a similar issue occurring on the Viewer machine with the BitDefender antivirus installed that also included the VPN add-on, which was proxying and editing the https traffic. In case if you have any antivirus software installed, then could you please double-check if you have any similar add-ons installed as well? They might be visible in your network adapter properties.

In addition, if none of the solutions above seem to help in resolving the issue, please feel free to send us the log files for examination. We could use the Viewer logs and the Host logs from one of the Host machines that you experience the issue with. You can send the logs to support@remoteutilities.com.

Hope that helps.
Thomas Inman, User (Posts: 4)
Sep 22, 2020 7:02:22 am EDT
Support level: Free or trial
Since I don't need any additional software to make direct RDP connections to local machines, my main interest is in connecting to remote machines not on my LAN.  I have read those documents multiple times thinking I must have missed some detail, but I don't think that is the case.  Choosing Direct connection over Internet-ID does not work because some machines cannot be found by their name, and their IP addresses can change from time to time.  Using Internet-ID seemed like the most desirable method, but again, the connection status in the Viewer seems to change every time I look at it.  It just keeps changing status, machines going offline and online again - unresponsive to launching a windows RDP session.  Some machines display notification that the host software needs to be updated, in spite of already updating them both via the console and the Viewer.  Viewer and Host installations are all beta2 version.  Server is installed on an AWS VM, which appears to work.

While I work on making Remote Utilities work properly, the best alternative I've found and am using with remarkable success, is L0gmein Hamachi VPN (not installed on same machine as Viewer) to machines on a trusted remote LAN, and simply connecting to them via RDP.  No tools, like screen recording and session notes, but it's super fast, spans multiple monitors, handles remote printing without need to install drivers or any additional configuration, and it rarely fails to connect.  The only thing I really want from RDP is shadowing so I can see the console with full control, together with the user, to troubleshoot issues.  So far, all of the information I've found after extensive searching appears to be obsolete for the most recent versions of windows 10 pro in 2020.  I have used various command line flags, group policies, registry edits, and none of them worked across the Hamachi VPN to another remote LAN.  RDP sessions with switches or without, the connection is a tcp session, not the console. So that was a lot of reading and testing to donate.  I've also put in a lot of time trying to make RU work as designed.
Pauline, Support (Posts: 2860)
Sep 22, 2020 5:11:04 pm EDT
Hello Thomas,

Thank you for the clarification.

Choosing Direct connection over Internet-ID does not work because some machines cannot be found by their name, and their IP addresses can change from time to time.

Please note that Direct connection can be only used in case if the remote Host machine can be addressed by its external IP address or hostname (DNS name). However, you can also establish a Direct connection over the Internet if you create a port forwarding rule in the router settings on the Host side. Please see this page for more information.

Using Internet-ID seemed like the most desirable method, but again, the connection status in the Viewer seems to change every time I look at it. It just keeps changing status, machines going offline and online again - unresponsive to launching a windows RDP session.

Please note that when using the RDP connection mode over the Internet, the RDP-over-ID feature is used automatically. In addition, please note that the RDP mode in Remote Utilities just launches the native Microsoft Remote Desktop Connection client from within Remote Utilities and connects to a remote computer using the standard RDP protocol.

In case if you're experiencing such connectivity issues using both Direct and Internet-ID connection as well as when using RDP and the Full Control and View connection modes, please feel free to send us the Viewer and Host log files for examination to see if it's possible to identify what might be causing the problem. You can send the logs to support@remoteutilities.com. Unfortunately, without the log files we can't tell the exact reason for such issues as the log files are used for the connectivity troubleshooting.

Hope that helps.
MaxBlitzer, User (Posts: 68)
Sep 29, 2020 12:39:04 am EDT

Polina Krasnoborceva wrote:

Since I don't need any additional software to make direct RDP connections to local machines, my main interest is in connecting to remote machines not on my LAN.  I have read those documents multiple times thinking I must have missed some detail, but I don't think that is the case.  Choosing Direct connection over Internet-ID does not work because some machines cannot be found by their name, and their IP addresses can change fr om time to time.  Using Internet-ID seemed like the most desirable method, but again, the connection status in the Viewer seems to change every time I look at it.  It just keeps changing status, machines going offline and online again - unresponsive to launching a windows RDP session.  Some machines display notification that the host software needs to be upd ated, in spite of already updating them both via the console and the Viewer.  Viewer and Host installations are all beta2 version.  Server is installed on an AWS VM, which appears to work.

While I work on making Remote Utilities work properly, the best alternative I've found and am using with remarkable success, is L0gmein Hamachi VPN (not installed on same machine as Viewer) to machines on a trusted remote LAN, and simply connecting to them via RDP.  No tools, like screen recording and session notes, but it's super fast, spans multiple monitors, handles remote printing without need to install drivers or any additional configuration, and it rarely fails to connect.  The only thing I really want fr om RDP is shadowing so I can see the console with full control, together with the user, to troubleshoot issues.  So far, all of the information I've found after extensive searching appears to be obsolete for the most recent versions of windows 10 pro in 2020.  I have used various command line flags, group policies, registry edits, and none of them worked across the Hamachi VPN to another remote LAN.  RDP sessions with switches or without, the connection is a tcp session, not the console. So that was a lot of reading and testing to donate.  I've also put in a lot of time trying to make RU work as designed.

1. You can ONLY use Internet-ID feature as replacement for Hamachi in your case. Forget Direct Connection, forget RDP connection, especially if you want the person in front of the computer to see what you're doing on the screen instead of a login page like they would with RDP. Just right click on a host and "Full Control".

2. The status' won't be as reflective as they are in Hamachi, which was more real time and RUT is either delayed, or they only get certain information at time of the Viewer being opened, or after a connection to a host was made. If Internet-ID is se t for them, then the status for Online should be fairly correct aside from network issues.

3. I actually got onto RUT to switch away from using Hamachi for the occasional time Hamachi client screws up, plus the occasional Win Home machine without RDP, but unfortunately found I've had to keep both around as both services fail occasionally (RUT upgrades had some breaking issues a few times in previous years) and paying for each service costs less than a truck roll to fix it. Since in your case all of your clients have Pro/RDP capable, if RUT failed to connect on a random client, you'd still be able to remotely access another client at same location and RDP into it locally from there to fix RUT connection. In my case, I couldn't do that.  I think RUT upgrade issues are not really an issue anymore once they are on current versions, but upgrading from really old versions will have issues.

4. If you're only getting connections only 20% of the time using Internet-ID, you have network problems, or the computers are sleeping or rebooting (Win updates). Either way, I can say from experience, it's on your end. In the "IP Address" column in the viewer, when using Internet-ID, that will be the IP address of the RUT server your connection is relaying through.  Ping that IP in a cmd window and see if you're getting packet loss or if the pings are over 100ms.  If pings are over 100ms, you're going to want to setup a local RUT relay server yourself, or switch people over to using direct connections (you'll need access to their routers to make port forwards). Unless you setup direct connection, you'll never match the performance of using RDP and Hamachi. First, RDP uses less bandwidth and more performance than RUT, and second, Hamachi sets up direct connections between endpoints instead of using a relay.

I tried making the argument to RUT years ago for implementing direct peer to peer connections instead of the relay (and relay only used as fallback wh ere it can't arbitrate a direct connection between two peers), but for some reason they think their customers want their direct traffic to be relayed through RUT servers for security reasons. At that point, I setup a RUT server at the nearest datacenter and use that wh ere I don't have router access to setup RDP port forwards for direct connections. If you have a lot of machines all going through the Internet-ID (using RUT relay server), you'll experience a lot more network connectivity issues than you'll care for and you'll find it better to setup a RUT server on a fast, public Internet connected machine local to your users and you.

* Website time zone: America/New_York (UTC -4)