Planning a Group Policy Strategy

On Overview on Group Policy

Before you can consider to even begin planning a Group Policy implementation in your organization, you have to understand a few important aspects of Group Policy. Microsoft initially introduced group policies in Windows NT to assist administrators in managing the desktop configuration settings of users and computers. Windows Server 2000 included hundreds of Group Policy settings which you could configure. Windows Server 2003 offers all the group policies included with Windows 2000 as well as more group policies, which enable you to use new Windows Server 2003 features. Group Policies can be defined as the groupings of user configuration settings and computer configuration settings which can be linked to container type objects in Active Directory, so that they are applied to users and computers. Group Policy is extremely flexible. It contains options for numerous user and computer configuration settings. This includes options for:

• Computer startup and shutdown
• User logon and logoff
• Registry based policy settings
• Security settings
• Scripts
• Folder Replication
• Application deployment and management

While group policies do after all affect settings in the Registry, the use of Group Policy eliminates the need for administrators to manually change the Registry. A simpler option is to use Group Policy to configure and apply settings.

Group Policy settings can be linked to the following:

• Computers
• Sites
• Domains
• Organizational Units (OUs)

By linking a Group Policy Object (GPO) to a site, domain, or Organizational Units (OUs) in Active Directory, you can apply Group Policy settings to the following Active Directory objects:

• User objects
• Computer Objects

A Group Policy Object (GPO) is the container used to store Group Policy settings in Active Directory. The GPO is then linked to a site, domain or OU, and applied to users or computers within the particular site, domain, or OU. Because a GPO is considered an Active Directory object, you can set permissions on the GPO to control which users or computers can access the Group Policy settings stored within the GPO.

As mentioned already, GPOs can be applied to users and computers by linking GPOs to sites, domains, or OUs. Through Group Policy, you can configure the following types of policies:

• Computer configuration settings: These settings are used to configure policies which affect computers. The user logging on to the computer does not influence whether these settings are applied. Computer configuration settings are applied when the operating system starts.
• User configuration settings: These settings are used to configure policies which affect users. The computer which the user is logging on to does not influence whether these settings are applied. User configuration settings are applied when a user logs on to the computer.

Computer configuration settings and user configuration settings have Software Settings, Windows Settings and Administrative Templates.

Group policies have following setting options:

• Enabled
• Disabled
• Not Configured

A domain in Active Directory has the following default GPOs:

• Default Domain GPO, includes security settings which affect each computer belonging to the domain. The Default Domain GPO is linked to the Domain object in Active Directory.
• Default Domain Controller GPO, includes both security settings and configuration settings which impact domain controllers, and is linked to the Domain Controllers OU in Active Directory.

Because multiple GPOs can be linked to sites, domains, and OUs, they are applied to either the user or to the computer in a particular sequence or order This is illustrated below:

1. Local GPO: A computer running Windows Server 2003 has a local GPO. The local GPO is applied first and therefore has the least precedence when group policies are applied. They are always overridden by Active Directory based GPOs. Active Directory based GPOs are also referred to as nonlocal GPOs.
2. Site GPOs: A GPO linked to a site in Active Directory is applied after the local GPO is applied. Because multiple GPOs can be linked to a particular site, the site GPOs are applied in the order as specified by the Administrator.
3. Domain GPOs: Domain GPOs are applied next, and therefore have higher precedence than site GPOs and the local GPO. Again, when multiple GPOs are linked to a particular domain, they are applied in the order as defined by the Administrator.
4. OU GPOs: OU GPOs have the highest precedence. Group Policy application starts at the top of the tree, and then moves down to the OU containing the user object or computer object.

Group Policy settings are usually passed from a parent OU to a child OU. This is known as Group Policy inheritance. When Group Policy settings are specified for a parent OU, the Group Policy settings are applied to each child OU associated with the particular parent OU. If the same Group Policy setting is specified for a parent OU and a child OU, the setting of the child OU overrides the setting of the parent OU. You can however override Group Policy inheritance to prevent a child OU from receiving the Group Policy settings of its parent OU.

An Introduction to Group Policy Planning

You need to plan for the implementation of Group Policy within your environment before you can implement any group policies. You also need to plan the manner in which you are going to manage group policies once they are implemented.

