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.
Conrad Sallian wrote:
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.
Anywhere I can find a roadmap or plan of what features you have prioritized next?
We'll keep to a more frequent release schedule fr om now on.
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.
Conrad Sallian wrote:
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 :)
And we made the final release before the end of this month, just as we promised.
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.
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.
As for paid upgrade - our upgrade policy has always been very precise on this point. We exactly follow this policy.
We'll fix that page now leaving only version 220.127.116.11 avialble for download. Yes, the last minor update of version 6 is 18.104.22.168. And the server is 22.214.171.124.
You need to stop using the Internet if you're going to make nonsensical complaints like this. Use your head next time.
Clodomiro Berzelius wrote:
This is not good enough. You NEED to make your program safer, or you deserve to be shamed all over the internet, or marked as a malware forever. Your program is IDEAL for scammers.
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".
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.
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.
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?
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.
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.
Conrad Sallian wrote:
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.