Cautious reluctant all-clear from me (Germany) …:

Since connecting this morning to a remote machine and working on it for shorter and longer intervals and longer and shorter breaks without disconnecting in-between RA's behaviour seems to have returned to pre-christmas performance for now. Anyone else observing this?

Whatever you did in addition to that restart, it seems to have worked out positively.

Cheers
Philipp

Unfortunately I have to add my own "almost no improvement" comment. There was one positive change: The pre-remote connection to RA servers now happens instantly instead of up to a minute "connecting" and up to another minute "registration". But after that when in fact connecting to a remote machine that session still lags like before. Same behaviour: a couple of seconds fluent workflow and subsequently up to a minute for a simple mouseclick. Repeat.

Hoping for soon improvements with best regards
Philipp

I have to join into this issue, very similar observations here (Germany) since a few days (not exactly to pinpoint, after holiday and turn of the year back to everyday operation since Monday, 6th Jan. Issue appears since then, maybe earlier):

"Connecting..." status displayed for 30~60 seconds after starting RA.
Subsequently "Registration in progress..." status displayed for 10~20 seconds
After that "Ready to Connect" status display.
When connecting afterwards, all the steps displayed also take much longer than, well, last year.

When operating a remote session, this works for up to maybe a minute or shorter, then a phase of extreme lagging follows (10/20/30 seconds for even executing a mouseclick on the remote machine), unclear duration, then maybe again a short phase of relatively fluent operation, then again lagging and alternating these in the subsequent time.

Plz explain and update – tnx in advance
Philipp

I have to join into this issue, very similar observations here (Germany) since a few days (not exactly to pinpoint, after holiday and turn of the year back to everyday operation since Monday, 6th Jan. Issue appears since then, maybe earlier):

"Connecting..." status displayed for 30~60 seconds after starting RA.
Subsequently "Registration in progress..." status displayed for 10~20 seconds
After that "Ready to Connect" status display.
When connecting afterwards, all the steps displayed also take much longer than, well, last year.

When operating a remote session, this works for up to maybe a minute or shorter, then a phase of extreme lagging follows (10/20/30 seconds for even executing a mouseclick on the remote machine), unclear duration, then maybe again a short phase of relatively fluent operation, then again lagging and alternating these in the subsequent time.

Plz explain and update – tnx in advance
Philipp

Addendum:

Just did an update on another machine, unconnected, and everything worked fine. Afterwards no problems connecting to it from elsewhere with old, known credentials. So obviously "update while connected" seems to be the problem.

Philipp

Hello again,

I now conducted an update on another remote device and observed the same problems, now well documented, I hope:

Device C: Physical machine: W10-Laptop at private Home, CB-RA-2.1 at that time, sitting on the same Desk with machine B so I can execute remote stuff and observing everything in parallel.

Chain of events:

Establishing connection from B (local) to C (remote), B already on RA-2.2, C still on RA-2.1. Using known credentials, 9-digit-ID ("4xx-xxx-xx0") and keyfile.

Connection established and works.

Right after that, via remote ≡ menu check for updates and acknowledging the expected connection abort:



After that, the connection closed:



Now having a look at the Laptop's screen (device C) directly. The previouslly mentioned error dialogue almost immediately showed up, now here in full detail screenshotted:



("The process can't access the file c:\…, bc. it's in use by another process")

Funny enough, the update runs in the background and after clicking away the error, RA restarts automatically – and now with a different ID ("8xx-xxx-xx2", not the previous "4xx-xxx-xx0"), and without encryption and unattended access enabled:



Clicking encryption, generating a key and trying to save it yields the following error message:



("Path not available. (X) "C:\windows…" is not available. … yadda yadda yadda")

Confirming that error with OK and after that shutting down RA and restarting it solves the problem. It is then possible to generate a key, save it, transfer it to the local machine B, entering the new ID and importing the key and then establishing a connection and working via it.

So there seems to be an issue with the update process started remotely via a RA session on the remote machine. I'll try out the outcome when updating RA locally on a machine D first and then connecting there from, say, machine B.

Hope this helps better.

Cheers
Philipp

Hello Sergey,

well, this is strange. I'll try to recap but I don't have all the details in mind unfortunately.

This appeared in the following constellation:

• Device A: Physical machine: W10-Laptop inside corporate Network, CB-RA-2.1 at that time
• Device B: Physical machine: W10-Workstation at private Home, CB-RA-2.1 at that time
• No OS reinstallations on both devices.
• Supposing with "user" you mean OS user/W10 Login, yes, same user for installation, both devices

Chain of events:
Yesterday: establishing RA connection from A (local) to B (remote), everything ok, doing some remote stuff. Later on check for updates manually via the ≡ menu and getting 2.2 announced. Not yet executing the update being cautious and completing the remote stuff on B. Then first starting update on the remote device B with connection aborting as expectable. Then secondly starting update on local device A. I remember getting asked for the registration ID which puzzled me a bit because, well, just an update. I didn't remember it so clicked "no ID" and entered my mail (the one I believe I used already for first registration, but not absolutely sure about that). Installation and restart completes, I think at that point the remote ID must still have been in the history because I tried to reconnect to remote B but that failed, even with a couple of retries. I think the error message was somehow "unusual" but can't remember it verbose. Gave up on that.

Later at home and physically in front of the until then remote machine B. It shows an installation error dialogue whose content I don't remember, sorry. After ok'ing it away the update installation finishes anyway (without requesting registration infos) and RA starts — already with empty history. Being on the "allow remote control" tab also all the settings regarding encryption and unattended access are gone. Setting these checkboxes and trying to generate a key export results in a strange windows explorer filesystem error mesage claiming that the path c:\...\...\Desktop (don't remember details) doesn't exist.

I then shut down RA completey and started it from Start Menu after some seconds. From then on, everything worked, key generation and export/save as ra-key-DEVICENAME.txt . Nevertheless the device history was still empty and the local 9-digit ID was a different than before.

Transferring this keyfile today to my laptop (Device A) and opening a remote session to B, using the new 9-digit ID and importing the new ra-keyfile worked smoothly. I now have a remote session A→B open all day. Can't tell whether the 9-digit ID of A has changed because I never wrote it down and the only history it ever was recorded in is gone (@ Device B).

I also have not updated RA on any other devices I use it on, but I'll keep my eyes open on strange behaviour when doing so.

Sorry, this is all a bit gappy but I hope it helps.

Thanks
Philipp

Heyho,

is it known and correct/intended, that with Cloudberry MSP360 Remote Assistant …:

• The device/connection history is gone
• And with it the keys/keypairs for encryption and Unattended Access are gone as well

…, so that one has to newly generate keys for all connections on all devices used until now?

Cheers
Philipp

Thank you! Do you need further information?

Hi, Gleb,

thank you very much for the fast and pleasant feedback. I have an additional detail regarding this matter. A similar effect happens with the main CB RA toolbar. Please see also the enclosed commented screenshot (blurring by me).

The mouseover effect for both layers (remote and local) also appears with the toolbar, if it unfolds over a remote desktop window, in this example a Firefox with several tabs open. As you can see, hovering above the chat icon also highlights the underlying nonactive firefox tab. Other than in the scrollbar example a mouseclick seems not to "go through" to the remote firefox, since clicking in that example opened only the chat window and did not activate the underlying FF tab - the one with Google in it stayed selected.

Seems related to the other bug, although not with the exact same (mis)behaviour.

HTH
Philipp

Yes and no ... I pasted several keys into a text editor and two were identical, checked via search and compare. But in hindsight I'm not sure whether I made a copy and paste error, so everything's fine, I guess. Thanks for feedback.

Bye
Philipp