The first step in planning your Group Policy implementation is to define the requirements of the organization. You need to implement restrictions (Group Policy settings) which are necessary, and which still allow users to perform their daily tasks. You therefore need to be educated on which resources which users need to access. This essentially means that you have to determine the best policy settings for each Active Directory object. Other factors which affect the implementation of a Group Policy strategy include the size and location of the organization, and the manner in which the organization is structured.

When planning the policy settings for Active Directory objects, you should design the structure of the Organizational Unit (OU) so that users and computers which have the least number of restrictions are located high up in the OU tree. Users and computers which should have the most restrictions should be located lower down in the OU tree. This approach implements Group Policy in a tier manner. When creating a Group Policy implementation strategy, remember that the default domain policy should not be changed, other than for setting a password.

When planning the Group Policy implementation, the aspects which should be planned, broadly include the following:

• Group Policy settings
• Group Policy Objects (GPOs)
• Administrative control of GPOs

Remember that Windows Server 2003 includes more than 600 Group Policy settings. To determine which Group Policy settings you need link to sites, domains, and OU, so that they can be applied to computers and users, can be quite a tremendous task. It is therefore imperative that you understand the different Group Policy settings, and the impact of applying these settings. You can use the Group Policy Object Editor to gather information on Group Policy settings.

One approach to use when planning your Group Policy implementation is to create and use a test OU to test the impact of group policies on users and computers. This would typically involve creating the policies, and then testing the impact of these policies on users and computers from different locations in Active Directory. Microsoft provides the Resultant Set of Policy (RSoP) tool which can be used to assist in assessing the design of Group Policy in your organization. You can use RSoP to simulate group policies, and you can then use these to create the actual group policies for your real OU structure. You can also use the RSoP tool to determine the impact of users which are moved from one OU to another OU. The RSoP tool is included in Windows Server 2003.

Factors that should be determined in Group Policy Planning

The factors that should be determined in the planning process of Group Policy are discussed below. When determining the manner in which Group Policy settings should be structured or arranged into GPOs, it is best to focus on the users and computers that need the settings, as the basis for arranging these settings. This basically involves arranging Group Policy settings into GPOs, based on the type of Group Policy settings.

The ways in which you can arrange Group Policy settings into GPOs are listed below:

• Single setting GPO type: With this GPO type, a GPO contains only one type of Group Policy settings. For instance, the GPO contains either only security settings, or only software settings, but never both types of Group Policy settings. The single setting GPO type design works best if your organization’s administrative tasks are task orientated, and are distributed between numerous persons.
• Multiple setting GPO type: With this GPO type, a GPO contains more than one type of Group Policy setting. For instance, the GPO contains both security settings and script settings. The multiple setting GPO type design works best if your organization’s administrative tasks are centralized. It is usually the design when an Administrator has to perform all the different types of Group Policy administrative tasks.
• Dedicated setting GPO type: With this GPO type, one GPO contains user configuration settings, and another GPO contains computer configuration settings.

In addition to this, you can structure your GPOs by using one of the following approaches:

• Decentralized design (layered): The objective in this approach is to have a particular Group Policy setting in as little a number of GPOs. Therefore, when a change needs to be made, the change needs to be implemented in only a small quantity of GPOs. While Group Policy administration is simplified, longer logon times are often experienced by users because numerous GPOs need to be processed. This design works well in organizations where the rate of change is quite frequent, and the various groups within the organization have the same security requirements.
• Centralized design: In this approach, the objective is to utilize as few as possible GPOs. What this means is that all the Group Policy settings for a particular site, domain, or OU in Active Directory are contained in one GPO.

You should include who will manage the GPOs within the organization as part of your planning process. Once again, different design approaches can be used to delegate administrative control of GPOs.

• Centralized administrative control: In this approach, only the administrators of the top level OUs in the tree have administrative Group Policy rights. These administrators are the only ones that have the Full Control permission.
• Decentralized administrative control: In this approach, both the administrators of the top level OUs and second level OUs in the tree have administrative Group Policy rights. Administrators of the top level OUs have the Full Control permission to manage GPOs within the top level OUs, and the administrators of the second level OUs have the Full Control permission to manage GPOs within the second level OUs.
• Task specific administrative control: In ths approach, administrators perform administrative tasks for Group Policy according to which tasks need to be performed. For instance, one administrator would perform security orientated tasks, while another would perform administrative tasks for a different type of Group Policy setting.

When determining which group policies to implement within your organization, your strategy should include the following information:

• User configuration settings,
  • User logon and logoff scripts
  • Smart card authentication (if relevant)
  • Security settings for both software and file restrictions
  • Administrative template restrictions
  • Folder redirection
  • Software distribution for designated users
