Pepa Kokes's community posts

I can confirm I have the same issue on initial redraw. I don't think it came with 6.10.9, I faintly recall being annoyed by this behavior even with older versions (but I am not sure and I certainly don't remember which version started that). I also use direct connections, but I didn't try legacy capture yet.

Two observations:

1) I suspect this may be (partially) caused by the active screen saver. It might be a good idea to "move the mouse" on connection so that the screen saver is turned off.

2) The initial redraw is slow, even if the initial screens (blanking screen saver, fixed-color login screen) are very simple. Once the initial redraw is done, the succeeding redraws are much faster - in fact, redrawing a desktop with complex and diffult-to-compress background is maybe twice as fast as the initial redraw of a one-color lock screen...

Hello Conrad,

I don't have any extensions in Edge, as far as I know. I don't use Edge at all, except that it gets started by your competitor's product to let me enter a description of what I did.

It may be the incompatibility occurs only in certain situations. I use a very non-typical connection scheme with RU, for example (instead of a connection server I use a direct reverse connection [from Host to Control] over a SSL tunnel, and I use screen blanking too; plus the Windows are set up with many specific settings). If RU is able to log the necessary system calls, I can activate the logs, reach the unresponsive state and then send you the results. Perhaps that would be the easiest way of debugging this?

I will also see whether I can replicate the error in a virtual environment, but that may be difficult to achieve.

Just remembered: This incompatibility wasn't always there. There was a time when RU and ME would coexist peacefully. Unfortunately, I can't remember how long that was, as I have been running into this issue for quite a some time until isolating the actual cause and resolution and writing here. It is possible it worked with a pre-6.10. RU or perhaps with an older version of Windows 10.

Recently I noticed a rather annoying compatibility issue between Remote Utilities (RU) and Microsoft Edge (ME):

I use RU to connect to a remote computer (RC). Everything works fine until I start ME on RC. At that moment the RU connection will fail. Particularly, the display will stop transferring data, will turn to black and white, report a lost connection ("connection was interrupted") and fail to reconnect. If I close the full control window and try to reopen it, I get a "certificate warning - potential security breach" and no matter the choice, the connection will not get established, even if I restart RU.

The only functional solution is to connect to SC in the Task Manager mode and kill Microsoft Edge. That solves the problem and I can once again connect to SC using full control.

Unfortunately, I can't avoid using ME, because there is a case where the application concerned (one that I have to use) will start it on its own. Also, if ME can cause this kind of a failrure, I can't help but worry about which other application will do the same thing. It also makes it rather difficult to switch to RU for my customer support needs (I use it for my own purposes now), because what would I do if the customer actually liked Edge and had it running?

SC is running Windows 10 Pro 1809, ME is updated, RU is 6.10.9.0 on both sides of the connection.

Any help?

I just noticed that Remote Utilities seem to incorrectly interpret keys on the numeric keypad. At the very least, the numeric plus, minus, times and divide are sent as regular keys rather than numeric. It is easily noticeable in two-panel file managers where these keys have a different meaning - a regular plus is simply a plus, a numeric plus allows group selection of files.

Not really. I suggested PRO so that you wouldn't lose your income, but there's a lot of sense in allowing these temporary connections even when the number of bookmarks is unlimited: It would help keep the list uncluttered and easy to navigate (there is little point in keeping a connection which was purely one-time, and it might be rather difficult to actually find a stored connection if there are hundreds or thousands of them). Also, if a new Agent connection was to be stored permanently, the user would have to provide sufficient details to make the bookmark usable (e.g. think up a descriptive name), which would take some unnecessary effort.

Would it be possible to extend the Agent builder ( https://www.remoteutilities.com/support/docs/agent-package/ ) with a way to run our custom code? There are at least two use cases where that would be very useful:

1) Use a different communication channel for sending the ID+password than just e-mail. For example, we already have a channel for automatic updates, online backup and reporting. We could use this channel to send the connection data to our servers, where any available tech could pick them up, click a link, which would execute the Viewer with the right command line directly, without having to type anything.

2) We could connect to our application's database, checking for any relevant information before even making the connection. We could, for example, read the customer's name from the database (to be displayed to the tech handling the case), or check for their support level in our systems (e.g., do they even have a support agreement? Do they have a specific tech assigned to handle their cases?).

I imagine a simple DLL with one exported function, such as:

BOOL AgentStartRequested(LPCSTR internetID, LPCSTR password, BOOL * canStart, LPCSTR * message)

The agent would load the DLL, check for the function, call it, then read the canStart parameter to determine the result and display the content of the message parameter.

pepak

Thank you. I think I understand now. It's a pity I can't connect to an Agent without entering the agent's data to the viewer database, but I can appreciate that that might prevent you from making any profit. Still - perhaps it would be possible to provide this record-less approach at least in the PRO license type?

Hi! We are considering moving from  [censored] to Remote Utilities. There are aspects of RU we really like, such as the self-hosted server, but the distinction between a "tech" and an "endpoint" is not quite clear to us.

1) Does a "tech" refer to a person or to a simultaneous connection? The documentation I saw seems to make both interpretations possible, but there's a significant difference. If we have 20 employees but never exceed 10 simultaneous connections, do we need 20 licenses or would 10 licenses suffice? If those 10 simultaneous connections are made by 5 distinct people, could we get away with just 5 licenses?

2) What exactly does an "endpoint" entail? From what I can tell, it's a computer in the list of known computers. If we don't want to use address books at all (we very much prefer the "agent" solution as then we can prove to our customers that we can't connect to their systems without their knowledge and approval), should we even care about the number of endpoints?

Thanks.

Conrad wrote:
You really won't break anything if you just delete one of your callback connections. And yes, the Viewer keeps all its settings and data in that %appdata% folder.

In the end, I created several brand new virtual machines and they behave exactly the way I would expect them to. For some reason the real computers don't, though. Never mind, I am glad to have a working setup and if it was just some glitch with my setup, that's not a big issue.

In fact, I am completely baffled by the need of the hosts to actually provide *any* callback port. Obviously, the hosts are connecting to the viewer, but they are only connecting to one specific IP address and one specific port.

When you use callback connection it's the Viewer that is listening and the Host that initiates a connection, not vice versa.

That's precisely why I can't understand why should the port of the host machine matter.

The Host should know the Viewer's listening port in order to be able to connect (along with Viewer's IP address , of course).

Of course. That's obvious.

They don't have any need for a local port setting, as any traffic should go over the connection they initiated.

I agree that that's how it should work in theory. But unfortunately that's not what I observe with my computers. On my second host, I *have to* change the Settings -> Network -> Port to something else than on my first host, otherwise the callback connection from the host to the viewer will connect, but any kind of control from the viewer will fail to start. The moment I change the Port, even though it should be completely irrelevant as the connection's direction is from the host to the viewer, control starts to work.