Thank you for the kind words. Regarding the free version 5.x - we discontinued ID service for that version, but for a different reason. Version 5.x was frowned upon by antivirus programs just too much, because it was relatively easy for bad guys to plant malware or patch that version and get away with that. So we made our free 5.x users to upgrade to version 6, but we didn't take away their free license.
I will note down the suggestion, of course. Perhaps, there is indeed a way to automatically detect and fix the issue, although it wouldn't be a good practice to change any settings without the user knowing. We'll see.
Aaron Levinson wrote: 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.
Yes, and it most definitely will. For example, in the upcoming update we'll store the settings in a different registry entry than where they are stored now. Instead of:
the settings will be in
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.
Thank you for the suggestion. I will forward it to our developers and we'll see what we can do.
Aaron Levinson wrote: 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.
Yes, that's right. We'll update the description on that page then.
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.
Thank you. No problem you using the free license. It's just a matter of convenience. Indeed, if you have many remote PCs in your address book, it might be suboptimal to stick with the free license and constantly create and delete records in the address book.
To all of you guys - we found a way how to add a digital signature to custom configured installers without "going online" with our MSI configurator. So we'll soon implement this feature and any installer, including custom ones, will be signed with our digital signature.
There is currently no idle check in the program. However, you can use another solution. Enable the Ask User permission feature and set Auto-alow on timeout. If the user is there they can access or reject your remote connection request. If there are not there, you'll still be able to connect after a specified time.