• Computer configuration settings,
  • Computer startup and shutdown scripts
  • Local security settings
  • Administrative template restrictions
  • Windows settings which control the manner in which the OS will operate
  • Software distribution for designated computers

Identify those users and computers which should be excluded from the scope of certain Group Policy settings,

• Identify administrators that should be excluded from any Group Policy settings.
• Identify which Group Policy settings should have inheritance blocked.

Identify the location at which each necessary Group Policy setting should be applied,

• Identify those policies which should be linked to sites, so that they apply to users and computers within the particular site.
• Identify those policies that should be applied to the users of domains.
• Identify which policies should be applied to each OU within your hierarchy.

Determine the manner in which assigned rights and permissions influence whether Group Policy is applied,

• Identify which security groups would prevent the application of particular group policies.
• Identify which users should have the rights to apply and change group policies within the organization.
• Identify which rights should be granted for users to read and apply group policies within the organization.

If you are going to be using the Resultant Set of Policy (RSoP) tool included with Windows Server 2003 to determine what the RSoP results are going to be for users,

• Utilize test OUs which reflect the actual OUs used,
  • Create test user objects
  • Move test computer objects to the OU
  • Apply all necessary Group Policy settings.
• Verifying the results should include,
  • Logon using a test user object to the OU.
  • Record the results
  • RSoP queries can be utilized to generate Group Policy settings results.

Using RSoP Planning Mode in Group Policy Planning

Windows Server 2003 provides the Resultant Set of Policy (RSoP) tool which includes a planning mode that can be used to query and test policy settings to determine the effects of them on users and computers. This feature is useful in assessing the design of Group Policy within your organization. Before you can open RSoP in planning mode, you first have to add the RSoP snap-in in the Microsoft Management Console (MMC).

To add the RSoP snap-in,

1. Click Start, Run, and enter mmc in the Run dialog box. Click OK.
2. From the File menu, select Add/Remove Snap-In.
3. When the Add/Remove Snap-In dialog box opens, click Add.
4. When the Add Standalone Snap-In dialog box opens, select Resultant Set of Policy from the available list, and click Add.
5. Click Close to close the Add Standalone Snap-In dialog box opens.
6. Click OK in the Ad/Remove Snap-In dialog box.

To open RSoP in planning mode,

1. After adding the RSoP snap-in in the MMC, right-click Resultant Set of Policy, and select Generate RSoP Data on the shortcut menu.
2. The Resultant Set of Policy Wizard launches.
3. Click Next on the Welcome To The Resultant Set Of Policy Wizard page.
4. When the Mode Selection page appears, select the Planning Mode option. Click Next.
5. On the User And Computer Selection page, proceed to:
   • Select a particular user or user container
   • Select a particular computer or computer container

You can use the Browse button to search for a particular user or a particular computer. Click Next.

6. On the Advanced Simulation Options page,
   • Enable the Slow Network Connection checkbox if you want to simulate GPO processing over a slow network connection, such as a dial-up, DSL or ISDN connection.
   • Enable the Loopback Processing checkbox if you want to simulate a loopback processing mode.
   • You can select the site which RSoP should use in the Site list.

7. Click Next.
8. On the Alternate Active Directory Paths page, you can specify a different OU for the user and computer which you have previously selected. This enables you to test the changes which would take place if the user or computer is moved to another location. The page is only displayed if you have previously chosen a particular user or computer. Click Next.
9. The User Security Groups page displays the security groups to which the user is a member of. On this page, for planning, you can select additional groups or remove groups to ascertain what changes will take place. Click Next.
10. The Computer Security Groups page displays the security groups to which the computer is a member of. You can choose additional groups, or remove groups to determine what changes will take place. Click Next.
11. The WMI Filters for Users page shows all linked Windows Management Instrumentation (WMI) filters. On this page, you can choose which WMI filters to utilize on the user or container in the simulation. Click Next
12. The WMI Filters for Computers page shows all linked Windows Management Instrumentation (WMI) filters. On this page, you can choose which WMI filters to utilize on the computer or container in the simulation.
13. When the Summary Of Selections page opens, check that the domain controller listed for the simulation is the correct one. You can click the Browse button to choose a different domain controller for the simulation. Click Next.
14. After the RSoP query has been processed, a Finish page is displayed.
15. Click Finish to view the RSoP window.