As for upgrading to a newer version, it is not mandatory. Any customer can stay with version 6 if they are not happy with version 7. Even if they upgrade their key to version 7, their version 6 key still works, i.e. they can even roll back to that version if needed.
I would suggest in the future, not to deprecate the "Simple Update" feature then. Since v7 got released, doing a simple update prompts that a new viewer is available. If you sel ect yes, you're forced to install v7. If you select no, it doesn't proceed with simple update and the feature is therefore deprecated. Work around is to use the Remote Install feature, though that takes longer with more clicks. Not the end of the world.
We'll keep to a more frequent release schedule fr om now on.
Anywhere I can find a roadmap or plan of what features you have prioritized next?
We didn't intend to trick anyone. Beta version is, well, beta version. It can be any number. And initially we indeed wanted to make it another minor release. But then it were a lot of quite serious improvements so it could easily become version 7. That said, there is 7 years span between version 6 and 7 - unlike our competitors we do not release a major each and every year whether it's justified or not. Otherwise there would already be version 14 :)
Well, you did. You went through several beta cycles under the 6.x version which gave me hope for getting improvements and fixes. You're pretty much alone in thinking that version scheme is meaningless and trivial. Other companies would have just been clear from the start and called it a v7 beta.
Unfortunately, none of the new features interest me as much as just resolving a few issues that have been there for a while. Given they were not resolved in the last beta and I don't know what you've improved since then nor do I have the time or systems set aside to devote any time to QAing it, so... I was drawn to RUT years ago because of the perpetual license, but this specific event has caused me to switch to a subscription based service.
If you're thinking its a good thing there was 7 years span, I disagree. Not if it means nearly 2 years between supported stable builds instead of frequent updates. I'm burned out now on RUT, I don't have any expectation of bug resolutions that is satisfactory to me.
Having major releases every 1-3 years would be better from a financial point of view, as well ensuring you're properly road mapping your development instead of dropping new "major" releases like this.
Further, when someone inquired about getting a new beta update before March 1 expiry, this critical fact was neglected and downright misleading: "Yes, the final release will be made before the end of this month.
And we made the final release before the end of this month, just as we promised.
No, you're mistaken. You're "final release" was 6.10.10 in 2019. The "new" release was Feb 25, 2021.
As for paid upgrade - our upgrade policy has always been very precise on this point. We exactly follow this policy.
Yes, and those are usually helpful, when releases are more frequent than 1.5 years. Acronis puts out a new release each year (whether or not they need to). They're growing and offer both perpetual and subscription. They put out several releases a year, including updating previous versions 1-2 more times after the new release is out. When "major" updates occur regularly at 1 year intervals, it helps the product stay on the tracks and get back focus if they strayed too far one version from what their customers want.
This is really disappointing. I really wish you called your 6.12 beta version 7.x instead of tricking us into thinking it was another 6.12 release. I wouldn't have bothered testing the betas if I knew this to to be the case. Further, when someone inquired about getting a new beta update before March 1 expiry, this critical fact was neglected and downright misleading: "Yes, the final release will be made before the end of this month."
I just installed the RU Server 3.0 and then realized with the version bump to v7, I would need to pay for an upgrade. So now I'm stuck on a mix of 6.10.x's, beta 6.12's and a RU server running 3.0 I need to downgrade to 2.7 release. I really hope it doesn't bork the address books or settings.
So what is the last official 6.x release that I can still run? The 6.10.10 that is ancient and buggy that is almost 2 years old? I don't even know if there was a minor update put out after the last time I upgraded my license in May 2019. Can you update the page above to include them, please?
You need to stop using the Internet if you're going to make nonsensical complaints like this. Use your head next time.
The user installed this at the request of the fake technician. The user is stupid and needs to be educated, not take away all the tools. The same thing can be done with 100 legitimate purpose software, this isn't specific to Remote Utilities.
Do you request kitchens stop using knives because criminals can stab people?
Seriously, you don't understand this is a user problem, not a software problem.
Before the next beta, please change the default option for: Remote install->Connection type to "Remote utilities security".
I only use single passwords. And when testing betas, you prompt for each login credential rather than the saved single password when the default "Windows security" is selected. This doesn't make much sense for me, especially if upgrading 1+, not sure about other users. I suspect not.
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.
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.
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?
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.
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