Another important feature that was added to beta 2. Quoted from release notes:
You can now remotely restart the Agent as administrator (provided you know the credentials) in order to perform the necessary tasks during a remote session, such as installing programs and interacting with UAC prompts.
This feature has been long awaited by many. Feel free to test it out and let us know if it works for you as expected.
Windows Defender detects Adware.W32/Unwaders.C!ml in rutview.exe of the new beta.
What's up with that? False positive I assume?
Yes, absolutely. It is a false positive. We will contact Microsoft immediately and file a false positive report.
To their credit I should say that of all antivirus software vendors Microsoft is the fastest in responding and eliminating false positive detections. Besides, they have a very friendly and well-though false positive report interface. We encourage everyone having the same problems with RU files to report a false positive at this link https://www.microsoft.com/en-us/wdsi/filesubmission
Beta 2 has been released. See release notes. The most importation addition was the "PIN" function that let's you protect your self-hosted server's Internet-ID "tunnel" from unauthorized use. Although this hasn't been a security vulnerability in any way, such use was still a nuisance (because of unknown Hosts hanging in the server connections list) and now it has been fixed.
Later today or tomorrow we will publish a blog post that will explain in detail how the new features work.
TBH, I would rather not break my current viewer settings :-). If you can confirm that the contents of "%APPDATA%\Remote Utilities Files" folder is all that I need to recover, I will try tomorrow (time permitting).
You really won't break anything if you just delete one of your callback connections. And yes, the Viewer keeps all its settings and data in that %appdata% folder.
However, I think network issues are highly unlikely here, at least in the sense you probably mean them - I am using a set of direct connections over an SSL tunnel, and the tunnel has been tested and retested multiple times and is working perfectly. Plus, if it *was* a network problem, the host's callback connections window should not display "connected"...
A network problem does not necessarily mean that the tunnel is bad or low performing. Perhaps the 'problem' is an incorrect word chosen. It could be a specific security setting for instance or anything else , either on the PC or the router that would affect how a specific application uses the network. There are hundreds of hardware and software manufactures after all.
In fact, I am completely baffled by the need of the hosts to actually provide *any* callback port. Obviously, the hosts are connecting to the viewer, but they are only connecting to one specific IP address and one specific port.
When you use callback connection it's the Viewer that is listening and the Host that initiates a connection, not vice versa. The Host should know the Viewer's listening port in order to be able to connect (along with Viewer's IP address , of course).
They don't have any need for a local port setting, as any traffic should go over the connection they initiated.
In order for something to go over a connection, a connection must be initiated first. That is the point.
Could you try to disable/delete the first connection and see if the second connection will start working immediately. I'm not sure this is the case. That is - the problem is not that one connection is getting in the way of another, the problem is most likely that there are some other connectivity (network) issues.