MaxBlitzer's community posts

snk-nick wrote:

Are there any release notes for these new versions?

Yea, right next to the download links.

Polina Krasnoborceva wrote:

Hello,

Thank you for your message.

We just released a new version of Remote Utilities where we implemented some fixes to our servers. Please, try updating Host, Viewer and RU Server to the most recent version (2.10.8.0 for Host and Viewer and 2.7.8.0 for RU Server) and see if this resolves the issue. You can download it on this page:  https://www.remoteutilities.com/download/

When you update Remote Utilities, please make sure that Viewer and Host/Agent are the same versions. Please note, that version mismatch between Viewer and Host/Agent may lead to performance issues and some features not working.

Hope that helps.

Hoping this helps with the constant pop ups for clients when Viewer is open.

The downloads has version 2.7.9.0.

Is there a way to do the server upgrade without requiring a reboot? Even selecting the option in the setup to close the open applications and restart them after still said I needed to reboot after the update was done. That's one of the worst part of Windows machines, the need to reboot and how long it takes to reboot.

Thanks

Michael Jenkins wrote:

Polina Krasnoborceva wrote:

Hello Michael,

Thank you for your message.

I recommend that you upd ate to the latest version of Remote Utilities and then see if the issue persists.
The latest version is 6.10.5.0 and it's available for download   here  .

If the issue persists even after you updated the program, feel free to send us the log files for examination. Here is how to locate the logs:   https://www.remoteutilities.com/support/docs/logging/  

Hope that helps.

I did the upgrade to 6.10.5.0 and have seen no change in the behavior. There certainly seem to be enough people having this issue that it isn't a fluke. There must be some systemic problem going on.

-Michael

Michael,

I've experienced lag and the occasional disconnect issues as well in the past.  Now, I use Internet ID only for initial setup before I can make router port forward/firewall for direct connection to the clients. Now I never see disconnects or lag (12-18ms ping). Hoping to sort out an address book issue and go to my own closer RU relay server (in seattle) to help with sites I don't have router access and avoid their servers altogether.

I'm on the west coast of Canada. I get a better ping to their server in LA (46ms) than their servers in Montreal (84ms), but more often I would get relayed through the Montreal server. Even during problem periods. Right now, for two hosts in the same office, one is on LA and one on Montreal.  There is no special optimization or server selection (or very basic), failover or anything like that in the RUT host.

When I was having very frequent problems some months back, I started pinging the IP shown for "Last IP" in the viewer for their server IP, and I could see very high ping times or drops that correlated with my disconnects and lag. So I ran some tracerts to find out where the loss was happening, and it was happening just outside of the datacenter in Montreal, not the DC or server itself. In such a case, their servers will report very light load server usage and not really highlight a problem for RUT's IT guys (ie, looking for overloaded or down servers). I do not know if they use monitoring services fr om multiple locations, but that would be a good idea.  There's going to be several routes into a major datacenter, but traffic wasn't being routed around the damage. Visitors that relayed through that server that didn't go through the damaged path likely wouldn't have experienced any issue.

The secret ingredient to having reliable, fast connections through a relay server is having servers really close. So on another service that you might not have experienced disconnects, they likely had a much, much higher server presence with servers closer to you (Beam screwer is 33ms fr om me right now). The other ingredient is for the ID to only be used for setting up the connections through NAT routers but letting the two endpoints directly communicate after the tunnel is se t up. RUT have already said they don't plan on implementing this (they will HAVE to change their minds when IPv6 becomes prevalent or else they won't be able to compete with performance of competitors. Heck, even more people having high speed internet connections puts more bandwidth costs on them, especially with a generous free tier...), so my advice for you if you plan on using RUT on more than a few hosts or use it often:

