1. Direct connection. No intermediate server is used, Viewer and Host communication directly. 2. Internet-ID connection. An intermediate server is always used. This can be either our hosted server, or a self-hosted server, your choice.
Authentication methods (are enabled on the Host when you configure it):
1. Single password. No separate users, no logins, just a password. 2. Remote Utilities security (login and password pair and permissions can be set per user). 3. Windows security. Piggyback on Windows security model and use Windows accounts for authenticating on a remote Host (or Active Directory accounts if on AD network). 4. Custom (self-hosted) server security. Using a self-hosted server for authentication. Somewhat similar to what a domain controller does in an AD network, i.e. acts as a gatekeeper and keeps all user authentication information.
Now connection types and authentication methods are not directly related. There can be any mix of them.
For example, you may use direct connection as your connection type, and use custom server security for authentication. In this case your Viewer and Hosts will only use your self-hosted server for that purpose (i.e. authentication) and not as a relay server for Internet-ID connection.
Another example, you may use Internet-ID connection through our hosted servers with Windows security authentication. That is, you can connect to a remote PC over the Internet and authenticate on the remote Host using the credentials of a Windows account on that remote machine (e.g. the local Administrator account). Of course, you must first add permissions for that account in Windows Security authentication settings on the Host.
While it's true that any combinations may be used, typically certain authentication methods are more often used with a specific connection type. For instance, using Windows security with direct connection makes sense because - as a rule - direct connection is used in a LAN or even a domain network and it's perfectly natural to use Windows accounts for authentication than to create accounts anew in Host settings (e.g. for Remote Utilities security).
Custom server security is a middle ground. It tries to bring the benefits of centralized account management to a scenario with Internet-ID connection used across remote machines scattered across the internet, i.e. not on the same LAN/AD.
To sum it up, you shouldn't bother with the self-hosted server (RU Server) unless it's absolutely necessary for your scenario.
I notice that the new server update has a note saying "Minor improvements to RU Server license registration mechanism." - I thought this might be a fix to the issue however it doesn't seem to have changed anything..?
Do you mean the issue of not being able to add a license key to server without Desktop Experience installed on the machine?
Unfortunately, no. In Remote Utilities paradigm the update process is always "human-initiated" and is under control. If Hosts start to update on their own this may lead to VIewer-Host version mismatch issues in case Viewer is outdated.
We understand that nowadays many apps update automatically but Remote Utilities isn't a single app, it's a dual app. And it dictates some caution when it comes to updating. Especially when a remote computer is many hundreds of miles from the user.
So long as the endpoints (Hosts) have access to the internet you can set up the Internet-ID connection to get to the Hosts. This is the easiest way to go since you won't have to do any network configurations on the routers.
However, if you insist connecting directly (without an intermediate server) to the remote Hosts you will have to forward ports twice - once on each router. I believe this might not be an option in this case.