Greg Sullivan's community posts

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

First off, RU is an awesome product.  Overall, very happy with the flexibility it allows me.

I've had this 'disconnect' issue as well.  So far I've seen this persist with 6.8.x.x and 6.9.x.x.  I'm currently in a situation where I can't risk attempting a remote upgrade to 6.10.x.x that might fail where I completely lose remote access.  So that'll have to wait - but it sounds like 6.10.x.x are still seeing it.   So I'll share some observations.

This seems to be more nuanced than just simple "network issues" at the host or viewer ends.  The viewer is on a 1 Gbit (roughly symmetic) fiber internet connection.  The host was initially on a admittedly spotty DSL connection, then upgraded to more stable a 50 Mbit cable internet.  The problem remains the same.

Early in the day (east coast, US) remote connections are pretty solid - around 1 PM EDT they start dropping. During this time, bandwidth and latency do drop a bit, but overall do not show any drastic degradation. Around 6 PM EDT, things start improving.

A few observations:
1) If the viewer connects to the host by Internet-ID, the connection fails several times an hour.
2) I can immediately connect my local computer to the host computer network over VPN and the connection no longer fail.  The VPN server is hosted at the same location / network as the host computer.  So at a high level, there's not a drastic change in the connection between the two points - except the use of the Internet-ID.
3) Recently, perhaps most significantly (?), I've noticed that when the connection drops, the main Viewer window displays the "connection error" and the remote host either shows as "Online" (but no longer "Logged On") or briefly moves to "Offline/Unknown" before moving back to "Online".  However, while all of this is happening, for 2 to 4 seconds, I can continue to interact with the remote desktop.  After a few seconds, the remote desktop does eventually "drop".  Upon reconnecting, I can confirm that the actions taken after the "disconnect message" were indeed carried out on the remote host.

This would suggest to me that the issue isn't so much in the remote access connection, but in Internet ID connection status mechanism.  It seems that for some reason, the viewer determines [incorrectly?] that the remote host has gone away and closes a functioning remote access connection.

- Greg

Appreciate the effort in addressing the issue.

Sorry to report we too are also [still] seeing random disconnects, and frequent online/offline popups over the past two days.

In my experience, prior to v6.8.0.1, the issue was far less common.  Also, I do wonder if there's a "network health" component to the problem:
- With remote machines at two locations, the issue seems to be much worse at the location that has a lower bandwidth, and less stable connectivity.
- At this "worse" location (Eastern US time-zone), the problem is almost non-existent prior to 12:00 or 13:00, at which point it gets quite bad and remains so until around ~19:00.  Weekends are usually problem free.  I've wondered if net usage in local geographic area is a factor.
- It's a far less desirable configuration, but if I establish a VPN connection to this "worse" location, and connect to the remote station by local IP instead of Internet-ID, the issue is reduced (eliminated?).

Initially, I was planning on trying to get hardware pulled together to set up a local server, but this will be a challenge in the near term - and reading this thread might not solve the problem.

Again, thanks for trying to sort this for us!

- Sully