S
Steve Bottoms
Guest
Good morning, everyone! Environment is multiple Windows 10 Pro systems (v1607 thru v1803) in a multi-site AD domain.
Condition #1: some users may have active screen savers running with timeouts ranging between 5 and 30 minutes, *WITHOUT* the "On resume display logon screen" checked. Doesn't matter if Screen Saver is set for "(None)" or some screen saver from the list. Let's use an example of 2 minutes on the screen saver, setting *NOT* selected to display logon screen.
Condition #2: recently pushed to machines in a given OU a GPO containing the "Interactive Logon: Maching inactivity limit" set for 1800 seconds (30 minutes).
Problem: This issue appears only when the GPO has been pushed, and is verified at 1800 seconds through both RSOP adn registry settings. It appears that when the screen saver is active and the -x- minute timer of inactivity is reached, the screen saver goes off as designed. However, if I let the machine sit for more than 30 seconds after that, it will ALWAYS enter the lock screen. Every time, verified with multiple users, both normal and domain/local admins logged in, easily replicable.
So I disabled the setting in the GPO, re-pushed, and verified that correct policy setting ("Not defined") is now pushing. I just tested again with the screen saver TURNED OFF but the saved value of 2 minutes *and* the "display logon screen" NOT checked: screen saver went off at 2 minutes, displayed the lock screen.
So there are two questions here: 1) Can anyone confirm that when this GPO setting is turned on the screen saver setting OVERRIDES the timeout value set for locking, *REGARDLESS* of whether the screen saver is configured to "Display logon screen"? 2) there's some other setting somewhere in Windows 10 that appears to be persisting after a screen saver timeout has been set BUT IS DISABLED?
I've verified that there are NO OTHER GPOs with any associated settings set anywhere in the domain, enforced or otherwise, that set set to cause either of the behaviours I'm seeing.
Thanks!
SteveInReno
Edit: Yes, I've checked this (https://social.technet.microsoft.co...oblems-causing-group-policy-to-not-apply.aspx) article and verified that none of the points noted apply here.
More...
Condition #1: some users may have active screen savers running with timeouts ranging between 5 and 30 minutes, *WITHOUT* the "On resume display logon screen" checked. Doesn't matter if Screen Saver is set for "(None)" or some screen saver from the list. Let's use an example of 2 minutes on the screen saver, setting *NOT* selected to display logon screen.
Condition #2: recently pushed to machines in a given OU a GPO containing the "Interactive Logon: Maching inactivity limit" set for 1800 seconds (30 minutes).
Problem: This issue appears only when the GPO has been pushed, and is verified at 1800 seconds through both RSOP adn registry settings. It appears that when the screen saver is active and the -x- minute timer of inactivity is reached, the screen saver goes off as designed. However, if I let the machine sit for more than 30 seconds after that, it will ALWAYS enter the lock screen. Every time, verified with multiple users, both normal and domain/local admins logged in, easily replicable.
So I disabled the setting in the GPO, re-pushed, and verified that correct policy setting ("Not defined") is now pushing. I just tested again with the screen saver TURNED OFF but the saved value of 2 minutes *and* the "display logon screen" NOT checked: screen saver went off at 2 minutes, displayed the lock screen.
So there are two questions here: 1) Can anyone confirm that when this GPO setting is turned on the screen saver setting OVERRIDES the timeout value set for locking, *REGARDLESS* of whether the screen saver is configured to "Display logon screen"? 2) there's some other setting somewhere in Windows 10 that appears to be persisting after a screen saver timeout has been set BUT IS DISABLED?
I've verified that there are NO OTHER GPOs with any associated settings set anywhere in the domain, enforced or otherwise, that set set to cause either of the behaviours I'm seeing.
Thanks!
SteveInReno
Edit: Yes, I've checked this (https://social.technet.microsoft.co...oblems-causing-group-policy-to-not-apply.aspx) article and verified that none of the points noted apply here.
More...