Community

Hi,

Does Remote Utilities provide a generic tunnel capability in order to use network services on the remote host?  I know a tunnel of sorts is provided in the form of RDP support, but I'd like to know if this facility is available for any TCP/UDP port number.  For example, if I wanted to connect to a Web server hosted on the remote host over the Internet, and I connect to the remote host using its Internet ID, is it possible to setup a tunnel using the Viewer program to do this?  If not, it would be great if such a feature could be added.

Thanks,
AaronL

Conrad Sallian wrote:

Even if I were to use a direct connection or a self-hosted server (and I'm doing the latter), there is still the question of how the verification of pay licensing works.

Based on trust :-) We have our EULA and we expect our users to honor it.

Ah, that makes sense.  At https://www.remoteutilities.com/support/documentation/main1/item142/#license_count , it states: "For the 'per operator' license type the license count means how many users (operators) can work simultaneously from Viewers registered with this license key."  I had assumed this meant something was done to actively prevent more users than are licensed from using the same license key at the same time, but I realize now that my assumption was incorrect.

Thanks,
AaronL

I wasn't suggesting that Remote Utilities change a setting behind the user's back.  Instead, it could leave the setting as-is but internally use the legacy approach if it can detect that this is necessary.  If that is done, maybe the legacy capture setting can be removed (assuming it isn't useful for other reasons).  I would tend to think that automatically working around issues rather than requiring user intervention is preferable.

This forum isn't the best place for this post, but there really isn't an ideal forum for this, and since it relates to licensing, I thought that I would stick it here.

In the Security Overview document, at https://www.remoteutilities.com/buy/docs/security-overview.pdf , in the "An autonomous solution" section, "You never have to rely exclusively on our
infrastructure if you do not want to. Rather, you can configure it to be an entirely autonomous solution."  I wonder if this is really true, however, when it comes to pay licensing.

Even if I were to use a direct connection or a self-hosted server (and I'm doing the latter), there is still the question of how the verification of pay licensing works.  Based on the description of the "Per operator" and "Per remote PC" licensing options, it would appear that some network communication is necessary in order to adjust the count in the case that there are multiple operators on different computer systems using the same license at the same time.  And, I would tend to think that this network communication would happen through Remote Utilities infrastructure, regardless of which RU Server is used (or even if an RU server isn't used, as is the case with a direct connection), although I haven't run a packet sniffer to confirm this.  And, if it goes through Remote Utilities infrastructure, then the statement "you can configure it to be an entirely autonomous solution" isn't entirely correct.

I imagine that the statement could be true when using the free license, however.

Thanks,
AaronL

I admit that I feel uncomfortable using such great software without having to pay anything for it.  Remote Utilities was a much better option for my situation than any of the "bigger name" and smaller products out there, many of which I evaluated.  Even the RU Server (what I've been calling the broker server) is free.  Perhaps another type of pay license is in order.  One thing I noticed is that when things switched to 6.0, older versions of the software were no longer supported in the case that the free license was being used.  So, support is perhaps a reason to switch to a pay license.

Hi Conrad,

You had stated in an earlier post that "Windows 10 looks more promising", so I was basically responding to that.

However, what would be preferable is if Remote Utilities could somehow detect that screen capture won't work properly and implicitly switch to legacy capture mode.  When I first encountered this issue, I thought that it was likely that Remote Utilities had a bug.  If I hadn't been able to find this post, this would likely have been a showstopper for me.

Interestingly, this same issue, or one that is very similar, also exists for certain VNC servers.  Both TightVNC and UltraVNC are affected.  RealVNC works fine.

Thanks,
AaronL

Currently, in order to display the Internet ID to the user from my software (for a proactive remote assistance support model, which I discussed in more detail in my post to the Licensing forum), I extract it from the Registry, at HKLM\SYSTEM\Remote Utilities\v4\Server\Parameters in the InternetID key value.  Then, I extract the <internet_id> value from the XML stored in this key value.  Access to HKLM\SYSTEM requires elevated privileges, but that's not an issue for my software.  This approach to determining the Internet ID programmatically is fragile, since the way in which this information is stored by Remote Utilities could easily change in a future version of the software.  What I'd like to see is a command-line option to rutserv.exe that returns the Internet ID to stdout, perhaps something like /internetid .

In another post, I saw that a user was wondering if it were possible to bind Remote Utilities to a specific network interface.  The response was that this was possible in older versions of Remote Utilities but hasn't been available for some time.  I'm not asking for a way to do this from the Remote Utilities Host UI--what I am asking for is a command-line option for the /start command that would provide the ability to specify a specific network interface to bind to.  On a system with multiple network interfaces, Windows' TCP/IP implementation frequently makes bad choices when it comes to picking the best network interface to use.  For example, on a system with a fast Ethernet connection and multiple slower mobile broadband network connections, it usually picks one of the slow mobile broadband network connections, sometimes the slowest of the mobile broadband connections.  Windows TCP/IP appears to decide which network interface to pick based on the combination of the interface metric and gateway metric, and it frequently assigns poor choices for the values for each of these metrics.  It is possible to change them, and I've done that, but it doesn't work reliably, and the settings will sometimes revert to the defaults after rebooting the system.

In my software, I have an accurate means to detect which network interface would generally result in the best connection to the Internet, so what I'm asking for is something like:

rutserv.exe /start [/networkinterface <identifier>]

The <identifier> parameter could be an IP address, since that is what is needed for the call to bind(), as follows:

sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(0);
addr.sin_addr.s_addr = inet_addr(ipAddress);
int nRet = bind(s, (sockaddr *) &addr, sizeof(addr));

Alternatively, it could be the UUID associated with the network interface in question (as stored in IP_ADAPTER_INFO::AdapterName after a call to GetAdaptersInfo()).

Thanks,
AaronL

At https://www.remoteutilities.com/buy/licensing/free-license.php , it states that when using the free license, "The number of remote PCs you can control is limited to 10."  It is a little unclear precisely what this means, but in practice, it appears to mean that someone is limited to no more than 10 entries in the viewer's address book.

I'm planning to use Remote Utilities for remote control in the software product that I work on.  However, in my situation, I set Remote Utilities to run manually, and, in order to start and stop Remote Utilities, I use the /start and /stop command-line switches fr om my software to silently start or stop the Remote Utilities host.  In fact, the Remote Utilities user interface is pretty much hidden from the user of the host in my usage model.  In this usage model, remote assistance is provided proactively--I don't need 24 hour access to remote systems.  The user of my software would call a phone number to get in touch with someone, and the user would also provide the Internet ID (which I extract from the Registry and display to the user).  This is one of the reasons why I selected Remote Utilities--it is possible to use it without exposing the Remote Utilities user interface to the user.

In this sort of usage model, there is no point to persisting entries in the viewer's address book, since any time the viewer is used to connect to a remote host is done on a temporary basis.  As such, it is very easy to keep to the 10 PC address book lim it.  In fact, I can get by with a single entry in my viewer's address book and then changing the Internet ID as needed.

However, I want the ability to control more than 10 systems, just not all at the same time.  The way the free license works allows for this.  Nevertheless, regardless of how the free license is implemented in the viewer, I'd like to make sure that I'm honoring the terms of the license if I use it with more than 10 host systems.  If the free license isn't truly suitable for my usage model, then I'll go with one of the pay license options.

Thanks,
AaronL

I discovered this post through an Internet search.  I ran into the same issue on Windows 10 with the display rotated 270 degrees.  The problem clears up when switching to legacy capture mode (or with the screen rotated 0 degrees).  So, it would appear that the issue isn't fixed with Windows 10.