Community

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?

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

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

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.

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.