Conrad Sallian's community posts

Hello,

Thank you for your message.

The only "issue" (well, actually just a lack of a feature) is that you cannot use "Simple update" to update your Hosts remotely once you updated the Viewer because this feature was implemented starting version 6.6. Otherwise, the update process should be ok.

Any particular instructions in performing the upgrade on the Hosts other than the 'check for updates' option? Loosing connectivity is not an option to most based on location and timing of accessibility. All Hosts are running either Win7 or Win10. Thanks

A rule of thumb when remotely updating your Hosts is that you update the Hosts  in small groups and keep control over the process. First, you upgrade the Viewer, then you upgrade one or two Hosts to test the procedure and see if there are any adjustments you should make to your process, and then proceed with updating the rest of the Hosts (every 10-20 Hosts at a time).

That said I highly recommend that you wait another two weeks and update to version 6.9 when we release it. There were quite a few important changes as compared with version 6.8, see the release notes as well as the recent posts in our blog.

Let me know if you have any questions.

Igor wrote:

InternetIdService.exe in 2.7 beta is an AMD64 image.
My "server" is Windows XP SP3 x86

Hi Igor,

Unfortunately, the new version of server only runs on 64-bit systems. Sorry for that.

Hi Paul,

Having said that, it seems rather backwards to me. I can think of all kinds of bad things happening if a rogue viewer (controller) connects to a given host, but I have a hard time picturing the same type of concern that I've connected to the wrong host.

I see. And yet, the host identity mechanism as it can be seen in version 6.8 and earlier was to prevent just that - unauthorized replacement of the Host with a rogue/patched copy.

Perhaps I could add this 'shared secret VIEWER verification' option as a feature request. This way I could honestly tell clients/customers that no other RUT viewer can get to their computer. That their host would speak to ONLY MY viewer. The current implementation (and the certificate based scheme in the beta version) does not offer that assurance.

The new PIN-code system in the beta 2 may fit for this purpose, although you must be using the self-hosted server in order for it to work. See more information in this blog post https://www.remoteutilities.com/about/blog/Remote_Utilities/6.9-beta-2/ . We will still note down your suggestion though.

Hello Paul,

Thank you for your message.

This is the correct behavior. The purpose of shared secret is to provide the means to verify the identity of a remote Host, not to serve as another password or authentication factor.  The program logic here is as follows: If  there is a shared secret on the Viewer side (in connection properties) then the program performs the identity check. If it's empty , then the check isn't performed because the program assumes that admin doesn't want to perform identity check and it should let admin connect in.

That said in version 6.9 (as of Sep 25, 2018 in beta available for download) this system was totally replaced by a more modern certificate-based check. Now the process is automatic and doesn't require user intervention except only when there is certificate mismatch and the user is warned about it and asked for further actions. Here is a related documentation page for your reference.

By the way, in version 6.9 we also implemented two-factor authentication so if you want to add more security this is just what you need.

Hope that helps.

I recommend that you upgrade your Viewer, Server and at least one of the Hosts to the latest beta version (available here https://www.remoteutilities.com/download/beta.php ) and see if the issue persists with that Host. There has been a lot of changes made in terms of stability improvement in the latest beta version.

Hello Igor,

Could you tell us what the server version is by looking at the Admin Console window (Help -> About).

Thanks!

Hi Brian,

I responded via email, thanks.

Uploading your log files here is not recommended,  even though the logs don't contain any personally identifiable information.

Hi Greg,

Still, your font and spacing looks strange on this image. Perhaps, you have DPI settings other than the default? Or maybe some sort of scaling is enabled.

Hello Greg,

Thank you for your message.

Do you have any accessibility features enabled? Namely, the ones on the Ease of Access -> Display section of Windows settings.

Hello Carol,

Feel free to send us the Host log files at support@remote-utilities.com for examination. You can locate the logs in the Host installation folder

C:\Program Files (x86)\Remote Utilities - Host\Logs\