Export (0) Print
Expand All

Determining the Number of Group Policy Objects

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The number of Group Policy objects you need depends on your approach to design, the complexity of the environment, your objectives, and the scope of the project. If you have a multi-domain forest, or multiple forests, you might find that the number of GPOs required in each domain is different. Domains supporting highly complex business environments with a diverse user population typically require more GPOs than smaller, simpler domains.

As the number of GPOs required to support an organization increases, so can the workload of Group Policy administrators. There are steps you can take to ease the administration of Group Policy. In general, you should group settings that apply to a given set of users or computers and are managed by a common set of administrators into a single GPO. Further, if various groups of users or computers have common requirements, and only a few of the groups need incremental changes, consider applying the common requirements to all these groups of users or computers by using a single GPO linked high in the Active Directory structure, and then add additional GPOs, which apply only the incremental changes, at the relevant OU. This might not always be possible or practical, so you might need to make exceptions to this guideline. If so, be sure to keep track of them. Note that a maximum of 999 GPOs is supported for processing GPOs on any one user or computer. If you exceed the maximum, no GPOs will be processed. This limitation affects only the number of GPOs that can be applied at the same time; it does not affect the number of GPOs you can create and store in a domain.

Consider that the number of GPOs applied to a computer affects startup time, and the number of GPOs applied to a user affects the amount of time needed to log on to the network. The greater the number of Group Policy objects that are linked to a user — especially the greater the number of settings within those GPOs — the longer it takes to process them whenever a user logs on. During the logon process, each GPO from the user’s site, domain, and OU hierarchy is applied, provided both the Read and Apply Group Policy permissions are set for the user. In GPMC, the Read and Apply Group Policy permissions are managed as a single unit called Security Filtering.

If you use Security Filtering and you remove the Apply Group Policy permission for a given user or group, also remove the Read permission, unless you need that user to have read access for some reason. (If you are using GPMC, you need not worry about this, because GPMC does this for you automatically.) If the Apply Group Policy permission is not set, but the Read permission is, the GPO is still inspected (although not applied) by any user or computer that is in the OU hierarchy where the GPO is linked. This inspection process increases logon time slightly.

Always test your Group Policy solution in a test environment to ensure that the policy settings you define do not unacceptably prolong the time it takes to display the logon screen, and that they comply with desktop service level agreements. During this staging period, log on with a test account to gauge the net effect of several GPOs on objects in your environment.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft