Justin_Y
Enthusiast
Enthusiast

Disable Windows 10 Lock Screen

Jump to solution

We are trying to meet those wonderful audit requirements and I have one issue standing in my way. 

We are meeting our authentication requirements using the initial logon and then a timed disconnect (below) reconnect through the UAG appliances. A windows lock screen does not pass out audit requirements. So the goal is the disable the lock screen and use the Idle Time Until Disconnect (VDI) GPO to disconnect back to that initial logon after our time limit. Lets say 15 minutes. To do this we also implemented the Remove Lock Computer user GPO. This works as expected on initial logon but when we reconnect to a desktop after about 5 seconds of seeing the desktop its as if something presses ctrl+alt+del and that brings up the pre lock screen menu. 

I have monitored the desktop in vcenter and the screen still gets locked after disconnect by Horizon which is great. Not sure where this 2nd unlock attempt is coming from. 

Does anyone have a way around this either a Horizon setting to disable that 2nd ctrl+alt+del or a different way to remove the abilities for users to lock the screen from start, Ctrl+alt+del and Windows L

Thank You

0 Kudos
1 Solution

Accepted Solutions
Justin_Y
Enthusiast
Enthusiast

Found a few articles similar to this post that explained that the GPO was the cause of the CTRL-ALT-DEL with no answer on how to disable the lock screen without. 

https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/CTRL-ALT-DELETE-screen-on-reconnect/td-p...

I did find a workaround that works with our requirements. I used the DEM triggered tasks to initiate a disconnect when users lock the screen. This then forces them to reauthenticate using the edge servers authentication. 

Justin_Y_0-1638821205341.png

I then ran into the issue that on the 1st reconnect the logon would flash then it seemed like the triggered task would disconnect you again. A 2nd reconnect did not have the same behavior and logged on as normal. A 3rd reconnect dropped again and a 4th logged on as normal. Digging in the DEM logs I found a pattern and I was able to resolve by creating another Triggered task to refresh the triggered task settings on disconnect. 

Justin_Y_1-1638821353320.png

This is working in Horizon 7.13.1 and DEM 10.2

View solution in original post

0 Kudos
7 Replies
Justin_Y
Enthusiast
Enthusiast

Found a few articles similar to this post that explained that the GPO was the cause of the CTRL-ALT-DEL with no answer on how to disable the lock screen without. 

https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/CTRL-ALT-DELETE-screen-on-reconnect/td-p...

I did find a workaround that works with our requirements. I used the DEM triggered tasks to initiate a disconnect when users lock the screen. This then forces them to reauthenticate using the edge servers authentication. 

Justin_Y_0-1638821205341.png

I then ran into the issue that on the 1st reconnect the logon would flash then it seemed like the triggered task would disconnect you again. A 2nd reconnect did not have the same behavior and logged on as normal. A 3rd reconnect dropped again and a 4th logged on as normal. Digging in the DEM logs I found a pattern and I was able to resolve by creating another Triggered task to refresh the triggered task settings on disconnect. 

Justin_Y_1-1638821353320.png

This is working in Horizon 7.13.1 and DEM 10.2

0 Kudos
KenArcher
Enthusiast
Enthusiast

I've been fighting with the same issue. Unfortunately triggering a tsdiscon.exe on lock along with the refresh on disconnection doesn't have the same results for me. I get an instant disconnect on every reconnect attempt. The DEM logs show a user environment refresh on the first disconnect but nothing on subsequent reconnection attempts. At this point I'm forced to reboot the desktop via Horizon Admin. Are there any additional settings that may need to be applied for the provided fix to work?

I should note that triggering a tsdiscon via command line without the two triggered tasks does not cause the same issue. The session will disconnect at that point and can reconnect without issue. Interestingly enough, if the user hasn't triggered a Windows lock the session will return without prompting the user for the password. After Windows lock has been triggered even once reconnections after a tsdiscon will always prompt for a password.

Edit: Another behavior has been identified. If I configure DEM to send a message on unlock I get three messages instead of one. So it looks like the system is locking on reconnect on its own.

0 Kudos
Justin_Y
Enthusiast
Enthusiast

We also do a refresh on session reconnection but that was in place before adding anything. From what I saw in the logs it was the disconnect and then it seemed to disable the lock task until reconnect. i am running 10.2 version of DEM. I did bring up a similar issue a few versions back about lock screen tasks being executed on reconnect so this may have been included in a bug fix if your running a older version. 

0 Kudos
KenArcher
Enthusiast
Enthusiast

Thanks for the response. Unfortunately, refreshing triggered tasks at either reconnect or disconnect or both is not having the same effect for us. After the lock/tsdiscon.exe the user can no longer reconnect to their desktop. It looks as if Windows is triggering a lock on reconnect, which in turn has DEM triggering tsdiscon.exe. I was able to replicate similar behavior using the option to send a message in the triggered task instead of tsdiscon.exe. If I lock the session and stay connected the message would pop up once. However, if I lock the session and disconnect/reconnect I get the message pop up twice. 

We are currently using 10.2 as well so I don't think it's an issue with that. Instead I suspect it's a windows 10 behavior that's causing the extra lock.

0 Kudos
Justin_Y
Enthusiast
Enthusiast

Its Horizon's unlock process. Also might help we are running Horizon 7.13.1 , Win 1909

0 Kudos
KenArcher
Enthusiast
Enthusiast

We are Horizon 2103 Win 21H1. Rollback isn't an option at this time so I may have to get creative and script a solution. If I come up with something I'll post it here in case anyone else has the same issue. Thanks. 

0 Kudos
Justin_Y
Enthusiast
Enthusiast

I had a Horizon Client Property, Pool Name, Contains condition on the Disconnect user on lock triggered task for our test pool name. After removing the condition so it applies to all desktops it went back to disconnecting as soon as I connected. No idea why this works but I tested by adding the condition back and applying a common part of the pool name and its working! Hopefully you have all your pools starting with a common pool name, didn't test with any other conditions. 

0 Kudos