In a company that has a domain but doesn’t use Group Policy properly, every computer has its own story: one has no screen lock, and on another the user has installed whatever software they like. Group Policy turns this disorder into a set of central, consistent and controllable policies.
How does Group Policy work?
Each set of settings is created as a GPO (Group Policy Object) and linked to a site, a domain or an OU. Every GPO has two parts: Computer Configuration, applied when the computer starts, and User Configuration, applied when the user logs on. The order in which policies are applied is abbreviated LSDOU: local policy, site, domain and finally OU. If a setting is repeated at several levels, the level closest to the user or computer, the OU, usually wins.
- Enforced: A policy that is Enforced cannot be overridden by lower levels.
- Block Inheritance: Prevents policies from higher levels from being inherited by an OU; use it with caution.
- Security Filtering: Limits a GPO to specific groups.
Principles of a tidy structure
- The main tool is the Group Policy Management console (
gpmc.msc); create and link your GPOs from here. - Create one GPO per purpose with a descriptive name, such as
WS-Security-BaselineorUSR-Drive-Mapping, instead of one large GPO for everything. - The default
UsersandComputerscontainers are not actually OUs, and GPOs can’t be linked to them; move users and computers into your own OUs. - Keep only password, account lockout and Kerberos policies in the Default Domain Policy, and put all other settings in separate GPOs.
- Create a Central Store so all administrators use the same ADMX template files; its path is
\\domain\SYSVOL\domain\Policies\PolicyDefinitions.
Practical policies to start with
- Automatic screen lock: After a few minutes of inactivity, the screen locks with a password.
- Removable storage restrictions: If needed, use the Removable Storage Access settings to block USB flash drives or make them read-only.
- Network drive mapping: Use Group Policy Preferences to map drives based on the user’s group; old logon scripts are no longer needed.
- Windows Firewall: The firewall stays on for all computers and users can’t turn it off.
- Audit policy: Log events such as failed logons and account changes so there is a trail when an incident occurs.
- Application restrictions: With AppLocker or similar tools, you can restrict running programs from folders such as Downloads; the available features depend on your Windows edition.
Test every new GPO first on a test OU with a few computers and users. One wrong setting at the domain level can affect the whole company within minutes.
Troubleshooting: why wasn’t the policy applied?
- Use
gpupdate /forceto refresh policy application on the computer. - The
gpresult /rcommand shows which GPOs were applied and which were filtered out; for a full report, usegpresult /h report.html. - Check that the user or computer is actually in the right OU and that the GPO is linked to that OU.
- If you changed Security Filtering, make sure the Authenticated Users or Domain Computers group still has Read permission on the GPO; otherwise the policy won’t apply.
- DNS problems and SYSVOL replication issues between domain controllers are also common reasons policies fail to apply.
Common mistakes
- Adding every setting to the Default Domain Policy
- Undocumented, unused GPOs left in place for years
- Careless use of Enforced and Block Inheritance, which makes policy behavior unpredictable
- Having no backup of your GPOs; you can back them all up with
Backup-GPO -All -Path D:\GPOBackup
Checklist
- Users and computers are in defined OUs.
- Every GPO has a descriptive name and a description.
- The Default Domain Policy contains only account policies.
- A Central Store has been created for ADMX files.
- New policies are tested first on a test OU.
- GPOs are backed up regularly.
If your domain’s GPOs are a mess or you want to implement standard security policies, ITPlus724 engineers can review and redesign your company’s Group Policy structure.