Pepa Kokes's community posts

If I disable screen blanking, the colors are back to normal. Can the feature be fixed so that it supports blanking while keeping the colors?

Screenshots sent. Note that before I installed beta, both directions looked the same, after discounting different screen sizes, of course.

I did just try to upgrade from Host version 6.10.10 to 6.12 beta 2. Everything went far in that I can still connect fine and remote control works, but for some reason the image quality went way down: It seems that the screen from a 6.12 host is only sent in 256 colors rather than whatever is set in the connection properties (65536 by default on my setup, but as far as I can tell, that setting has no effect now). It seems that the fault lies with the Host (installable) rather than the viewer, because the 6.12 viewer displays fine when connected to 6.10.10, but once I upgrade the host to 6.12, I only get 256 colors.

I would like to add that even though Remote Utilities themselves take care of security, I still like to add another layer using an encrypted tunnel to route the RU traffic through. While this approach takes more setup time and more CPU power (double encryption), it does have distinct advantages:

1) More control over the actual encryption process. RU now uses TLS, but there isn't really much information on how exactly it is done. Every TLS version, including 1.3, can be used in an insecure manner. For example, all it takes to pretty much break the TLS security is to incorrectly implement certificate verification or the reaction to certificate verification messages of the used SSL library. Using a tunnel, I can control this very well, even add features not available in RU (e.g. a smart card may be required to perform the connection).

2) More control over the communication. Specifically, using a tunnel in conjunction with a firewall I can *enforce* that RU does not talk to anyone else than the intended target - all RU communication except for to/from the tunnel is automatically disabled. The documentation says that in a direct communication this is always the case, but with a tunnel+firewall, I can be sure - even taking into account possible errors in the implementation of RU.

When a Remote Utilities Full Control connection to a computer ends, the computer gets locked. That's as it should be. However, I am encountering an undesirable locking behavior in conjunction with short disconnects:

1) Viewer connects to a Host in Full Control mode and controls the computer for a while.
2) A momentary disconnect occurs.
3) Viewer tries to reconnect in five seconds and succeeds.
4) Viewer can still control the computer for a while.
5) After a short while, the computer gets locked.

This is definitely incorrect. I suspect it is caused by the fact that disconnections can't get detected other than by missing a timeout and when that occurs, the Host doesn't care whether a connection is still available and simply locks the workstation. Unfortunately, it means that a computer may remain unlocked for some time and that someone can connect to a computer and work with it without unlocking. I think these fixes should be considered:

1) Decrease the timeout for "connection lost" on the Host. It might be a good idea to make it user-configurable.

2) Do not lock workstation on "connection lost" if another connection is active.

3) A Host configuration option to *also* lock the workstation on each Viewer connect. Default: Not active.

4) A Host configuration option to mitigate #3 in such a way that if the same host (identified by e.g. a nonce sent by the Host to the Viewer during the previous successful connection) reconnects without being properly disconnected while the workstation is not locked, #3 will be skipped for this Host. Default: Active.

You can use junctions to move the logs directory somewhere else. This solution works fine for me.

RU works fine for me with TEMP directories on a ramdisk (created using ImDisk, just like yours).

Your error relates to a problem in Windows 10 v1809 (I think) or newer which I encountered myself - some fault in the Installer service prevents access to the actual MSI file extracted from the original EXE. It's not limited to RU, either - every MSI-saved-to-EXE I tried has it, too. You can get around the problem by getting the MSI file and running "msiexec /i file.msi" as admin; you can either get the MSI version directly, or you can run the executable, have it fail due to the error, but before you close it, copy the MSI file from the TEMP directory.

With Legacy capture the initial redraw is noticeably faster. I am keeping it enabled for now.

I will try. If I can make it, fine. If not, it's good enough that the problem is limited to my computer only.

I already did, but did not observe any change. Note, though, that I did it remotely and wasn't able to restart RU, so I expect the change did not take effect yet. I will restart the computer tomorrow and then test how it behaves.