• Sergey N
    21
    CRA.png

    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.

    Read the full article in our Blog
  • Philipp
    0
    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
  • Sergey N
    21
    Hello Philipp,

    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?

    Thank you.
  • Philipp
    0
    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
  • Philipp
    0


    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.
    20190817-085532.jpg
    Connection established and works.

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

    20190817-084021.jpg

    After that, the connection closed:

    20190817-084033.jpg

    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:

    2019-08-17.png

    ("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:

    2019-08-17%20%281%29.jpg

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

    2019-08-17%20%282%29.png

    ("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
    Attachments
    20190817-085532 (22K)
    20190817-084021 (30K)
    20190817-084033 (13K)
    2019-08-17 (3K)
    2019-08-17 (1) (34K)
    2019-08-17 (2) (6K)
  • Philipp
    0
    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
  • Sergey N
    21
    Hello Philipp,

    Thank you for such an informative reply. this will definitely require some time to test. Thank you for pointing it out.
  • Steve Wasiura
    0
    great job documenting this Philipp! I wish all end users were as helpful.
  • Diogo Alves Gouveia
    0
    In this new version is it possible to have multiple-to-one conections?
  • Sergey N
    21
    Hello Diogo,

    Not yet, unfortunately, I have added your request to an already existing one. You will be notified upon release.
  • Fatih
    0
    Hello,

    Nice program and thank you freeware version. I tested, but how to open multiple sessions (computer) ?

    I want to multiple computer.

    Thank you.
  • Sergey N
    21
    Hello Fatih,

    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.
  • MrJani951
    0
    Waiting for Android remote version will be released...
  • Sergey N
    21
    Thank you ! We are already working on it.
  • Dann
    0
    Hi Sergey, great work on the latest version of CloudBerry Remote Assistant. I am a big fan of the software and use it daily - I am now worried though that I have ordered a new Windows 10 laptop running on an ARM processor.

    This is fine for x86 software, or compiled for ARM64 but Windows 10 ARM will not emulated x64 applications. Although it is technically possible, you can't actually do it on a Windows 10 device with an ARM CPU.

    I seem to think old versions of CloudBerry supported x86 but it looks like the latest versions are x64 only. What are the chances of getting an x86 or even ARM64 binary for Windows devices? If it's not something that can be done fairly easily and quickly then I will have to either cancel my order of the device or switch to an alternative remote assistance product and I'd rather not do either.

    Any way I can get around this?
  • Matt
    91
    Let me consult with R&D first, and we'll provide more info on that as soon as possible.
  • Ron Williams
    0
    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.
  • Sergey N
    21
    Hello Ron,

    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.
  • Seekay
    0
    Any plans to release a client for Linux?

    Update: Never mind, I just saw there is another thread requesting one already. Please include me to your notify list. Thanks! :)

    https://forum.cloudberrylab.com/discussion/692/page/p1
  • Ron Williams
    0
    "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.
  • Sergey N
    21
    Sure, added.

    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.
bold
italic
underline
strike
code
quote
ulist
image
url
mention
reveal
youtube
tweet
Add a Comment

Welcome to MSP360 (CloudBerry) Forum!

Thank you for visiting! Please take a moment to register so that you can participate in the discussions!