As always we are excited to announce a new performance and usability improvements to CloudBerry Remote Assistant along with awesome new features with the release of version 2.2.
CloudBerry Remote Assistant is now able to host fully functional Meetings. This is the first iteration of this feature and many more improvements and features are coming later through the year. You can host a meeting for an unlimited number of participants, share one of the screens or specific applications if you don’t want to show your entire screen.
Session Recording and Playback
Sometimes you need to save an important meeting that you just had or have proof of a completed task or important session that you had, or maybe record an example of how work should be done for your employees. We understand that and this is why we implemented this feature. You can record meetings and remote sessions with your peers. After the recording is finished you can share the recording or play it via a built-in Remote Assistant Recorded Session Player.
Custom Passwords
In case you don’t want to use Unattended Access, but need constant credentials to connect to a specific machine we implemented an awesome feature - custom passwords. From now on, you can set it up and forget about constantly changing PIN in case of a machine or software restart.
Conclusion
As always we are listening to your feedback. This list only covers new features, however, there is so much more that we fixed, optimized and improved under the hood. Don’t forget to update to the latest version via Main Menu - Check for updates or by downloading the latest build from our site.
macOS and iOS versions
We are really glad to announce the start of the BETA program for the Mac platform. You can find a sneak peek of those versions along with the sign-up link here.
Nope, we haven't encountered it on the update, in fact, I have updated myself from 2.1 to 2.2 and haven't encountered anything like that. So we will need to clarify a few moments here:
1) Was the same user used in the installation?
2) Any changes on the machine were made regarding OS reinstallations or anything?
3) Is it a VM or a physical machine?
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.
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.
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.
So far you can't, however, we already have a similar feature-request into which I have added this one and you will be informed upon the release. Thank you.
I am running Windows 10 Pro on the local system and Windows 8.1 on the remote. Since the installation of the new version, a pin is required at every login even though unattended access is selected on the remote machine. Also, when I try to perform an administrative procedure such as add features to Windows 8, I can no longer control the remote system and have to have someone local to that system complete the procedure. I did not have to enter the pin in previous versions, but did have to sign on to the remote system using the Windows signon.
It would be useful to be able to view/change options in Cloudberry Remote on the remote system. i realize this could be considered a security issue, but if one has already been granted full control it seems to me that it is a moot point.
Thank you for your feedback, this is interesting indeed, PIN shouldn't be requested after the update, the settings should remain the same. Maybe the UA is disabled now ? Anyway we will reproduce this scenario on our side and see what it will lead us to.
"Service Request failed: unable to connect, another connection is established." I get this message after having the connection between my system and the remote system fail. I know there is no other connection to the remote system, but am unable to reestablish the connection until the remote system is rebooted by someone at that location. Sometimes I continue to get this message even after a remote reboot.
This means that the service of RA is either hung or in some incorrect state. I would suggest simply re-installing the software from an elevated account and trying to connect again, it should work normally afterward. In case it still fails I would suggest checking the Event Logs.