MaxBlitzer's community posts

Polina Krasnoborceva wrote:

Since I don't need any additional software to make direct RDP connections to local machines, my main interest is in connecting to remote machines not on my LAN.  I have read those documents multiple times thinking I must have missed some detail, but I don't think that is the case.  Choosing Direct connection over Internet-ID does not work because some machines cannot be found by their name, and their IP addresses can change fr om time to time.  Using Internet-ID seemed like the most desirable method, but again, the connection status in the Viewer seems to change every time I look at it.  It just keeps changing status, machines going offline and online again - unresponsive to launching a windows RDP session.  Some machines display notification that the host software needs to be upd ated, in spite of already updating them both via the console and the Viewer.  Viewer and Host installations are all beta2 version.  Server is installed on an AWS VM, which appears to work.

While I work on making Remote Utilities work properly, the best alternative I've found and am using with remarkable success, is L0gmein Hamachi VPN (not installed on same machine as Viewer) to machines on a trusted remote LAN, and simply connecting to them via RDP.  No tools, like screen recording and session notes, but it's super fast, spans multiple monitors, handles remote printing without need to install drivers or any additional configuration, and it rarely fails to connect.  The only thing I really want fr om RDP is shadowing so I can see the console with full control, together with the user, to troubleshoot issues.  So far, all of the information I've found after extensive searching appears to be obsolete for the most recent versions of windows 10 pro in 2020.  I have used various command line flags, group policies, registry edits, and none of them worked across the Hamachi VPN to another remote LAN.  RDP sessions with switches or without, the connection is a tcp session, not the console. So that was a lot of reading and testing to donate.  I've also put in a lot of time trying to make RU work as designed.

1. You can ONLY use Internet-ID feature as replacement for Hamachi in your case. Forget Direct Connection, forget RDP connection, especially if you want the person in front of the computer to see what you're doing on the screen instead of a login page like they would with RDP. Just right click on a host and "Full Control".

2. The status' won't be as reflective as they are in Hamachi, which was more real time and RUT is either delayed, or they only get certain information at time of the Viewer being opened, or after a connection to a host was made. If Internet-ID is se t for them, then the status for Online should be fairly correct aside from network issues.

3. I actually got onto RUT to switch away from using Hamachi for the occasional time Hamachi client screws up, plus the occasional Win Home machine without RDP, but unfortunately found I've had to keep both around as both services fail occasionally (RUT upgrades had some breaking issues a few times in previous years) and paying for each service costs less than a truck roll to fix it. Since in your case all of your clients have Pro/RDP capable, if RUT failed to connect on a random client, you'd still be able to remotely access another client at same location and RDP into it locally from there to fix RUT connection. In my case, I couldn't do that.  I think RUT upgrade issues are not really an issue anymore once they are on current versions, but upgrading from really old versions will have issues.

