Group Policy – Good practice

Recently we have had a spate of work involving cleaning up AD…. due to what can be best described as “messy” behaviour – especially around group policy.

Group policy is a great configuration tool for your enviornment – so it is very beneficial if it is kept clean!

In no particular order:

• KISS – keep it simple stupid
• Design a good OU structure
  • A good OU strcuture will only be 2 or 3 OU’s deep
  • OU’s are only used for 2 things – delegation of authority and applying group policy
  • OU’s do not have to represent the business strcuture or physical locations – see the above point
  • Remember, group policy can be applied to sites as well as OU’s… so if you have location specific policies, this does not mean you need a static OU to represent locations
  • Think “Do i need to apply different policies to these computers” – if the answer is yes, then have a different OU, if the answer is no, then put them in the same OU (and dont worry about the future – its not exactly hard to drag and drop objects between OU’s!)
• Avoid using block inheritance and enforced settings. If you think you have to use them – its more likely that your OU structure is poor than you actually have to use them
• If you need to filter group policy, remember that you have WMI and group filtering at your disposal, this is often better than creating another OU
• Keep the number of GPO’s to a minimum – each additional GPO has to be evaluated by clients – even if it does not apply to them
• Maintain a naming convention, so it is clear what each policy does, or where it applies, e.g
  • Computer – Default settings
  • User – Default settings
  • WSUS – Adelaide Site
• Place computer and user settings in different policies and disable the part of the policy not in use
• Never have the same settings in two different policies, if the same settings need to apply to multiple sets of users/computers, make a GPO for it and link it to multiple locations
• Be careful with loopback policies…. applied incorrectly (as they so often are) they can significantly impact client performance
• Generally, leave the default domain and default domain controller policies alone….  sure, put your password policies etc in here…. but dont go putting IE settings or office customisations in there
• Always edit your policies on the latest version machine…. e.g. Windows 2008 R2 or windows 7…. while editing policies on 2008 R2 then on XP can work – you need to ensure the policy templates are the same versions…. so quite frankly, its just easier to make a rule to say “only edit policy on 2008 R2/Windows7)
• If you have many people that can administer group policy – and change control/rollback etc is required, look at AGPM from MDOP…. if your company has SA with Microsoft, you will be able to purchase MDOP as well….AGPM allows versioning, approval, audit trails etc…. very handy stuff for if you have more than 2 or 3 people diting policy (expecially if not all the people are competent!) (offical marketing wank speak version – http://www.microsoft.com/en-us/windows/enterprise/products-and-technologies/mdop/agpm.aspx)

Obviously these rules aren’t applicable everywhere…. there are large enviornments where block inheritance is valid, there are times you do combine user and computer policies – but these should only occur after other avenues have been ruled out.

Anyhoo – hope that helps someone out there… preferably not in Adelaide, as it will reduce the flood of work we have at the moment from doing this 🙂