I'm having a problem very similar to that described here.
However I already have the latest server 184.108.40.206. Viewer 220.127.116.11 and host 18.104.22.168.
Host has auth modes single password and CSS enabled. I can connect using single pwd, but when trying to connect using CSS I get "Custom Server Security Authorization Error".
Host logs sometimes show error 35 127.0.0.1 Password is incorrect or error occurs. Whether this actually appears in the host log seems inconsistent.
I can connect to the RU server from the host settings "Users and access control" button - it connects and all the users and groups are visible. I've tried assigning permission to my user directly and via group membership.
I can connect from the same viewer to other hosts on my LAN using CSS. The host that doesn't work is remote and I'm connecting over the internet using the RU server as the internet ID relay server as well as the auth server.
I've tested network connectivity from the host to the RU server using powershell test-networkconnection and verified the IP and port being used are working.
Thank you for your message and the provided log files.
Could you please try updating your current Remote Utilities installation to the most recent 6.12 Beta 2 version for Host and Viewer and 2.9 Beta 2 for RU Server and see if the issue persists after the update? We have implemented a few improvements and bug fixes, namely, we fixed some issues that could make RU Server freeze during custom server security authorization, so the issue you're currently encountering might be already fixed in the Beta version. For the full list of release notes please see this page.
Version 6.12 Beta 2 for Viewer and Host and version 2.9 Beta 2 for the RU Server are available for the download on this page. When updating Remote Utilities, please make sure to update both Viewer and Host (as well as the RU Server) in order to avoid version mismatch that might cause performance issues or some features not working. If needed, before updating your current installations, you can try using Portable Viewer and Agent.
Please let us know if the issue persists after updating Remote Utilities.
I've upgraded the server to 22.214.171.124 and tried with the original viewer and host - same result. I've run the portable viewer beta version - still same result. As the host concerned is remote and belongs to a client, I don't feel able to "risk" running the beta host, even as the standalone host. I might end up losing access to the machine altogether and I cannot access it physically to resolve if that occurs.
It sounds like the fix was in the server and should hopefully have resolved my CSS auth problem even with older host / view although I note the preference to run consistent versions end-to-end.
I think for the time being we'll need to stick with single password auth and use the server mainly for internet ID - it does seem much faster than using the public/default servers. Single pwd seems reliable compared with CSS.
We'll keep testing on this basis - unless you have any further suggestions.
Could you please also clarify what authentication method is set for the remote Host in the Connection properties -> Authentication tab? If it's set to Auto, please try changing it to Custom server security and vise versa and see if it makes any difference.
Meanwhile, I've forwarded the issue to our development department and asked for their input on this.
I've checked with our developers on the issue - it seems like the issue might be caused by some incorrect settings on the Host side. Could you please provide us screenshots of the Hosts settings, namely the Authentication tab -> Custom Server Security ->Servers window and the Users and access control window like on the screenshot below?
You can send the screenshot to email@example.com if it's more convenient.
I had already tried both Auto and CSS as the auth method for the connection in the viewer - both give the same result.
Screen shots from the host below (with a little obfuscation). However as I can log into the server and load up the list of users / groups, doesn't this prove conclusively that the server address configured in the host is correct. The server is deliberately running on non-standard port 5654.
It seems that we have managed to reproduce the issue. In order to further isolate the issue, could you please also try adding permissions in the Address Book manager for a user explicitly, i.e. not for a group but a separate user and see if you're able to connect to a remote Host using CSS this way?
Hi I had tried that. But to be sure, I've tried again: From the Host / "User and Access Control" I've explicitly added my user name with full permissions (as well as the group I'm a member of). Trying to connect still fails in the same manner.
Sorry for my somewhat misleading previous reply. We have thoroughly tested this again and couldn't reproduce the issue. Could you please provide us the following information for further examination?
Open the Windows Registry Editor (Win+R -> regedit) and export the following registry keys: 1. HKEY_LOCAL_MACHINE\SOFTWARE\Usoris\Remote Utilities Host\ registry key that contains the Host settings 2. HKEY_CURRENT_USER\SOFTWARE\Usoris\Remote Utilities\MiniInternetId registry key that contains RU Server's Admin Console settings
Zip these registry keys and send them to us to firstname.lastname@example.org. We will examine the files and see if they can give us a clue on what might be causing the issue.
Thanks, Polina, for the follow up, but we had already reinstalled the offending host in single-password only mode, and rolled out the same MSI to some 15 other hosts. So too late to harvest the registry keys.
We'll stick with single pwd for now as it seems to be working reliably, can't really afford to sink more time into it at present.