Unfortunately, this is not the first time Windows Defender marks our software not only as mere riskware, but as a serious threat, like a trojan. This happened in the past. It is all the more strange to see that it's the Viewer that is marked as malware. Viewer cannot "give" remove access by definition, it's a client not a server (as in "client-server" architecture).
We do our best to report false positive detections though.
I had considered setting up my own Remote Utilities relay host to see if that would help, but have just been too busy. It could be a connectivity issue between Utah and where ever the Remote Utilities server is hosted.
Apart from using your self-hosted server please also try the latest beta 184.108.40.206. This from release notes:
The remote screen transfer speed of dynamically changing content (e.g. videos) over slow connections has been increased.
This is not only about slow connections, of course. The very screen capture algorithm in the beta was improved as compared with the current stable version (220.127.116.11).
This has never been an ID problem. It's a network problem, in most cases caused by packet loss in the network itself or at ISP or issues with gateway hardware. There are many possible reasons.
What I recommend though is that you try installing the latest beta version https://www.remoteutilities.com/download/beta.php . In this version we implemented some fixes that can help smooth out small network issues and make the overall performance better.
If you install the Beta, make sure that you do that on both ends, Viewer and Host, not just the Viewer or the Host.
You are correct, it goes back to the prefilled simple password instead of going back to the one time password. It's confusing because the simple password is saved with the address and it doesn't prompt for it initially because of that, but then it goes to it if the one time password is wrong or close to expiration.
Yes, this makes sense. We are currently considering this issue and how to better address it in the next beta.
One more thing I've found: If you remotely update, and include a new password in the msi, and the previous version is 18.104.22.168, you cannot login because the old settings are still on the client.
Sure, we will test that and see how we can fix it. Thanks!
Unfortunately, it looks like a general issue which may or may not be connected with Remote Utilities. I can only recommend that you add Remote Utilities Host installation folder (C:\Program Files(x86)\Remote Utilities - Host\ to antivirus software exception/white list and see if the problem persists.
f I put a wrong one-time password in, it says the password is wrong, and then it goes to the simple password entry box, so it you then type in the correct one-time password, you are actually changing the simple password.
Sorry, could you please elaborate on this. You cannot change the single password from the Viewer side, you can only change it on the Host side, in Host authorization settings.
When you enter a wrong one-time password you are returned to the single-password prompt window. There you need to click OK again (your single password remains pre-filled) to invoke the one-time password prompt window.
I assume that you are entering the one-time password in the single-password dialog and that makes it all confusing. I can agree that perhaps this specific interface routine needs some reconsideration. I will immediately forward it to our development.
When I create an MSI and tell it to auto-generate an ID and use the custom server, it seems that when the MSI is ran, it grabs a default/public server ID. The ID on the client does not show on my ru server. If I go to the ID on the client and tell it to generate a new ID, then the new ID shows up on my server.
1. Do you use online or legacy option? 2. What is the type of installer that you choose (standard, one click or agent)? 3. Could you please send us the Host log? Feel free to send it to firstname.lastname@example.org as an attachment. This issue might also mean that the Host simply doesn't connect the first time for some reason, the log should reflect that.
The reason why you cannot see the entire Win7 screen on your WinXP monitor is that probably the resolution on the Win7 machine is higher than that on WinXP machine/monitor.
There are basically two ways to resolve this issue:
1. Switch from normal view mode to stretch view mode. The Win7 image will shrink and fit your WinXP monitor. The downside of this method is that scaling will occur and the objects on the screen will look tinier than on the Win 7 monitor or when normal view mode is enabled during remote session. You can change the View mode in connection properties in Viewer.
2. Change the very resolution on the Win7 machine to equal the resolution on the WinXP machine. Unfortunately, Remote Utilities cannot automatically change the resolution for you during a session so this should be done manually by right clicking on the remote screen and selecting Display Settings item in the standard Windows right-click menu. This method will let you see the remote screen "pixel for pixel" on your WinXP screen without resorting to the stretch option. The downside is that you should do that manually and probably also set the resolution back to its original value once the remote session is over.
You must click on the "Change password" button to enable the edit mode for these fields. By the way, in version 22.214.171.124 (currently in beta) we changed the Host settings interface and made a single and more streamlined settings window.