Thank you, Sergey. But I cannot understand how making a user give their log-on credentials to someone else is in any way a 'security' feature. Exactly the opposite. But I can see that no-one in CloudBerry agrees with me, so I have to just accept that and move on.

Thank you for your time.

...and I'm guessing that no-one has answered because they are hung up on having that obstacle in place, and don't want to explain why. These are clever people. They could do it, no problem (I'm guessing).

For me, I sometimes see a benefit when things go wrong. Stuff isn't perfect: that's life. It's sometimes re-assuring when your favourite, formerly-perfect, supplier gets a delivery wrong, because then you get to see how they will handle the (inevitable) problem. In this case, Cloudberry don't even seem to accept there is another view, never mind a problem, so I have to draw my conclusions about their support.

Maybe it's me. But I think we've both described real-world, very common scenarios that mean that needing to know the user's local log-on credentials is much worse than not requiring them.

I gave up, and reluctantly renewed with AnyDesk.

Hi, David

Thanks for the really fast response. I believe I had already read this article, and it describes exactly the problem:
"...you simply enter the remote machine's Remote Assistant ID, enter the remote host user's Windows credentials"

I don't want to know the Remote User's credentials, and they may not want to tell me them. In order for me to have access to their machine, they will have to have already complied with some or all of:
- installing the software
- setting various security settings
- providing me with their ID
- given me their PIN
- given me their public Encryption Key

Even when I write that I'm thinking it would sound deeply suspicious to them if I then ask them additionally for their username and password - their final line of defense. (Now I can access their machine if I'm on-site, and they're not even there.)

The other remote access programs I have used all allow me to join the remote screen exactly as it is currently running. That works well for the inexperienced remote person, obviously. And for the experienced local user it allows them to have their screen unlocked, and I join them seamlessly as intended; or they can leave their screen locked and have complete assurance that I cannot access their data in their absence. It works perfectly - from complete unhindered access to total lock-down and all points in between.

This afternoon I have read the documentation and forum postings, and many people seem to have the same issue as me - it just doesn't provide 'Unattended Access' the way I expected, and the way other apps do. You guys are clearly really capable, and I believe could provide it in a flash, so I think there is some reason why you don't want to, and I can't follow the logic of what that might be.

The program, for me, is 99.9% there - the hard graft is all done, and really well. Make the connection join the remote machine 'as is' at that moment, and I'd be very happy.

Thanks again.