I am trying to change the account lockout threshold for all the users on our domain. The threshold should be three, but there are users who get locked out after one mistyped password, and others who can try six or seven times before getting locked out.

We have Windows Server 2008 R2, and all users are on a single domain. In the Group Policy Management, I have tried following the Group Policy path of [GPO]\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy but none of my GPO's (existing or newly created ones) have an Account Policies setting under Security Settings. I have expanded all the different paths looking for it, and I have had no luck. I have also tried doing this from the Server Manager with the same outcome.

I have tried MMC.exe, and GPO's created in this have the correct path, but the GPO's created here seem to be associated only with computers, not with the domain as a whole. I set one up on Local Computer (the server), and it seemed to affect some users, but not others.

I suspect a possible cause (or contributor) to the problem may be a missing SYSVOL file for an Account Lockout GPO. This is a GPO that existed before I began working here, and was disabled by someone trying to fix the lockout issues. I am unsure as to when, why, or by whom the SYSVOL file was deleted/moved. Because the SYSVOL file is missing, I simply get an error saying that the computer cannot find the path specified and I may not have permissions when I attempt to view this GPO.

I have been researching online what to do in this situation, but have yet to come across anything helpful. I would appreciate any solutions or advice, as I am fairly new to this, and running out of ideas quickly.

1 Answer 1


This is could be due to a problem with your default FGPP.
Read this article.
You can see what FGPP applies to a specific user by checking his msDS-ResultantPSO.
You could use Powershell like this:

Get-ADUser -LDAPFilter '(&(objectCategory=person)(objectClass=user)(SamAccountName=JohnG))' -Properties msDS-ResultantPSO

You can correct this by adding the user (or a group the user belongs to) to the relevant PSO (demonstrated by the linked article above).

Also, applying local GPO, generally, is not a good idea.
You should have a policy applied specific on your DCs.

  • Could you add to your answer the steps you suggest to check the ms-dsResultantPSO value and indicate possible corrective action? Jun 4, 2015 at 13:15
  • @Twisty There you go.
    – EliadTech
    Jun 4, 2015 at 13:45

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.