Thank you for your report. It has been forwarded to our engineers for testing and examination. Since we cannot exactly reproduce your environment here, perhaps your help would be needed for us to diagnose the cause of the issue. I'll get back to you soon with clarifying questions.
Is there any specific reason that the remote screen response is significantly slower with Windows 10. I was hoping that the Beta would help improve the response time. It is particularily noticeable on any type of Win10 "system" screen/dialogs such as the login or lock screens. For example, It fairly consistently takes 20-30 seconds for the lock screen to respond to a mouse click or enter key. Once your in an application( e.g. MSWord) it seems to get better, but response is still a little more laggy than Win7 was. We're seeing this on multiple hosts and clients, even when accessing on fullspeed cable internet. We're running via internet-id using the free id server. We've already hit the common spots by dropping the color depth to 8 bits, and turning off Aero, and removing wallpaper. Its almost like Win10 does some type of "mode switch" when display system dialogs that causes huge delay.. Anyone else seeing this type of performance anomally or have further suggestions?
Could you try to enable "Use legacy capture mode" in the Host settings (Settings for Host -> Options) on one of the Hosts, and see if there is any difference with other Hosts, preferably its peers on the same network.
The server stores it's data files in the installation folder C:\Program Files\Remote Utilities - Server\ .
Service configuration settings are stored in this registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities\MiniInternetId
Administrator Console settings are stored here: HKEY_CURRENT_USER\SOFTWARE\Usoris\Remote Utilities\MiniInternetId
One question though. Is the server machine at the new location supposed to have the same DNS name (or IP address) as your current server? Remember that the Hosts you have already deployed as well as the properties of respective connection entries in your Viewer address book/books contain the address (IP or DNS) of your old server machine. If you migrate your server and change its address/DNS name the Hosts and Viewers won't be able to use the new server.
While migration does not happen very often according to our customer feedback and reports, In subsequent updates we'll still provide an easier way to migrate. Namely, we'll put all data and settings into a single folder or a file that you'll just need to copy to the new location to transfer your data. Still, the IP/DNS issue remains.
By the way, a possible migration is the reason why we recommend that you use a DNS name over IP address for the server. Pointing your DNS name at a new IP address is a simple task, whereas assigning the IP address of the old server to the new one may not be possible.
We will give it a careful thought. Thank you for your suggestions. As for our nearest plans - there definitely should be Mac support - at least for the Viewer - and a decent mobile client for iOS/Android instead of the current pretty basic one.
Ashley, update on this issue. After some examination we figured that both issues you encountered were bugs. Firstly, you needn't delete the folder RUT-Agent each time, the program should do it for you automatically. Secondly, the Internet ID settings that also include the address of your custom server don't apply as they should. These settings are stored in the registry, that's why just deleting the RUT-Agent folder didn't help.
We will fix these bugs in beta 3 and the final release. Meanwhile, in order to absolutely "reset" your PC's "Agent contamination status" to zero, please do the following:
1. Delete the above mentioned RUT-Agent folder in %APP DATA% Roaming before you run a new Agent.