I did go to G2Crowd and Capterra to write a review. G2Crowd required me to have a LinkedIn account; Capterra required me to give them my name and e-mail address and permission to do whatever they wanted with any information I give them. Since I don't provide false information, their terms were unacceptable.
As an alternative, I've posted a brief review here.
Pros After weeks of research I found [censored] (TV) and Remote Utilities (RU) to be the only remote access products I was willing to invest more time and energy in investigating further.
I think they are largely equal in the features I wanted, except importantly RU offers a direct (no intermediate server needed) connection option whereas TV does not.
I like Remote Utilities' cleaner design much more. The features are broad and deep. The Viewer's image of the remote host's screen is crisp and clear and quite responsive to remote control. The documentation is beautiful. Support is excellent. Product development is very active.
The two commercial travelers I support will be using RU to access information and sometimes functionality on their unattended office computer from the field. I will be using the product to provide IT support for them remotely.
This product does exactly what we want really well and will help us immensely.
The more I study and experiment with the product, the more I like it and the company; and the more confident I become that this will remain our remote access tool for the foreseeable future.
Cons The documenters are in the process catching up to the recent releases, but I found no significant cons.
After the comments I've heard it now seems that the current ribbon connection mode icon behavior might be best left as it is. My use case I now think would be used by far fewer users doing far less demanding work. It is also easily accommodated by the current design. There's thus insufficient justification for adding complexity.
More small things:
1. It speaks well of the Remote Utilities software and documentation (beautifully done) that there is so little activity in the forum of such a widely used product. (Potential customers: do yourself and your organization a big favor and get this software.)
2. It would be useful to be able to modify the title of a forum posting after the post has been submitted.
3. Under Host Setting > Security > Users and access control, I would change "User name" to "Remote utilities user name" to quickly distinguish it from the Windows user name.
4. Under point 5 of number 3 above regarding "Permissions for individual users can be overridden by global permissions set on the Modes tab."
I think this is incorrect. When a mode is disabled on the "User Access - RUT Security" window and enabled on the Security > Advanced > Modes tab, the statement states that the mode is enabled for the user when in fact it is disabled. The Modes tab setting (enabled) does NOT override the "User Access - RUT Security" setting (disabled).
It seems a connection mode is enabled for a particular user only if is enabled both on the Modes tab and on the user's "User Access - RUT Security" window.
In my most humble opinion, the previous behavior was superior to the one you replaced it with.
1. It felt right. Pick you object (connection icon) and then send it a message by clicking a connection mode icon (change its connection mode; or if there is no TCP connection already, open a TCP connection and set the connection mode to the one chosen). I'm also not sure the value of having separate login and logout concepts warrants the added conceptual complexity, but that's for another time.
2. Clicking a connection icon and then clicking a connection mode icon is easier than right clicking a connection icon and moving to a context menu item and clicking it. Small differences in effort become significant when you do them often.
3. There are use cases where a user goes fr om one connection icon to the next using the same connection mode each time. Mine is the other high level use case wh ere the user goes from one connection mode to the next while using the same connection.
I submit the previous method was not redundant but rather a superior way of performing the same operation (changing connection/connection mode combinations) for the other high level use case.
Have I made the case to reconsider reestablishing the previous behavior, or are my assumptions and reasoning flawed in some way?
Windows 10 Pro; RU 22.214.171.124 Rather than submit numerous questions all at once, I'd like to get answers to questions that might suggest the answers to other questions I have before asking them.
Question 1 After I log in and follow the following documentation, the expected Full Window doesn't open. When I select Full Control and double click the connection, the does open. The former behavior would be preferable for me. 1. Select a connection in the address book 2. Click Full Control on the General tab: 3. The Full Control window will open:
I had already implemented much of the advice given above so below I describe the parts I was missing. I'm going to ask a couple of questions about RU related to this later. Also later, I'll put together a checklist that might be useful to others.
I applied Benny's advice to add a UDP port 9 port forwarding rule in my host's router and install the WOL Magic Packet Sender application he pointed me to on the Viewer machine. That was essentially the answer.
I shut down the host with the Windows shutdown command found in the Start menu.
Then on the Viewer machine I opened Magic Packet Sender and entered the DDNS domain name (I had registered with No-IP.com) in the Host Name, and the MAC address of my host adapter; and left the default protocol at UDP and port at 9.
When I clicked Send the host started up immediately.
The host and viewer were admittedly on the same subnet, however the magic packet was sent to an external IP address and thus I think over the Internet.
A little more experimenting and then a follow-up post.