Greg Sullivan's community posts

Hi Pauline,

Thanks for the reply.  I'll do my best.  :)

Sometimes when working with a remote host, I need to simply move a file to/fr om the host.  In this case, the File Transfer mode that RU currently provides is entirely sufficient.

However, frequently I have more elaborate file transfer needs.  That might be:
1) synchronizing multiple specific files located in different folders across the drive
2) pushing/pulling files based on a script executing on the viewer computer.
3) iteratively tweaking CFG/INI files on the host without disrupting the activities on host desktop.

If the host computer were on the local network of the viewer computer, I would simply share a folder from the host computer and map a drive from the viewer computer:
  net use z: \\host_system\share
now any program on the viewer computer can work with the mapped drive Z: just like any other drive.

But if the host computer is truly remote, I believe this can't currently be done without involving several extra steps, leveraging other solutions.

I regularly find myself thinking it would be very cool and useful for RU to have a built-in feature wh ere, once a viewer has logged on to a host, a mapped/virtual drive could be created on viewer computer that points to a location on the host computer.  Not suggesting this is a simple feature, but it seems to me many of the key mechanisms are already in place.

Hope that helps!

Greg

File Transfer works fine for some stuff.

But it would be very awesome if RU could create a mapped drive on the viewer system that points to a drive (or folder) on the remote host.

Hi Pauline,

Looks like your address book corruption guess was on the mark.

I exported the address book and imported it into a portable viewer running on a different system.  From this set up, clicking "Logon" for connection #1 did nothing: no logon attempt at all,  for connection #1 or connection #2.

Connection #2 works as expected.  But Connection #1 can't be launched at all.

After clearing the address book and creating new connections #1 and #2, everything works as expected.

The "corrupted" address book was from the previous RU 6.10.10 install (which functioned as expected)

Greg

Properly capture question/request from
Switch to "View Only" from host as a Feature Request topic.

Add a mechanism on the host to downgrade a Full Control session as "View Only" without disconnecting the session.

and/or add a inactivity timeout on the Viewer that will downgrade "Full Control" to "View Only"

- Greg

Hi Conrad,

Thanks for that suggestion.  I'll look into it for the scenario I describe.

I do have a slightly different [and common] scenario where using the notification panel would be less convenient than the requested feature.

I have a few connections where I'm remotely monitoring a system in parallel with on-site personnel.  Either one of us are frequently stepping in and briefly interacting with the desktop.  When not interacting, I'm watching the remote desktop from across the office.

Having to reconnect after being disconnected via the notification panel would be inconvenient - perhaps that would train me to do a better job of switching to "View only" when done.

Maybe a more easily implemented alternative, or additional feature request, would be to have an option on the viewer to automatically fall back to "view only" after a configurable period of inactivity.  Though this might not work well in my "noisy mouse" situation.

Thanks for the terrific software!

- Greg

Hi Conrad,

Sorry I left out that detail.

No, the connections point to two different host machines with unique Internet-ID's.  The two connections are physically located at the same remote location and on the same local network as each other.  (i.e. they are at the same relative internet facing IP address relative to the RU ID Servers)

I'm connecting from a separate remote location from the two connections in question.

- Greg

I apologize if this functionality already exists and I've overlooked it.

It would be useful to be able to switch a remote session back to View Only fr om the host.

I have encountered a few scenarios wh ere this would be valuable, but here's one example:  I have a remote system on the other side of the building that I use between direct physical access and as a remote connection.  Sometimes I forget to switch back to "View only" before leaving the remote viewer.  Then, 15 minutes later, standing in front of the actual computer, I'm fighting with the "noisy" mouse on the other end of the remote "Full control" connection and the pointer is driving me insane.  :)

If I could just do something like an Alt-F12 at the host side to switch the remote session back to "View Only" without having to go back to the remote viewer on the other side of the building.  And without resorting to pulling the network cable or power cycling at the host.

- Greg

Just upgraded to windows Viewer and Host v7.1.1.0 fr om v6 and I've bumped into a quirk, seems readily reproducible.  There appears to be an issue with the logon mechanism wh ere extra connections are performed.

In the viewer, I have an address book folder with 5 connections (2 of which are online, 3 are offline).

If I sel ect the online connection #1 and right-click and choose "Log on", online connection #2 (!) shows "Logging on...".  Once #2 has become logged in, #1 shows "Logging on".

If I double-click on connection #1 (default action is view only), the same behavior occurs (connection #2 logs in, followed by the #1), except that only connection #1 opens up in the desktop Viewer (as expected).

If both connections are logged in, Logging off fr om #1 behaves as expected: only connection #1 is logged off.

If I attempt to log into the 2nd connection, only the 2nd connection logs in (as expected).

It's a minor issue, but slightly annoying.  Causes some extra/unnecessary connection activity.

Greg

Hi Polina,

Host and viewer here are running the v6.10.10.0 release build - due to some other constraints I won't be able to try v6.12.2.0 for a little while.

I need to look at the best way to try to attempt to do a screen recording - because the issue now happens far less frequently, I could be running a screen recording for many hours waiting to catch it.

Greg

Greg

All (Polina, Conrad),

Once I updated hosts and viewer to v6.10.x.x. this problem was _virtually_ eliminated - though not completely.

HUGE IMPROVEMENT: I'm no longer seeing constant disconnections every few minutes.
BUT: I do sometimes get a disconnect once every few hours which is tolerable.

However I will share an observation that I shared in my post to this discussion on Mar 29, 2019:

Very often, the main RU window listing connections will show a pop-up saying the remote connection has disconnected.  However for up to 5 seconds, I can continue to fully interact with the remote system in the viewer, whether that's typing text, moving windows, clicking UI, etc. before the remote connection actually drops.

Once I reconnect to remote system, I can confirm the actions taken *after* RU reported the connection had dropped were indeed performed on the remote system.

To me this suggests it's not so much a case of the remote system has disconnected, but that something (other than the host or the viewer) has *decided* the remote system has disconnected.  This is undoubtedly an over simplification, but it seems to me the host & viewer would ideally be the final determinants of a dropped connection.

Greg