Since we updated our hosts and viewers to the latest versions, we have noticed that the host service running on the end-user machines does not always inform the end-user that someone has connected. For example, previously the icon would turn red and the system would say "xxx has connected".
Unfortunately, this is a bug in version 220.127.116.11. You can update to the current 18.104.22.168 beta to have it fixed. Important: If you use self-hosted server, you should update the server to version 2.7 beta as well, as it is compatible with RU 6901 beta.
Since Host and Viewer are not bundled together and if backward compatibility breaks or changes on every version, then it should be more obvious to the user when there is a version mismatch that would prevent connection.
Newer Viewer can always connect to older Hosts. Compatibility the other way around is not guaranteed. That's why we highly recommend to at least make sure the Viewer version is the latest if it's not immediately possible to update the Hosts.
The Viewer knows the version of itself.
This is true.
The Viewer knows the version of the host.
Only when it connects or logs in on the Host at least once. If that happens, information about Host version becomes available in the address book. In the thumbnails view there is a tiny "msi" icon at the top right corner. In the Details view there are two dedicated columns:
The typical user (*cough* *cough*, myself included here. Though in this case, I KNOW I've read that before, just forgot) doesn't read documentation until they run into a problem. Errors and messages help tell the user where they should look in the documentation. The pop up informs the user what the exact problem is and what to do about it. Problem solved in minutes.
I can agree with this, but unfortunately, when version mismatch is involved there may be a problem or there may not. It's a probability thing depending on what specific feature the user is trying to use. Less intrusive methods of informing about version mismatch (such as the ones above) may work best especially on hundreds and thousands of address book records.
Issue resolved. Turned out it was the Viewer being 22.214.171.124 and the server host being 126.96.36.199. I didn't realize 188.8.131.52 Viewer couldn't talk to 184.108.40.206 beta. So just upgrading her Viewer to 220.127.116.11 made the connecting work.
Yes, there is backward compatibility only when you connect from newer Viewer to older Hosts, but not vice versa. We also mention that on the upgrading page - it is recommended that you upgrade Viewer first, then Hosts. Also, good practice is to avoid version mismatch, i.e. update Hosts as soon as possible.
As for the beta version and if you use the self-hosted server, it should be upgraded too. With RU 18.104.22.168 beta we also released Server 2.7.
I also saw the check marks she was seeing. Doesn't look like my screen and I didn't take any screenshots. But it's not intuitive as to what the check marks mean, since it was green for the offline connection and red for the online connection. Also, it frequently only showed the Internet-ID connection as online and the Direct connection Offline/unknown until double clicked and connected.
Checkmarks are essentially the results of the ping command. A remote computer may be "pingable" but the Host may not be running on it. This will result in a green checkmark and yet an RU connection won't be possible. An opposite example is that pinging a remote computer is not allowed (pings are unsuccessful) and yet it may still be available through RU. I wouldn't put much trust into these checkmarks then. It would be better to rely on the statuses instead.
They cannot use the Viewer to connect outside their home to their office. I'd expect them to block the host, but the viewer?! Jeepers.
The Viewer installer contains some modules of the Host (namely, rutserv.exe) for the MSI Configuration to work, specifically the "legacy" mode of the configuration (files are not needed for the "online" configuration option). That's why some antivirus software may falsely mark Viewer as dangerous. However, by extension they also mark rutview.exe which doesn't make any sense.
However, I'm trying to remotely help someone over the phone, she says she disabled both and still same result, "double clicking or selecting Full Control doesn't connect to server or give any errors or popups".
The feedback is on the connection icon/icons in the address book. If connection isn't possible, the icons will be in offline state.
Could there be a way to detect when the Viewer is being blocked from making any outbound connections?
Unfortunately, Viewer doesn't specifically monitor its own Internet access. However, in the future we were planning to add some basic diagnostics/monitoring features so that regular users could easily tell where the problem is.