Allen Pelusso wrote: Same for me too Adnroid ver 2.3.3 and open and black screen and go off few second after !
Let's wait till we update the mobile version with logging so that we could diagnose such issues.Meanwhile, please also check your device against the system requirements (information block on the right) and specifically if the device supports NEON.
Mind you I only tried ticking various buttons yesterday because neither host were working. I only changed settings in one of them though, which is lucky as the other one suddenly works fine today. So I presume there was a problem yesterday that magically fixed itself overnight [restarts of all machines and networks maybe?].
Yes, sometimes users accidentally enable or disable an option that affects remote connection and can even block it altogether.
Another logmein refugee here Starting with 3 hosts, but will be building to over 10 eventually. So glad logmein pushed me away, as Remote Utilities has so many more features I wanted.
Welcome to our refugee camp. Everyone gets a blanket and a bowl of hot soup. For free. :)
he connection only goes as far as Manual Log-on 'locked'. I presume this is because the host has windows accounts on it, but I don't understand how to enter any info that gets around that.
Locked sign here means that the remote computer is visible (say, you can ping it's IP address), but you are not logged on. By being "logged on" I mean logged on using the LogOn feature in Remote Utilities, not Windows logon.
As I could not connect via the various connection modes, I played around with RDP settings in the configure screen
RDP has nothing to do with Remote Utilities per se. It's just that we support RDP connection by launching a default client when the user wants to connect via RDP. Also, a feature called "RDP-over-ID" is also possible, when you connect using RDP via an "Internet ID tunnel" created by Remote Utilities.
To me this feels it should be the other way instead. Why would I need to check identity of the Host, I already connect to it with an IP or ID so I don't see the benefits of it (but I might miss something here).
This is to avoid situation when a different Host (patched by a hacker) is planted on a computer with the only purpose to find out your password when you try to connect to Host.
Instead if the Host would require the Viewer to know the shared secret, it would add an extra layer of security and I think that is the way what most people would expect it to work in.
That's what authorization is for. Authorization and identity check are two different things. Shared secret is not for making the connection more secure. It's for the Viewer to know that it is connecting to the Host it (the Viewer) thinks it is connecting to.
What is the recommended setup to make a connection as secure as possible? Is it a long password and only allow certain ip addresses then?
Long password and incoming IP filter (white list) is enough for good security. To ensure security on the Viewer side, never use the "save password" option.
How is the "shared secret" feature supposed to work? Right now I set it on a host but I can still connect to the host with only the password entered in the viewer machine. Using Internet ID to connect, Windows 8 host, Windows 8.1 viewer.
Any input please?
The purpose of shared secret is not to replace authorization. It's for checking the identity of the Host. That is, if you have shared secret enabled on your Host, but don't have it enabled in your Viewer (or rather a specific connection on your Viewer), you'll still be able to connect. But not the other way around - that is, if you have a shared secret field populated in your connection properties on the Viewer, but the Host has an empty field (or a different shared secret for that matter), you won't be able to connect.
So the identity check starts at the Viewer side. If the shared secret field in the connection properties in the Viewer is disabled, then no identity check takes place at all, regardless of the Host's shared secret field value. Because the program rightfully suggests that if you didn't enter anything in the connection properties shared secret field, you do not need identity check, and hence there's no reason for not allowing remote connection. But IF there is at least any value in the shared secret field in the connection properties in the Viewer, then the program MUST check it against Host's shared secret value.
L B wrote: I cannot find a way to add a recognizable to the systems in the iOS app. All i can get is a list of Internet ID's. i will never know what system I'm connecting to without creating my own checklist of system names/Internet ID. the Viewer has the ability to record recognizable system names to each host computer. Need this in the iOS app too.
Yes, we plan to make the "address book" on Viewer mobile more feature-rich and powerful. We'll add names in one of the future updates.
Jamie Ward wrote: The ability to select a certain monitor in dual screen setups doesn't always work for whatever reason. I haven't been able to pin it down as of yet. Sometimes clicking the monitor selection button in the toolbar gives you a choice, sometimes it doesn't.
This happens on two of the machines that I control remotely as well as locally (within the LAN).
Any advice to make this function correctly and troubleshoot?
Couple of questions:
1. Is that behavior seen when you connect via Internet ID only, via an IP address or both?
2. In what time after the connection has been established you try to switch monitors? Immediately or in a certain time passed (say a minute or two)?