When designing a strategy for Group Policy, you need to consider several issues. The planning issues that require consideration are the delegation of administration, the application of GPOs (or at what levels of the Active Directory hierarchy), the use of security for filtering, and the modification of inheritance. Designing the Administration of Group Policy ObjectsOne of the most important factors to consider when designing a group policy implementation is the delegation of administration. In other words, who will be responsible for administering the various GPOs and what that person's scope of authority will be. It's important to design the GPOs in a way that enables the current IT organization to manage them easily. Some sort of standard should be set in place so that the creation and organization of GPOs can remain consistent throughout the network. When you design group policies, you need to consider how administration is distributed throughout the network (centralized versus decentralized). You also need to determine who will be responsible for administering the GPOs and the scope of that person's administrative permission. When organizing GPOs, you have basically three options: single policy, multiple policy, and dedicated policy. Keep in mind that the implementation you choose will affect a number of things, including the maintainability of the GPO, the logon times as Group Policy is processed, and the ability to delegate GPO maintenance tasks.
When designing group policy, also take into consideration which users or groups will be assigned delegation of control over the GPOs and the type of permissions they will require. Will the users or groups be given the right to create new GPOs, modify existing policies, and link policies between sites and domains, or will they be given full control? The type of permissions assigned to users will again be determined by how the business currently distributes administrative tasks. Administrative tasks for GPOs can be grouped into three different general categories: creating, modifying, and linking. Here are some questions to keep in mind when planning the administration of GPOs:
Obviously, the permissions that a user is assigned over a GPO determine the scope of that user's administrative control. Remember to follow the principle of least privileges and assign only the necessary permissions for a user or group to carry out a job. Designing the Deployment Strategy of GPOsGroup policy objects can be linked to any of the three levels within the Active Directory hierarchy. The level at which a GPO is linked determines its scope. In other words, where in the hierarchy the GPO is linked determines the number of users and computers that are affected by the policy settings. For example, linking a GPO to a domain affects more users and computers than linking it to an OU within the domain. To deploy group policies effectively, it's important to understand the effect that a GPO has when it is linked to a certain level in the Active Directory hierarchy. Linking a group policy at the site level would have a different effect than linking a group policy at the OU level. The needs of the business will determine where group policies should be linked in the hierarchy. Site LevelThe first level at which a GPO can be linked is the site level. A GPO linked at the site level affects all users and computers within those particular IP subnets. You might be asking yourself why you would ever want to link a GPO at this level instead of applying it at the domain or OU level. Linking a GPO at this level allows a business to take advantage of the physical connections within and between groups of subnets. To take advantage of the high-speed connections within a site, administrators can choose to create a GPO for publishing applications and link it at this level. For example, a GPO can be linked to specific sites so that users do not have to install applications over a relatively slow WAN link and the high-speed connections within the site can be utilized.
Domain LevelThe next level in the Active Directory hierarchy to which a GPO can be linked is the domain level. When a GPO is linked at this level, it affects all the users and computers that belong to that particular domain. For example, if an organization requires that all computers within a domain have the same specific type of background on their workstations that included the company logo, a GPO could be linked at the domain level. When applying a GPO at this level in the Active Directory hierarchy, you need to be aware of a couple of issues. One of the reasons that OUs are created is to delegate control over their contents to another user or group. When a GPO is linked at the domain level, all the OUs within the domain inherit the policy settings. The policy has to be administered at the domain level, and authority over the policy cannot be delegated to administrators responsible for administering the OUs. In other words, the delegation of authority has to be done at the domain level. The administrators of the different OUs will have no administrative control over the policy. Also keep in mind that when a policy is linked to a parent domain, the child domains are not affected by the policy. Policy settings are not inherited from parent domain to child domain.
If the child domains require the same Group Policy settings, you have two options. The first is to link the GPO to the child domains. The only problem with linking GPOs across domain boundaries is that doing so increases traffic because the policy must be retrieved from another domain. This becomes a major concern if the link between the domains is slow. The preferred method is to create another GPO with the same settings and apply it to the child domain.
OU LevelThe third level at which a GPO can be linked within the Active Directory structure is the OU level. Linking GPOs at this level provides administrators with the most control. Users and computers can be grouped together into an OU, and a GPO can be created and linked to that OU.
One advantage of linking a GPO at this level is that delegation of authority over the GPO is still possible without giving the user or group privileges throughout the domain. This allows an organization to maintain a decentralized administrative model. Keep in mind that GPOs don't have to be linked at a single level only. They can be linked at all three levels within the Active Directory hierarchy. It's important to understand how GPOs are processed when multiple policies are linked throughout the hierarchy: The GPO that is processed last overwrites settings applied by the other GPOs. Here are some key points to remember:
Other Group Policy Design IssuesBy using filtering and inheritance modification, you can change the way in which a GPO is applied. By default, all objects within a container are affected by a group policy that has been applied. However, there might be instances in which not all objects should be affected by the group policy settings. In such cases, filtering can be used. Filtering enables an administrator to exclude certain groups from being affected by a group policy by limiting the scope of the policy. When you filter a GPO, you exempt a group from the settings within the policy.
The group policies that are linked to an Active Directory object affect all users who have the Apply Group Policy permission for the GPO. This is the default permission given to all users for a GPO. That means all users are, by default, affected by the policy. To change the scope of the GPO and exclude certain users from being affected, simply create a security group that contains the users who need to be excluded and remove the Apply Group Policy permission to the GPO. If the policy applies restrictions to the users' computing environment, some of the restrictions might not be required for administrative purposes. In that case, a filter could be applied to exempt those users responsible for administration of the OU from the policy. To filter by using security groups, do the following:
In some instances, a GPO linked to a parent object should not be linked to its child objects (remember that a GPO linked at the OU level is inherited from parent object to child object). In such a case, blocking inheritance can prevent the GPO settings applied to a parent OU from being applied to a child OU. Using a feature called block policy inheritance, the inheritance of a GPO can be modified so that it is not passed on from parent container to child container. Any policy applied at the domain or OU level can be blocked. The Block Policy Inheritance setting is not applied to the GPO itself but rather to the domain or OU that should be exempt from the policy settings. All policy settings are blocked, not just those from a single GPO. Use the following steps to block the inheritance of a GPO:
The only time that the Block Policy Inheritance option will be ignored and the policy will still be applied is when the No Override option is set. No Override means exactly that. If the No Override option is set, any group policies linked to a parent object will be applied to the child objects regardless of whether the Block Policy Inheritance option is set. This option prevents any other GPO from overwriting the settings contained within it. Any GPO link that has the No Override option set will not be overwritten by another policy. Use the following steps to specify the No Override option:
|