Optimizing Group Policies

markdmac's Enterprise Ready Login Scripts

Optimizing Group Policies

By Mark D. MacLachlan, The Spiders Parlor
http://www.thespidersparlor.com

How many times have your users complained that login takes too long? Maybe your users are not complaining but you have noticed it yourself when troubleshooting a users desktop.

This brief FAQ will offer some advice to help slim down your login process by better optimizing your Group Policies.

Proper planning is of course the most important thing you can do when designing your AD structure and your GPO implementations. Over time it is natural that GPOs will come and go through attrition.

There are many schools of thought when it comes to group policy implementations. This FAQ will attempt to present the reader with different options and will attempt to present pros and cons for implementing GPOs. I think it only fair to state that there is no right or wrong answer here on what would be best in your environment.

One school of thought is that to optimize login times you should not set security permissions on a GPO and should instead apply the GPO at the OU level. When another OUs users need the same settings, link the GPO at that OU as well. I must concede that this can enhance login time by limiting the amount of processing that must be done, however my experience is that this is a minimal savings in time and simply adds complexity to the environment. I would caution any administrator when linking a GPO to several OUs that care must be taken when modifying the GPO as all changes will be made to all OUs using the GPO. This may not be evident and can cause unexpected results. Furthermore, I find it a best practice to add DENY rights under APPLY POLICY to the Administrators ID to ensure that I don't accidentally lock out the admin ID. You can imagine how bad it would be to configure a user policy that prohibits opening Registry Editing Tools or MMC and having that get applied to the Admin ID. How would you undo the changes when you can not go back into MMC to fix it?

Another method of optimizing GPOs is to turn off either the User Configuration or Computer Configuration if not being used. I subscribe to this thought process and take it a step even further. (more detail to follow) Shutting down half of a policy will provide a performance boost when processing a GPO. When designing your GPO, try to separate User and Computer settings into different GPOs so you can disable unneeded settings.

Lets take minimizing a GPO to the next level though! Right out of the box a new GPO is about 2MB in size. Browse your SYSVOL\Policies directory to verify this. Why so big when all you did was set one setting you might wonder? Well, by default every policy has a number of Administrative Templates included in it. Removing the Administrative Templates that are not needed will drastically reduce the size of your GPO and in doing so greatly speed up the time it takes to:
[green]
A: Replicate between Domain Controllers
B: Push down to client PCs
C: Process on the client PC.
[/green]
So how do you remove an administrative template? First expand out the Administrative Templates section of the GPO. You will find this in both the User and Computer Configuration sections. Note that removing a template from one section removes that template from the other section as well. You won't hurt anything by removing a template from a policy (though you can loose settings if you remove a template that was being used). The original templates are located in the Windows\Inf folder in case you need to add one back.

I like to remove ALL of the templates and create my own CUSTOM ADM files. By doing this I can often reduce a policy from 2MB down to 22KB. Furthermore my custom template makes it a lot easier to see what has been configured in a policy since it only shows the settings I have chosen to configure. Configuring a custom ADM file is easy. The only software you need is Notepad. I prefer to open up a copy of System.adm as a reference and build my own template by copying information from the reference file.

Basic structure of an ADM file.
Before you start coding your own ADM files, you need to understand their basic structure. Opening up System.adm will give you a good idea of it, but here are the basics. Those administrators familiar with HTML will find this easy to follow. You basically have open and closing tags for policies. Additionally there are section tags that indicate where the User Policy, Computer Policy and Strings sections start. This is the first mention of a Strings section so let me briefly explain that. The strings section helps to translate a policy to the text that is displayed within the MMC window. Failure to include a policy element name in the strings section will result in an inability to load that template in MMC. Fortunately if you do mess that up, MMC will provide a useful error that identifies what was not identified. I must confess, I've had to use this error testing as my best troubleshooting method when creating a new ADM file.

At this point a simple example might be helpful.

Explaining all the aspects of the above is beyond the scope of this FAQ. If you study the sample ADM file you will see that what I have done is extended the selection options for hiding hard drives from a user over and above the choices that Microsoft provides in the standard GPO. As a matter of fact, you can hide ANY combination of drive letters by modifying this ADM file. But I digress....

OK, so by now you are starting to see that you can drastically reduce your GPO sizes by removing unwanted sections and further reduce the size and management complexity by taking the time to make a custom template. Now let us briefly turn our attention to the overall GPO design.

Some people prefer to have a single GPO to manage. I find that having settings spread all over the place within a single GPO is difficult to visualize. Instead I prefer to use an "a' la carte" design. I prefer to use a number of well named and highly streamlined GPOs to configure my environment.

For example, some GPOs I would set up:
IE Policy With Internet
IE Policy Intranet Only

These two GPOs would no doubt be almost identical except that the Intranet Only would configure the clients to not allow Internet Access. I'd most likely still be setting the rest of IE to be the same. So I would suggest introducing a third GPO:
IE Policy Common Settings

This third policy would probably have all Administrative Templates removed and would provide configuration information for all settings common to both my Internet and Intranet users. My other two GPOs would only include what was different. If ever I need to make a change, I only have to go to one place to make the change.

Over the course of my career I have experimented with different OU and GPO models and found this method to be the easiest to manage and the most efficient for replication and processing.

I will close with one final bit of information. When AD is first created, a Default Domain Policy is created. It is very important that Administrators not use this policy for any settings other than setting password policies. A corruption of this policy can cause a great deal of trouble. Microsoft has even created tools to recreate the default policies after so many people either intentionally or accidentally deleted the default domain policy. Stay clear of these polices, create your own and have fun.

I hope you find this information helpful. I strive for nothing less than ratings of 10 on my FAQs. Before you vote, if you feel this FAQ does not rate a 10, please submit a question to me and provide feedback. If you are looking for the FAQ to cover more ground I'd like to know what areas you were interested in. Don't forget to check out my other FAQs in this forum.