Group Policies Objects (GPO’s) are one of the most common, and most powerful tools in Active Directory. GPO’s are used to configure nearly every aspect of network control, yet there is a great deal of pain and suffering introduced by less-than-perfect policies.
With a few simple rules, you can reduce the headache factor, while making your job easier, and making you better at it.
Brevity is the Key
If you can’t describe what you want the policy to do, in ONE sentence, then you’re not ready to create the GPO. Vague design goals create extremely convoluted logic knots that can be difficult or impossible to resolve. Keep rephrasing until you can get it into one simple sentence.
Fewer GPOs mean simpler logic to troubleshoot, but each GPO will be more involved.
More GPOs mean simpler policies, but more complex logic.
Documentation
Each GPO should have its purpose clearly stated in the notes for the GPO. The name of the GPO should reflect its intent, as you will sometimes have nothing more to go by, than the name.
Each GPO should also list the responsible parties to contact, should a situation arise. This will include the GPO author, but should also include the management responsible for requesting the original GPO.
With these names and contact information available, questions regarding the GPO can be directed to the correct party.
Any proposed change to a GPO should be documented, listing the requested change of function, the party requesting the change, and contact personnel for further questions.
Testing
GPOs should NOT be tested in the production environment. Mistakes introduced by the GPO can spread through the entire forest before anyone could spot the problem.
Your Development environment is where GPOs should be tested first. This network should represent your best-effort at reproducing the production environment. It can be prohibitively expensive to reproduce all the hardware on the production network, but today’s virtualized environment makes producing a copy of the production network possible.
It won’t be an EXACT replicate of the production network, but close enough to test for most aspects. Anything that needs to speak with specific hardware, will NOT produce reliable results when tested on a virtualized environment.
Once the tests have passed in development, then you can move on to pilot groups. These are populations who will first test the changes on the development network, but only on a small subset. Choose users who are amenable to testing. They are usually easy to choose: eager tech enthusiasts, power users, members of the IT/HelpDesk team.
By testing on these users first, you can minimize the consequences of an error. The only affected users, will be the pilot group. Once the changes have passed testing in this group, you’re ready to port to production.