After checking the actual design of logonshield when multiple sessions are available on the target machine. I understand the behavior as below. (when option "Prevent user from being logged on while job executes" is set, all users should be logged off to have the SD job executed.)
Suppose we have enabled logon shield for a job which is deployed onto a target where 2 sessions are in disconnected mode and one is in active state. In this scenario, the active session is shown the logoff request and upon the logoff completion, job seems to be starting but not getting complete. Once you logoff the disconnected sessions, the job is working fine. The behavior seems to be as per the current design only.
But some customers except that when we start the job the active user gets logged off and he gets the logon shield. The other users get logged off also so the job can start. So the customer expected behavior is to logoff other disconnected sessions and execute the job.
By default, we expect SD Agent to show logoff window for all active user sessions. Once all the sessions are logged off, then only the job execution starts (after Logonshield enable). Agent doesn't forcefully logoff the sessions as it might cause critical data loss. We definitely see it as the main reason behind the current design. We expect most of the customers may not accept forceful logoff due to critical data loss.
However, Customers hope if we can have a config setting to decide the behavior in this scenario. This mean, depending on the customer's requirements, either we logoff disconnected sessions or wait (current design).
So as per customer demands, I m posting this as an idea for consideration the above in future releases.
Thanks & Best Regards,