Group Policy Guide — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Order, inheritance, and a test OU

A Group Policy object is a set of settings. A link attaches it to a site, a domain, or an OU. The order of links is the order they apply, and later links can overwrite earlier ones when the setting is the same. Enforcement makes a link win over a block of inheritance below it. Block inheritance stops higher links unless they are enforced. You can explain a design that uses one of those. A design that uses all of them on the first day is a design you will not debug.

The Default Domain Policy and the Default Domain Controllers Policy are poor places for an application setting. They already carry the settings a domain expects. Add a new GPO, link it to the OU that should receive it, and leave the defaults alone. A security filter can limit a GPO to a group. It is a scalpel. Filtering the default domain policy down to one group is how you accidentally un-apply baseline settings for everyone else.

Computer settings and user settings are different halves. A setting in the wrong half does nothing and looks like a replication problem. Loopback is a special case for terminal servers and kiosks, not a switch you flip because a user setting did not apply to a computer.

The precedence calculator and the settings search on this site help you read order and find a setting name. They do not change the domain. gpresult or the results wizard on a test computer is the proof. A setting that is listed and a setting that applied are not the same until you read the result.

One setting on a lab OU

Create a GPO with a boring name that says what it does, such as Lab-Screen-Lock. Link it only to the Lab OU from the Active Directory guide. Put one computer or one user in that OU. Set one setting you can see, such as a screen lock timeout, in the correct half. Do not disable the firewall, do not disable antivirus, and do not set a blank password policy here.

On the test computer, as the test user, read the applied result. The GPO name should appear, and the setting should be the value you chose. If it does not, check the half, the link, the security filter, and whether the computer has refreshed. Forcing a refresh is fine in the lab. Forcing a refresh on every computer in the domain is not the test.

Then add a second GPO on the same OU with a different setting, and read the order. Swap the link order only if you can say which one should win when they collide. If they do not collide, order does not matter and you should not spend the window on it.

Write the GPO name, the OU, the link order, and the one setting in the ticket. Rollback is to unlink, which you do once in the lab so you see the test computer go back.

A change you can finish

Production is the same shape: a named GPO, one OU, one setting or one tight group of settings, a test object, a result, then a wider OU in a later window. The domain root is not the first link.

Rollback is unlink or a link disabled, not a delete of a GPO you might relink. Deleting is later, when nothing links it.

Name the GPO for the outcome, not for the person who built it.
Link it to the test OU only.
Set one visible setting in the correct half.
Read the applied result on the test computer.
Confirm you did not edit the Default Domain Policy.
Unlink in the lab and confirm the result goes back.
Only then plan the wider OU as a separate change.

Mistakes that outlive the command

Group Policy fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Editing the Default Domain Policy for one application.
A security filter on a baseline GPO that then stops applying to most computers.
Block inheritance and enforce on the same day, with no drawing.
A user setting when you needed a computer setting, or the reverse.
Loopback on ordinary desktops.
Disabling the firewall or antivirus by policy to make a test pass.
Linking at the domain because the OU design is unfinished.
Judging success from the editor instead of from a computer's applied result.

Decisions to write down before the window

One decision for Group Policy: The GPO is new. The two default policies are unchanged. The first link is a test OU. The domain root is a later decision. One setting, correct half, visible on the test object. Link order is written down only where two GPOs set the same thing. Security filtering is a named group, and the authenticated-users or computer read permission still allows the GPO to be read. Enforce and block inheritance are off unless the ticket draws them. Nothing in the GPO disables the firewall, antivirus, or updates. The applied result was read on the test computer, not assumed from the console. Rollback is unlink, and you have done it once. A wider rollout is a new window. And a second person read the OU link aloud.

Group Policy checks before the link leaves the lab OU

Confirm this before you call the change done: The GPO name matches the ticket. It is not the Default Domain Policy or the Default Domain Controllers Policy. The link is the lab OU and no higher. The applied result on the test computer shows the GPO and the value. The setting is in the half you intended. No firewall, antivirus, or update setting was weakened. Enforce and block are off, or drawn in the ticket. Unlink restored the previous result in the lab. Security filtering still lets the target read the GPO. Link order is recorded if two GPOs overlap. A second person saw the applied result. The wider OU is not linked yet. The AD guide's OU path matches this link. The hostname in the prompt matches the hostname in the ticket for Group Policy. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for Group Policy happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Windows Server Hardening Checklist.