Conrad Sallian's community posts

Hi Rafi,

Regarding #1 - Sorry, I think I used the wrong term. I meant two Monitors. It seems to start with dual monitor view, and switch to #1. This takes time on a slow connection, and possibly can be avoided?

Ok, no problem. Actually, your monitor selection should be remembered for this connection so the next time you start it it should immediately show you the selected monitor. Is that the case?

Can you explain the way you currently implement the auto-reconnect (using IP? Using ID?)

Auto-reconnect is just what it is - the program attempts to re-connect to a remote computer if there is brief network interruption, usually a few seconds long or more (i.e. noticeable by human).

Auto-reconnect happens regardless of whether you use direct connection (IP based) or Internet-ID connection (ID based).

and how to make it always check for correct IP by ID and use the correct (modified) IP?

Frankly speaking this is the first time we see that a dynamic IP address is reported as a possible cause for connectivity issues. If network device (e.g. router) and local network in general is configured properly, there shouldn't be any issues with Internet access even if a network device is assigned another IP address.

Hello Anousch,

Thank you for your post.

Yes, you should be able to connect to your self-hosted server on the mobile client. Access the properties for the selected connection and choose RU Server.

Hello Alan,

Regarding callback, we are going to handle this differently. Instead of implementing manual mode we'll see if we can make it fully automatic, i.e. automatically determine if callback is possible.

Hello Rafi,

Thank you for your post.

I see that RU are always defaulting to two terminals view, even when the icon/control shows "1".

Do you mean terminals or monitors? When terminal sessions are involved Remote Utilities may default to "console" view but it cannot default to multiple terminal sessions at once, this is impossible.

If it is, can you please advise how to set it so that it will always use the RU *ID* for re-connection, so to acquire the updated IP and succeed?

The Internet-ID doesn't change unless changed by the user themselves. It is unlikely that this is the cause for the problem.

Let me know if any of these two problems have been fixed in the new Beta I see on your site.

I highly recommend you try using the beta and see if you still have these issues. Note that you should update both parts of the software , not just the Viewer.

Thanks.

Hello Eric,

We will include this feature in 6.9.0.1 beta 2 which is due in a couple of weeks.

Hello,

Thank you for your post.

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 6.8.0.1. You can update to the current 6.9.0.1 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.

Hello Chris,

Do you use any keyboard/mouse sharing or KVM software, like Synergy or ShareMouse? Note a similar thread here.

Hello Max,

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.

Hi Nick,

From the user standpoint and experience there shouldn't be any differences. Except perhaps the regular (current default) mode is a bit more optimized on newer systems such as win 10.

Thanks.

Hello Max,

Issue resolved. Turned out it was the Viewer being 6.8.0.1 and the server host being 6.9.1.0. I didn't realize 6.8.0.1 Viewer couldn't talk to 6.9.1.0 beta. So just upgrading her Viewer to 6.9.1.0 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 6.9.0.1 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.