I just love RA and have been using it for quite some time now. However, yesterday, after update to build 2.3.0.52 (both Host and Remote) I now get an error message when trying to connect Remote computer which I have configured for unattended access, exchanging keys.
After pressing connect I get a message "'myComputer' is already working on Remote Computer. Your connection may pause this windows session". 'myComputer' is name of my computer.
However, there are no other remote sessions ongoing. The Remote Computer, as well as the host, have just been started/rebooted.
I can force a connection by providing the PIN, but this is not according to the configuration and what I want.
Do you have an idea what happened and how to resolve this?
Hi, yes I have updated both the host and the Remote. Host is win10, Remote is running win7.
I also checked another Remote using win10 this evening. Although this Remote2 has not been updated the same problem applies. Remote2 is running RA 2.2.0.51 . This is also the version that I was using on Host and Remote1 before the update.
So problem seems to be that host thinks that there is already an ongoing session, but infact it is not.
I am thinking of two things to narrow down the issue:
- Delete the computers and re-generate key pairs etc and re-enter them in the list of Remote Computers.
- Connect to the Host using Remote1 and Remote2. This might answer if there is a version issue. On the other hand I have never connected this way so I will need to generate keys and get the Host on the list of remote computers. This is basically the same as item above and thus, may have little value.
same problem. have not tried reinstalling. one machine was a usual upgrade. the other had some odd error during upgrade so it forgot the id and all settings. had to generate new keys. this probably rules out the suggestion that regenerating keys will fix it. all machines involved were on latest version.
I have looked up the case from our side and reproduced it also. This behavior is normal, previously we basically kicked you out of the session in case of using Unattended Access, now we just warn you that you will break up the session of the user that is currently logged in. If the application is running not as a service you can connect via PIN and join the current session. We understand that this is not obvious and we will re-work the mechanism and the text you are seeing. Thank you and let me know if you have any questions. Cheers!
Thanks for update. However, I am not sure that I understand.
There is no RA session ongoing, so no session to be kicked out from.
When I press "Connect" on the shown screen above, things behave a bit differently on win10 vs win7.
On the win10 Remote I can see that it goes back to Windows login screen, logs in, restart RA and eventually the screen is shared. So maybe this is what you mean when you state that the session is restarted.
But, on my win7 Remote, when I press "Connect", the Remote goes back to Windows login screen and stays there while showing "Waiting for remote instant of Remote Assistant to start" on Host.
This state is never resolved. Finally connection with RA is lost and the following is shown on Host:
If you then, on the Host, try to reconnect, you get the following message:
On the Remote nothing is shown except the win7 login screen.
When logging in on win7 Remote it re-establishes network connection which indicates that this was pulled down when Host tried to establish a RA session.
As a RA user, you previously have always had, and I think, should have, the impressesion that you dive into the current session. All session specific information data and application is kept as is and there is just another Remote user (the Host) controlling the inputs as has been determined by the setup of the configuration of the Remote computer.
I hope this is what you will revert back to. Anything else seems very confusing.
I must also take the opportunity to thank you for a great application. I have been around from start. Performance and feature suite have improved a lot over the builds.
I have tried to give my 5cents of testing and hope you can do something with it.
I just upgraded to 2.3.0.52 and this problem still persists. Is there a fix in the making or should I roll back to the previous version? Not sure if it's related, but the connection is also superslow.