I think there is confusion because you're able to access the Change Password page without entering a valid password at the initial login prompt. It sounds like the user never got past the Change Password page, so no new password was being saved. (Although there's some ambiguity over step 11, "the second new password works" - in what way?)
I'm not seeing the same behavior on my 20.6 instance, but I'm not set up with Automate either. It doesn't appear to be a Control bug, though. I'd contact support for some hands-on troubleshooting.
Those should only change upon a reinstall. When you say "another company group", are you referring to custom property 1 (which is named "Company" by default)? Are you using any extensions or integrations that might be reinstalling the client with different custom property values?
Hmm, 20.1 should definitely support TLS 1.2. Do you see any error messages? If circumstances permit, it might be helpful to run the server in debug mode and send me (email@example.com) the resulting log:
sudo /etc/init.d/screenconnect stop
sudo /etc/init.d/screenconnect debug > debug.log
(It might also help to know what mail service you're using.)
This seems to work properly on my device. To be clear, you're talking idling on the host page in the Control app, correct? (When I hear "client" I think of the Control software itself, rather than host (or admin, for that matter) page access.)
Is this still happening for anybody on 20.5+? I only have one debug partner, and I haven't heard back from them in a while.
(If you're willing to help debug, I'd prefer cloud instances, but any reliable repro case will do.)
Our first implementation broke ADFS, so we had to roll it back. A new implementation is currently in review, so I'm not sure which release it will be in yet.
Customer support service by UserEcho