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.
But another colleage in another state, can not direct connect. Am I assuming wrong, that if I can get through, they can?
Additional setup may be required for being able to connect over the Internet. Specifically, you need to access the router settings on the Host side and set up a port forwarding rule. That is, to forward incoming requests at port 5650 to the computer where the Host is installed.
Actually, you can hide the menu in the Host settings. Here is how it looks like in the Host 22.214.171.124 settings:
In older versions including the current stable version 126.96.36.199 this option is available in Settings for Host -> Options.
Note, however, that if the user is administrator on their machine and you hide the menu, they will still be able to stop the Host. We cannot go against Windows security architecture and prevent full admins from doing whatever they want on their machine.