4. If you're only getting connections only 20% of the time using Internet-ID, you have network problems, or the computers are sleeping or rebooting (Win updates). Either way, I can say from experience, it's on your end. In the "IP Address" column in the viewer, when using Internet-ID, that will be the IP address of the RUT server your connection is relaying through.  Ping that IP in a cmd window and see if you're getting packet loss or if the pings are over 100ms.  If pings are over 100ms, you're going to want to setup a local RUT relay server yourself, or switch people over to using direct connections (you'll need access to their routers to make port forwards). Unless you setup direct connection, you'll never match the performance of using RDP and Hamachi. First, RDP uses less bandwidth and more performance than RUT, and second, Hamachi sets up direct connections between endpoints instead of using a relay.

I tried making the argument to RUT years ago for implementing direct peer to peer connections instead of the relay (and relay only used as fallback wh ere it can't arbitrate a direct connection between two peers), but for some reason they think their customers want their direct traffic to be relayed through RUT servers for security reasons. At that point, I setup a RUT server at the nearest datacenter and use that wh ere I don't have router access to setup RDP port forwards for direct connections. If you have a lot of machines all going through the Internet-ID (using RUT relay server), you'll experience a lot more network connectivity issues than you'll care for and you'll find it better to setup a RUT server on a fast, public Internet connected machine local to your users and you.

Thomas Inman wrote:

Same behavior as previous posters have noted.  I am using the trial version to connect to other machines on my LAN, as well as machines on a separate remote LAN (no VPN).  Using the latest version on all machines.

I can RDP into other machines on my LAN without using Remote Utilities, including one that is shown as 'offline' or 'logged on'.  To clarify, I am most interested in connecting to other machines via RDP using Remote Utilities, not the Full Control Option which is too laggy and has the same behavior of "connection lost".  I have tried using Direct Connect as well as Internet-ID Connection.  The results appear to be the same - cannot access remote machine.  From the Viewer, I am able to access 'Remote Settings', but still no remote access via Full Control or RDP, yet, I can access the machine in question using RDP without using Remote Utilities.

So, I'm at a loss to figure out what in the heck is going on.  Each day I open Remote Utilities and never know whether it is going to work or fail as it is now.  If this issue has a known solution, please post it somewhere.  I've searched the entire site and documentation and only found this one thread.  I hate to call Remote Utilities 'unreliable', but I can't think of any other way to describe it at this point during the trial period.  

I've read previous posts recommending users submit their log.  Is that what you need to figure out why this isn't working?

Thanks

PS. I should add that over the last few years, I have used  [censored] , Splashtop, Zoho Assist, and rarely if ever had any such problems connecting, which makes this issue with Remote Utilities that much more puzzling.

For the remote machines, my understanding is that you still need to setup port forwards for RDP if they are not on public IP's. They don't use RDP protocol over the RUT port. Afaik, the benefit is basically as an address book, but doesn't do NAT hole punching, so you still need to set up all that as if you weren't using RUT.

However, that should work on your LAN, and your hosts don't appear to show online, so that implies your hosts are not talking to RUT servers. Direct connections will always show offline (unless you're actively connected to it). But using the Internet ID and hosts are really online should show that.

So check the hosts are running RUT. If it is, the next issue could be a firewall blocking RUT connections.

You're not wrong that the online/offline status and version info is poorly implemented. I thought they said they were going to improve that, but their updates have slowed considerably in the last year or two compared to before, I think to work on Linux, Android and apple compatibility.

Conrad Sallian wrote:

Hello Max,

Thank you for your suggestion.

However, this specific "bug" was just something we overlooked on the building stage rather than a bug in the program itself (related to its functionality, that is). So we decided to keep it the same number.

Yeah, that is very bad practice. The build output from one version of the compiler and build system can vary with the same source code.  The building stage is essentially part of the "application" along with the source code. It should be tracked just as the same the code. Some companies have policies that even prevent the release system from ever generating different builds using the same release number to prevent this scenario.  Not only do you have your own code issues handling this issue internally, now you have two different "viewer6.12.b2.exe" files that you had posted for almost two weeks on the Internet.

No updated release date, no reference in the release notes about the correction. So the release notes loses credibility as being inaccurate when bugs were fixed and when new updates appear. Some people may not be willing to try a beta build to fix various bugs that was JUST released but think, "hey, it's been out two weeks, it's worth a try" but it's now actually only got ~1 day of public testing. Beta release notes should be verbose, more so than stable release notes, IMO.

On top of that, it received zero QA before it was posted for open beta testing. Now, it is expected to have MAJOR bugs in beta builds and the user accepts that. Happens to Microsoft ALL.THE.TIME. But they also have automated checks in place that (should) prevent showstopper bugs before they get into a public beta and quickly pull facepalm builds that fail even the most basic mandatory function.

Right now, my PC has two files names "viewer6.12.b2.exe" with different file sizes. One has a digital signature  signing date of May 13, and another one says May 18. The release date is May 6. The server's beta 2 has a signing time of May 5, which is what I'd expect with a May 6 release. But May 13 and May 18th? This implies that you didn't just have TWO different "viewer6.12.b2.exe" with different hashes, but (AT LEAST) THREE.  Can you comment on that?

Can you see how confusing this is by reusing release numbers and release dates? How do we know if the beta2 from May 6 was busted or if the May 13 stealth update introduced the epic fail? Like I mentioned before, this version reusing and non-release note update practice has lost so much credibility in beta testing for me.  I've always had my issues with your development style, but this one will be the one that takes the cake.

tl;dr I scream internally reading your response. I need to go take a chill pill now.

May 6 signed build: SHA-1: ???
May ??? signed build: SHA-1: ???
May 13 signed build:  SHA-1: 384B5BF7DB12D10EE637F0F317CDC8737F6F12DA
May 18 signed build: SHA-1: 5EB2C20CBB11C68EBBB40E0EDB5508D7D0CD8CCB

Polina Krasnoborceva wrote:

Hello Peter and Max,

Thank you for your feedback.

We've managed to reproduce the issue and implemented a quick fix for it. We apologize for the caused inconvenience.

An updated build of version 6.12 Beta 2 is available on  this page . Please try updating your Viewer and see if the issue persists.

Please let us know if you have more questions.

Polina,

The newest version updated and address books and registration worked.

But I would strongly suggest letting your developer know that they should increment the version string instead of re-releasing under same version.  That is just a no-no. We always had a saying, "numbers are free".

Peter Gray wrote:

Over the past couple of days I have tried using using version 6.12 Beta 2 Viewer.  It has not been a happy process!
Having installed the viewer on an XP pro machine which had version 6.1010.0 working fine, I found that my address book and so forth had not been carried over to the new version (and nor had my licence).  I turns out that 6.12 stores these settings in the user's application data in a folder Remote Manipulator Files whereas 6.10 uses Remote Utilities Files.
After copying the data across, I had the address book back, but a side effect was that the free trial period had expired.  On trying to install my licence code, I got a message "Attention Invalid registration key"  The key worked fine on a different machine which still had version 6.10.10.0.
So I uninstalled 6.12.  The uninstall progress window showed gibberish symbols instead of text!
I Reinstalled 6.10.10.0, and fortunately all was back to how it had been previously.
I then tried installing the beta on a Windows 7 machine which had not halready had the viewer installed.  This too would not accept the licence key.
So for me, version 6.12 beta 2 is completely unusable as it stands.

Went to upgrade from 6.12b1 to 6.12b2 and lost registration and address books as well. Went to put in registration and also got invalid registration key error. Uninstalled (I didn't have any gibberish) and reinstalled previous 6.12b1 to get registration and address books (address book sync still broken on this machine so I'm giving up on RUT now).

I thought that after nearly two weeks after the b2 was posted, this SHOWSTOPPER bug would have been found and the b2 pulled by now, so pretty annoyed to have run into it myself today.

Their documentation is actually really good. https://www.remoteutilities.com/support/docs/ru-server/

What are your issues with their current instructions that a video would help? It's quicker to just say, "when I get to step X, I don't know what to click" or whatever.

But I'm not sure if you understand the feature, since self-hosted server is just your own RELAY instead of RUT's public ones, and still doesn't "connect directly". For that, it's actually outside of RUT's scope so that will depend on your router and network connection, and that's WAY too broad to have a useful video. That needs some basic technical experience to configure direct connect (unless you have IPv6).

john Randal wrote:

Mine says the certificate is invalid

Check the time on your computer is correct. The problem is on your end. Or post a screenshot of what you're seeing.

Robert Ricketts wrote:

Conrad Sallian wrote:

Hi Robert,

The infrastructure was expanded just recently. It may take some time for the load to spread evenly across the servers. I recommend that you try in a few hours to see if there are still any issues and let us know.

Will do. Thanks again.

Next time you experience lag, use a program like mtr (winMtr, https://sourceforge.net/projects/winmtr/ ) to check the loss between you and the RUT relay server. After connecting to the host, grab the IP fr om the "IP address/DNS" column in the viewer and enter that into winmtr and click start.  That will tell you wh ere the bottleneck is actually happening.

A couple of years ago, I was really frustrated by the lag and RU said their servers were barely being utilized. This made sense because the problem wasn't their server itself, the problem was the connection to the datacenter their server was hosted in was bottle necked and dropping 80% packets. There are several connections into major data centers, so not everyone would experience this issue. So when RU checks the stats of their server, they'll see it running perfectly fine with lots of capacity available, but the issue is that they have zero insight into network issues outside of the server.  The client doesn't do any failover or checking to see which RU server is closer or anything complex like that.  RU setting up multiple remote ping monitors will help catch when this happens, but even when it does happen, that would just confirm outages and wouldn't do anything smart to route around the problem.

tl;dr If most of your clients are local, setting up a local relay server would make a huge difference. Also, if you have access to clients router and can configure port forwards, direct access is 10X better than using relay whether its yours or RU's server.

Polina Krasnoborceva wrote:

Hello Max,

Thank you for the provided details.

Could you please let us know if you have tried adjusting the touchpad settings or updating the mouse software on the Viewer's side?
Unfortunately, we cannot reproduce the issue which means that it only manifests itself in certain circumstances.

This is on a desktop PC to other Desktop PC's, no touchpad controls. Mouse is a Logitech M705. I'll let you know if I can reproduce on other PC's.

So then this pop up happens some time later

Could you please clarify if you mean the First connection warning  window? If this is the case, then we are considering the revamp of the First connection warning window along with some other features. However, unfortunately, we cannot provide any specific ETA on this yet.

Yes, that one. I will stop using this feature.

I'm checking the host version (because its not shown in the Viewer, for example)

Actually, it's also possible to check the Host version in the Viewer if you switch to the Details view style:

   
Yes, that is my preferred view I use all the time but a lot of the hosts have blank boxes or out of date. I'm in the process of migrating to a new computer and have my new and old PC side by side. They are using same synchronized address books. Some don't show the same versions for the same hosts. Some don't show any version for some hosts in one viewer and not the other. It's not a reliable place to confirm actual versions. Right now, my new PC has yellow exclamation marks next to 5/7 cloud address books and the old PC, also running viewer 6.12.1, has no yellow exclamation marks on any of the address books.

Install RUT using a silent installer made against 6.10.3. When I went to add the code in 6.12.1, it said I needed to use the same Viewer version as what was used to generate it! Jeepers, that is another strike against the silent installer feature. If I had installed the silent installer, got home and then got this message without an opportunity to manually se t a new password so I could manually add to the Viewer, I probably would just give up on RUT right then and there and move to another solution. Try and only break backwards compatibility on major versions, not on minor versions, I beg you!

I apologize for the inconvenience. We try to maintain as much backward compatibility as possible with each update because we understand that our customers might not be able to update remote Hosts all at once. Besides, we even advise updating remote Hosts in small increments and first test the update procedure on a small sample. There is backward compatibility, however, it's always better to upgrade both Viewer and Host and avoid relying on it.

As for the issue itself - could you please clarify if the issue occurred on another Viewer machine instead of the one where the installation package was configured? If this is the case, you simply need to copy the  keys.dat  file which is an  encryption key  to the Viewer machine where you want to use the  Add using code  feature. This file is located in the  C:\Users\user_name\AppData\Roaming\Remote Utilities Files\  folder on the computer where you originally configured the installation package.
Please try copying this file and pasting it to the same  C:\Users\user_name\AppData\Roaming\Remote Utilities Files\  folder on the Viewer PC where you want to use the  Add using code  feature.
Here's a related  KB article .

Looking forward to your reply.

Now that you mention this, I somewhat recall this limitation when making the silent installer - it's just been so long ago that I last generated it that I forgot. I knew to migrate relay server settings, but on the Viewer side I was only thinking of synchronized address books and that didn't need to be backed up/restored when migrating Viewer PC's.  And now that I know that was the issue, the message pretty much says that, and I just didn't clue in. doh. Only thing to add to that help page, was that after I pasted over the keys.dat file, I had to close and reopen the Viewer to get the Add Code box to appear again. It was appearing before I pasted the keys.dat file but wouldn't appear again until I restarted the Viewer. Then I could add the code.

Polina Krasnoborceva wrote:

Hello Max,

Thank you for your patience.

I checked with our developers on both issues:

1. Unfortunately, we could not reproduce the mouse pointer issue. Could you please confirm that you have both - Viewer and remote Host upd ated to the latest 6.12 beta version and the issue still persists in this case?
In addition, please try disabling the touchpad or altering its sensitivity in the Windows settings.
Also please double-check if the mouse software is upd ated to the latest version which might be downloaded fr om the manufacturer's website.

2. As for the time it takes to establish a connection to remote Host - the Authorization method se t to Auto does not affect it. Could you please check if it takes the same amount of time to establish a connection to a remote Host in case if our public Internet-ID server is used as an intermediary instead of the self-hosted RU Server?

Looking forward to your reply.

1. Can confirm this happens with Viewer 6.12.1 with hosts 6.10.10 and 6.12.1. Ran into this again today. I installed the 6.10.3 using the silent installer made last year. It failed to upgrade to 6.12.1 through advanced install. I upgraded it to 6.10.10 through simple install and then 6.12.1 through advanced install. A reboot might have been necessary for it to successfully upgrade to 6.12.1. Then I was trying to copy/paste username/password from my PC to the viewer session, getting the offset mouse problem EVERY TIME. It was really frustrating.

Generally, I'll install the silent installer on site when a new PC or new employee starts. The code gets emailed to me, but because there is no usable Android viewer that can take that code, I can't do a remote access and click on the pop up while I'm there in person.  So then this pop up happens some time later, after an upgrade, or when I'm checking the host version (because its not shown in the Viewer, for example). And then the pop up stays on the persons screen until they come in the next morning and freak the F out.

The silent installer is useful for ensuring the proper settings are consistently set and no typo's due to Internet ID's, passwords, IP's, etc. But the hard pop up that can't be moved and has a scary worded message makes that feature completely useless unless I'm setting up the computer at my home.

2. I would only have 1-2 hosts still left on public servers, but I won't login to them for fear of the stupid pop up message that blocks the right side taskbar until the user at the host clicks OK to warn the user someone is remote accessing their machine. I don't have a record of every time I've installed a host and took care of that. I can tell you at least 4 times wh ere this pop up has caused panic and alarm or just outright prevented me from doing maintenance due to blocking the taskbar.  I thought from previous feedback on how poorly users think of this feature that something was going to change in future versions... I think you guys are more working on linux and mac support than fixing the issues that have bugging me for a long time. *sigh*

One of these times I'll record the process of what it goes through compared to other services in terms of initial connection time.

New issue. Install RUT using a silent installer made against 6.10.3. When I went to add the code in 6.12.1, it said I needed to use the same Viewer version as what was used to generate it! Jeepers, that is another strike against the silent installer feature.  If I had installed the silent installer, got home and then got this message without an opportunity to manually se t a new password so I could manually add to the Viewer, I probably would just give up on RUT right then and there and move to another solution. Try and only break backwards compatibility on major versions, not on minor versions, I beg you!