MaxBlitzer's community posts

Still looking for improved version reporting. It's one of my biggest issues with RUT.

Upgraded 4 using remote install and the host .msi file, and 2 of them show the new version number and 2 don't (but did upgrade to .4).
Also, when I did them one at a time, they succeeded, but when I tried two at once, the first one failed authorization and the second one worked. Without changing any setting, tried remote upgrade again on the one that failed authorization and it upgraded.

Lastly, given the amount of time between beta releases, the 3 month license expiry seems short. You should think about 9 months at least.

Rob,

Just do the DNS name and setup a dynamic DNS hostname. You'll need to sync the registry and some RUT files between the servers. You won't need to change your address book at all.

DON'T do the MSI thing. When trying to using the Remote Install Tool for upgrading beta versions, it rarely, if ever worked. So I wouldn't suggest that especially when there is no point.

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.