Our DC is Windows server 2008 R2 and our workstations in our company are Windows 7. I am trying to set up a GPO that will automatically lock workstations after a predetermined time(no screensaver-just lock them). I have found all sorts of info on the web and on this site on how to do it-and it seems pretty simple. However when I create the GPO and apply it and test, it is not working. Here is what I have done:

I make the changes to the default domain policy at:

User Configuration > Policies > Administrative Templates > Control Panel > Personalization

  1. in the GPO I have enabled the screensaver

  2. in the GPO I have enabled the timeout(set it to 60 seconds)

  3. in the GPO I have enabled the Force Specific Screensaver and set screensaver to:

    %windir%\system32\rundll32.exe user32.dll,LockWorkStation

    (also tested this on the command line and it does lock the workstation)

  4. in the GPO I have enabled Password Protect The Screensaver.

I went to a workstation and did a gpupdate /force to refresh the policy and waited the 60 seconds---no dice. Screen did not lock. Same thing after rebooting the computer and after refreshing policy(and rebooting) on a different computer. The GPO is made at the default domain policy level so I know that there should not be any permissions issues or policy override problems. Every computer gets this default domain policy.

Any help solving this issue would be appreciated. I have sorted through the questions on Serverfault and the solutions, but they did not seem to help me. I don't know why this is not working. It seems like it should be.


  • 1
    Run gpresult on one of the machines and look at the report.
    – joeqwerty
    Feb 17 '17 at 19:39
  • 1
    Did you update the Default Domain Policy, or the Default Domain Controllers Policy? Does the container that the computers are in or a parent container have the Default Domain Policy applied? If parent, is inheritance blocked on the container or any container in between?
    – longneck
    Feb 17 '17 at 19:53
  • I updated the Default Domain Policy and it is this Default Domain Policy that has our policy settings. See below :
    – djb387
    Feb 17 '17 at 21:43
  • Why are you specifying %windir%\system32\rundll32.exe user32.dll,LockWorkStation? That is not a screensaver. %systemroot%\System32\scrnsave.scr would be a better choice, and exists precisely for this reason.
    – Greg Askew
    Feb 17 '17 at 23:41
  • 1
    @GregAskew I'm going to have to agree with Greg that the "reason" why it is not working as a GPO---yes, even though it does from a local workstation is "simply" because you need to point it to a "valid" SCR file. Stop trying to fight this problem and simply point it to a "valid" and "existing" SCR file per machine it runs against, and test and then you'll see regardless of which GPO you are using as well; although, I do understand the importance of not packing all GPO's into the same one--especially the default domain policy. Feb 19 '17 at 2:33

Don't go stuffing everything into the Default Domain Policy (DDP) thinking that gives it special powers. You should only configure the Default Domain Policy GPO to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy. (ref https://technet.microsoft.com/en-us/library/hh875588(v=ws.11).aspx especially the heading "Processing GPOs: Precedence") If you make a mistake editing DDP you're in a world of hurt. Much better to have other settings in their own policies so you can unlink them when you have a mistake.

Policies are applied with the following order/precedence:

1) Local machine
2) Site (AD Sites)
3) Domain policy
4) OU


Remove the screen settings from DDP. If you have other policies in place that also assign a screen saver, you need to remove the screen settings from those policies. Because if any of those policies are linked beneath the domain root, they have a higer order of precedence and those settings win. Finally, make a new policy with screen settings and link it to the root of the domain. Use GPRESULT to see which policies are being applied, and/or RSOP to see which policies the effective screen saver settings are being delivered from. Also keep in mind these are USER based settings, so until someone logs on your policy is not used, and the local machine policy still wins.

Sample RSOP

  • I updated the Default Domain Policy. The GPO for this is at the Default Domain Policy level and it is this Default Domain Policy that has nearly all our main policy settings. It should be working. All other policy settings that are set up in the Default Domain Policy are working fine. Just to test, I made another GPO setting change at the Default Domain Policy level(Security Options-Network Security-LAN Manager Authentication Level) and that one seems to have taken. Don't get why this one for the screensaver will not. As far as GPresult goes I ran it but am not sure what I am looking for.
    – djb387
    Feb 17 '17 at 21:56
  • Thanks Craig will try this. So are you saying that the policy on the workstations(basically there is no local screensaver or time out policies set on them) is going to supersede any policy that I make for them on the domain level?
    – djb387
    Feb 17 '17 at 22:00
  • Read about order of precedence, and review other GPO's for screen saver settings. Don't worry about machines where users are not logged on because they're already locked. I didn't need to bring that up in this case.
    – Clayton
    Feb 17 '17 at 22:03
  • Craig I know you say not to do it at the DDP but it is working as expected now. Also we did not want a screensaver to appear, just wanted the computers to lock after a period of inactivity. I don't know what is different now than when I was setting it up before. Maybe the order in which I selected the GPO variables?
    – djb387
    Feb 21 '17 at 22:04
  • 1
    GPO changes take time to replicate and for all clients to refresh and learn of the new settings. By default, clients only refresh GPO once every 90 minutes. If you were not seeing the new settings on clients within the first 90 minutes after the edit, that would be normal.
    – Clayton
    Feb 22 '17 at 2:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.