1. Get a Windows VPS from a major datacenter near your location to use as the relay server (I wished they had a linux RU server as those linux VPS' are easy to get for under $30 annually but a Windows VPS is 2-3X that). If they had linux RU server build, RUT could probably make some money by having turnkey private RU servers ready to go if they hosted with a major VPS provider like linode, vultr, digital ocean, etc.  Many VPN companies offer this with a decent markup that helps them fund their business.  Not to mention having better uptime on linux than windows servers for many reasons.

2. Setup direct connections wh ere possible

I would be curious to know what your ping times are to the RUT servers from your location. Run a continuous ping next time you experience issues and see if there is correlation. Then tracert to the IP and see wh ere the problem is happening.

Rob Barrett wrote:

In the image I provided, I am trying to right click on something in the system tray but I am NOT able to

Hey Rob,

I was thinking about this some more today.  Maybe this might be a workaround.  Try and move the taskbar from the classic location on the bottom to the top, left or right vertically. It'll suck and be awkward, but might get the job done. Make sure to unlock the taskbar first.

I also forget whether rebooting the computer worked to remove it from the desktop or not. You can try that, too.

It won't go away until it is clicked by the person at the computer screen, not from the viewer connection. For me, it lost usability unless I install it when I'm onsite, login to my home machine and then login and click the box myself. So it saves me a few clicks, but I've stopped using it after they introduced this feature.

Back on the older versions, I could just email a link to download it from my site. The user would install it sometime during their day and I could just login overnight and work on the problem. But the way the message is worded, they make it sound like the app is not intended for remote access but it may be used without your knowledge.  It would actually be outright better to say, "This software is used to remotely access your computer."  They could even add in a line like, "If this has been installed without your permission, you may uninstall it from Control Panel|Programs and Features"... or "Download the mobile client for iOS/Android here".

It requires elevated permissions to install, so I think its counter productive and not going to accomplish their goal of preventing malicious installs. If you already have admin rights, the app can be installed manually or with other apps like autohotkey answering automatically. I'm really hoping they change their minds on this, or at least remove it for any paid license, not just Pro and Site.

Rob,

I agree, unfortunately, that is a feature available only to their highest license package.

It's caused me nothing by grief a few times. Not to mention that this "feature" blocks the taskbar, so you're often prevented from fixing whatever problem you needed to fix remotely in the first place.

If they removed this limitation on lower licenses, I'd bet they'd sell more licenses.

Conrad wrote:

Hello Max,

Just as I was writing this answer Microsoft informed us that they removed the detection and that one should update their definition files.

I perfectly understand what you say and agree completely. Unfortunately, there is little we can do because the antivirus software industry is in dismal state. How else can we characterize them if they cannot even distinguish a digitally signed file from an unsigned trojan-loaded one?

Just think about it - a file signed with an EV Code Signing Certificate coming from a legit developer gets detected as a trojan :) Well, of course not all a/v software is that bad though, but some are.

And there is this VirusTotal, which is another sad story. For almost three years we have been trying to convince them that not all antivirus software are created equal and that they should take a closer look at the quality of the a/v engines they use. Yet, they keep presenting their scan results alphabetically and in red type (even the relatively benign detections). So the never-responding-to-false-positive-requests Chinese antivirus by the name "AntiyAVL" (without VirusTotal you wouldn't even know that it exists) always gets at the top of the list with their bold red warning that Remote Utilities is unsafe :)

Was the Microsoft response an automated one (I'm sure) or possibly a human? Could you ask them about what impact an EV signed certificate does on AV scans? Because I don't see that as an automatic whitelist for AV vendors, just an additional safety check that the .exe you have is from the people you expected it from before executing it (ie, from Microsoft, not Micros0ft). If it was an automatic whitelist, then the cost to mass malware infections would be very cheap. Legit developers signed certs get stolen all the time and we find out days, weeks or months later something malicious got slipped in without someone knowing. An AV vendor that trusted a file on EV alone would be swiss cheese and not something people would really want to install.

But yeah, the big 6-10 vendors that will be installed by your customer base is main priority. I know from reading bleepingcomputer forums over the years, people tend to ignore the really obscure VirusTotal AV engines, but if one or more of the main vendors detects something, there is probably something to it.

Contacted by user today after their viewer got removed by Windows Defender. Didn't know why it happened, and told her to download the 6.9 and of course, "a window popped up saying “viewer6.9.msi contained a virus and was deleted” so the download didn’t complete."

Since this is the second time this happened for this user in just a few months, with the loss of productivity after this happens, I'm anticipating the conversation about switching to something else. Telling people to temporarily disable their antivirus is not a solution that works more than once.

I cannot think of any software I use that has this level of problems with AV software, so it sticks out as an outlier. I understand the predicament you are in, it's especially harder as you're in an industry where AV vendors have to distinguish between malicious RATs and intentional RATs, but it is a problem that is mainly yours to make any improvement if there are false positives.

So what can be done about this situation?

First thought, was that the signatures should automatically be made available to the Virus Total AV vendors before officially releasing the final builds and have a high or 100% vendor update confirmation. At the very least, the main ones, like Defender, Kaspersky, McAfee, ESET, etc. I think people can look at a Virus Total and ignore false detections when the main ones don't flag it and only the super obscure ones do. I know you can submit false positives to each vendor, not sure if you can pre-submit to prevent false positives. I assume so.

But yeah, getting on Defender blocklist is bad. Anything and everything to prevent this proactively in the future should be done.

You need to go and manually remove remote utilities from registry. I've had to do that on a couple of boxes that refused uninstall and reinstall.  One instance was definitely some conflict with Intel security software. I think an OS upgrade can also result in broken installs due to installing in wrong registry location many versions back.

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.

The Viewer knows the version of itself. The Viewer knows the version of the host. Very easy to pop up and alert user to the documentation about needing to upgrade Viewer first and that they are not compatible.

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.

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.

You might want to make that clear on the Beta release notes page that 6.8.0.1 viewers can't talk to the 6.9.1.0 hosts.

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.