Group Policy Overview

Group Policy has proven to be one of the most widely used Active Directory technologies, and at the same time, one of the most misunderstood and misused. Many administrators have taken advantage of GPOs in order to control the security of systems and to distribute software to users and computers but do not fully understand the options that are available when using GPOs. Understanding the settings that can control security, restrict user sessions and desktops, deploy software, and configure the application environment should be the top priority when you are using GPOs. Options that affect how the GPOs are applied need to be understood as well; some of the options we will discuss include blocking inheritance, enforcing settings, applying settings to specific users or systems, and filtering out the accounts that do not need to have settings applied to them.

To make your job much easier, Microsoft has introduced a freely downloadable utility: the Group Policy Management Console (GPMC) . The GPMC simplifies the task of administering the GPOs used within your organization. From one location, all of the GPOs from any domain in any forest of the organization can be controlled and maintained . You can download the utility from Microsoft s website. As you can see in Figure 6.1, once this utility is installed on a system, the Group Policy tab on the properties page of a site, domain, or OU will no longer show the GPOs linked at that object. Instead, a button to open the GPMC appears there. The GPMC is added to the Administrative Tools menu also.

Figure 6.1: The Group Policy tab after the Group Policy Management Console is added.

Note	For more information about the Group Policy Management Console and how to download your copy of this tool, go to http://www.microsoft.com/windowsserver2003/gpmc/default.mspx .

Do note that the GPMC will only function on Windows XP and Windows Server 2003 operating systems. Any administrators within the organization who need to use this utility will require a workstation running Windows XP or else they will need to work from a server where the GPMC has been added. Figure 6.2 shows the GPMC. Notice how the group policies are all organized beneath the Group Policy container. This allows you to go to the container and work with any of the GPOs that you are using in Active Directory. Also note that the domain and all of the sites and OUs are organized within the console so that you can see where of the GPOs are linked.

Figure 6.2: Group Policy Objects within the GPMC

Of course the real power of the GPMC is the ability to run sample scenarios and to determine which GPOs are being applied to a user or computer. As you are designing the GPOs that will be used within the organization, take the time to test the effects the GPO will have on users and computers when applied in conjunction with other GPOS. Figure 6.3 shows an example of the GPMC s Group Policy Modeling section.

Figure 6.3: Group Policy Modeling

In the following sections we are going to take a look at what the company wants to use GPOs for. This will include the security needs, software installation options and user restrictions that will be used to control the user s environment.

Understanding the Company s Objectives

Before sitting down and designing the OUs that you will use for implementing GPOs, you must understand the needs of the organization. Although every Active Directory rollout will have password requirements, lockout restrictions, and Kerberos policies applied, that is usually where any similarities between organizations end. The first thing you should do is document the administrative structure of the organization. The previous chapters within this book have dealt with designing and documenting the administrative responsibilities, and you should have a good idea of how the OU structure is going to look from Chapter 5.

Base your Group Policy design on this administrative design as much as possible. Most organizations find that if they create their OU structure based on the administrative functions, the Group Policy requirements follow along pretty well. Although you may still have to build OUs for special purposes, the basic design should already be put into place. The special purposes could include special software that a subset of users from a department need to use, or restrictions on the systems that temporary employees will have.

A good Group Policy design starts with defining exactly what actions GPOs will perform for your organization. Because GPOs are primarily an administrative tool, you can ease some of the administrative load from the staff and allow the system to control users environments. Some of the areas that can be controlled are security, software installation, and user restrictions.

Identifying Security Needs

One of the first types of settings that will need to be determined are the security settings that will be enforced for users and the systems to which they connect. When Windows Server 2003 is configured as a domain controller, the security policy for the domain requires users to use strong passwords , which are password that do not use words that can be found in a dictionary and utilize several different types of characters . Microsoft has identified strong passwords as those that follow these guidelines:

Are at least seven characters long
Do not contain your username, real name, or company name .
Do not contain a complete dictionary word.
Are significantly different from previous passwords. Passwords that increment ( Password1 , Password2 , Password3 ...) are not strong.
Contain characters from at least three of the following four groups:
- Uppercase letters , such as A, B, and C
- Lowercase letters, such as a, b, and c
- Numerals, such as 0, 1, 2, and 3
- Symbols found on the keyboard (all keyboard characters not defined as letters or numerals), including the following:` ~ ! @ # $ % ^ & * ( ) _ + - = { } [ ] \ : " ; ' < > ? , . /

Training users on the proper methods of creating and using passwords can prove to be difficult. For instance, turning on the complexity requirements that force a user to have strong passwords usually ends up with the user writing their password down on a piece of paper or a sticky note and placing it close to their computer. You should implement corporate standards that identify how passwords should be protected and the ramifications of not following the policy. Of course, training the users and explaining the reason passwords are a vital defense mechanism can aid in the acceptance of the password policy.

Account lockout restrictions are another defense mechanism that should be used. Any time a brute-force attack is made against an account, the account lockout policy prevents the attackers from being able to make too many attempts at discovering the password. Most companies have this setting configured to allow between three and five attempts before the account is locked. Once it is locked, the attacker does not have the ability to try any additional passwords against the account for as long as the account is locked. This brings us to the second part of account lockout restrictions: you should always leave the accounts locked until an administrator unlocks them. Although this increases the administrative load to some extent, and more times than not the lockout is due to the user forgetting their password or having the Caps Lock key turned on, at least the administrator is notified of the possible attack. And just to make sure that you are not allowing an unauthorized user access to another user s account, you will need to put procedures in place that will help you identify the user who needs their account unlocked. This is especially true if they call to have their account unlocked and they mention that they cannot remember their password. Before changing the password, you will need to authenticate the identity of the user.

Aside from the account policies that can be set, other requirements also need to be identified. For instance, you may have users who need access to servers that hold confidential information. If users need to use an encrypted connection when accessing the data, you can specify the Internet protocol security (IPSec) policies that will be enforced by using GPOs. For example, if a user within the Payroll department needs to modify the salary and bonus structure for an employee, and the employee data is hosted on a server that you want to make sure is only accessed when IPSec communication is used, you can create an OU, IPSec Servers, for the payroll departments server and any other servers that require IPSec communication. You can then create a Group Policy object for the IPSec Servers OU that enforces the Secure Server IPSec policy and apply it to all servers in the IPSec Servers OU. Another OU can be created for the workstations within the Payroll department, Payroll Clients OU. The Group Policy object that is defined for the Payroll Clients OU could have the Client IPSec policy assigned to it, which would turn on IPSec communication whenever connecting to the Payroll servers, or any server that requests an IPSec channel.

Note	For more information on security, see Exam 70-293, Planning and Maintaining a Microsoft Windows Server 2003 Network Infrastructure , by Susan Sage London and James Chellis (Sybex, 2004).

Identifying Software Installation Needs

Using GPOs to roll out software can drastically reduce the administrative efforts required to install and maintain software within the organization. At the same time, it can increase the load upon the network to a point that is not acceptable. You need to determine if the benefits gained from having automated installation of software outweigh the network overhead required. Of course, no matter how much you may want to use GPOs to push software to client machines, some instances will occur when the network infrastructure will not allow it. This is especially true if you use wide area network (WAN) links between locations and the software distribution point is located on a server on the other end of the slow link.

A Service Level Agreement (SLA) could affect the rollout of software. SLAs are contractual obligations that dictate the amount of service availability that is required for servers or workstations. In some cases, software can take several minutes to install. If SLAs are in place and they restrict the amount of time that it takes to install an application, you may be forced to manually install the application for the user during times when they are not using the system. Another alternative is to link the GPO after hours and have the software installation assigned to the computer. Due to the fact that the software installation client-side extension is not included in the periodic refresh of GPOs, any changes that you make to the software installation options within a GPO are not processed on the client. Using remote access tools, you could then restart the user s computer, which would initiate the installation of the software.

If you determine that you are going to assign or publish applications to users or computers, you need to identify which applications are required. Most applications written by commercial software vendors within the last few years take advantage of Microsoft s IntelliMirror technology and are supported by Group Policy. Make sure the software is stamped with Microsoft s seal of approval. If Microsoft has certified the software to run on Windows Server 2003, the application will support IntelliMirror.

Work with each department within the organization to determine their software requirements. Understanding the software needs of the organization helps you identify which software packages need to be rolled out through a GPO. You may need to make some trade-offs. If every user within the organization needs to have a specific application such as antivirus software, it may be easier to create a system image that includes that operating system and the software. Using a third-party disk imaging utility, you can create a generic image of a system that includes all of the software and the appropriate system settings for the organization. Whenever the tech staff builds a new client system, the image is placed on the hard drive of the new computer, and when the computer is rebooted, it is configured with the default settings and software. This is a very quick and usually painless method of getting systems online in short order. However, you will encounter some drawbacks.

If devices on the new hardware are not supported at the time the image was originally created, the new hardware may not start up correctly and you will be left trying to install the correct drivers. As new software packages are identified as required for the organization, you may have to rebuild the image to support the software, which then brings us back to the advantages of Group Policy software deployment. Although operating systems cannot be deployed through a policy (that is a function of Remote Installation Services [RIS]), new and updated software can be. Of course Microsoft Systems Management Server (SMS) will also roll out software to client machines, and will do so with more efficient management options. One of the benefits of SMS that Group Policy has yet to implement is the ability to push the software package out at a predetermined time.

After determining which of the deployment options you are going to use, you then need to determine which software packages are going to be rolled out with Group Policy and how you are going to accomplish this.

Identifying User Restrictions

User restrictions limit what actions a user can perform on their workstation or control the applications that are allowed to run. For some companies, not many settings are required. The users have control over their workstations and the administrators may only control the account policies that are put into effect with the Default Domain Policy , which is where the password requirements, account lockout settings, and Kerberos policy settings are configured. Other companies take full advantage of using GPOs to restrict their users from being able to access any of the operating system configuration options. Some companies even force all of the systems to have the corporate background.

As extreme as it may sound, the fewer configuration options that a user is allowed to access, the less the user can affect, and possibly change for the worse . Desktop restrictions can remove the icons for My Computer and My Network Places, or can change what the user sees from the context menu when the right mouse button is used on these icons. The Display properties can be locked out so that the user cannot choose a monitor refresh rate or screen resolution that is not supported by the video subsystem. Start menu items can be restricted so that the user does not have the ability to open the Control Panel and modify settings within the operating system.

Note	For more information about Group Policy and the settings that you can use to control a user s environment, see the Group Policy section within the Windows Server 2003 Technical Reference on the Microsoft website.

You should identify which operating system configuration settings the users within the organization really need to work with, and how much power they need to wield over their workstations. Whereas it may take you a little longer to plan out the Group Policy settings that need to be applied to groups of users, the administrative headaches that these restrictions will alleviate will be worth the trouble. As you are designing the Group Policy settings that will be used to control and assist the administrative structure, remember the golden rule: keep it simple.

Creating a Simple Design

The underlying design goal, aside from supporting the organization s objectives, should be to create a Group Policy design that is as simple as possible. A simple design will allow for more efficient troubleshooting and processing of Group Policy settings. The fewer Group Policy settings that need to be applied to a computer or user, the faster the computer will start up, the quicker the users will be able to log on to their systems and, since a small GPO can be 1.5 MB in size , network traffic will also be reduced. If problems arise due to Group Policy conflicts or inappropriate settings, if the design is simple, it is easier for an administrator to troubleshoot the problem.

When determining the best and most efficient use of GPOs, you should review the requirements of the users who will be affected and then try to consolidate settings into the fewest number of GPOs possible. Then make sure you are taking advantage of the natural inheritance of Active Directory and are not using too many options that change the inheritance state.

Identifying User Requirements

Determine what you need to provide for the users and their computers. Every company s requirements will be different. Understanding how employees function on a day-to-day basis and what they need in order to perform these functions will aid you in determining the Group Policy settings you need to enforce. You will need to determine which settings need to be applied based on employees job functions and job requirements, as well as identify the corporate standards that should be put in place.

Corporate Standards

Corporate standards are usually the easiest settings to figure out. These are the settings that should be set across the board for every employee and computer. Corporate standards are settings that you define in order to control the environment so that no employee is allowed to perform actions that are prohibited . Settings that make up these standards include the password policy, account lockout policy, software restrictions, Internet Explorer Security Zone settings, and warning messages that appear when someone attempts to log on.

Corporate standards are settings that should be applied as high in the Group Policy hierarchy as possible. The Group Policy hierarchy consists of the three levels at which a GPO can be linked; site, domain and organizational unit (OU). Since the GPO settings are inherited from each of these levels, by linking the GPO at the highest level within the hierarchy where it applies, you will be able to enforce the settings over a large number of objects with the fewest number of GPOs.

Most designs apply the corporate standards at the domain level so that every user logging on and every computer starting up will have the policy applied to it. To make sure that these settings are imposed upon every user and system, the Enforced setting should be enabled on the GPO that represents the corporate standards. This way, if another administrator configures a GPO with settings that conflict with the corporate standards and links the new GPO to an OU, the corporate standards will still take precedence.

Don t modify the Default Domain Policy to include the settings for the corporate standards. Although this may seem like a logical place to enforce the settings because the Default Domain Policy affects all users and computers within the domain, the new Default Group Policy Restore Command, dcgpofix.exe, will not retain the settings that have been modified since the domain was created.

Note	For more information about the Default Group Policy Restore Command, dcgpofix.exe utility, see the section Options for Linking Group Policies later in this chapter.

If multiple domains exist within the organization, chances are the corporate standards will apply to them also. The GPMC will allow you to copy a GPO from one domain to another. Using this functionality, you can create a duplicate GPO that can be linked to a domain. This will alleviate having to link a single GPO to multiple domains. Whereas this is not an issue when you have domain controllers within a site that host the GPOs, if you have to pull the GPO from across a WAN link, you could increase the user s logon time considerably.

Job Function

Employees have specific functions that they provide for the company. An employee within the Human Resources department provides different functions than a temporary employee providing data entry for the Marketing department. Identify what the employees require to perform their jobs. Document your findings, and then compare what is the same among all employees within an OU and what is different. You may be able to create a single GPO for a department that applies to all of the users and computers and then link it at the parent OU for the department. Those settings that are specific to a subset of users or computers can then be added to a GPO that is linked to the child OU where the user or computer accounts are located.

Organize all of the settings required by employees within a department and create a GPO named after the department. That GPO can then be linked to the department. Other settings that are specific to a subset of the users within that department can either be linked to the OU and configured so that only those users receive the settings, or linked to a child OU if the users and computers are distributed for administrative purposes.

Job Requirements

There may be specific job requirements that must be met by users or computers that are different even though the job functions may be very similar. Whereas all members of the Human Resources department will need to access the training materials and benefits documents so that they can assist employees when necessary, a subset of Human Resources personnel may have access to the employee database. If this database resides on a server that requires IPSec-encrypted communication, only the appropriate Human Resources personnel should fall under the control of the GPO that provides the appropriate IPSec policy settings. By linking a GPO to the server s OU that enforces the servers to require IPSec for communication and another GPO linked at the Human Resource s client OU that uses the IPSec client policy, the Human Resources personnel will communicate securely with the servers.

System requirements may be different for users depending upon their job requirements. You may have users who need to use modems to connect to remote systems. Other users may need to have access to administrative tools. Exceptions to restrictions that are applied at the domain or parent OU may need to be overridden for these users. Make sure you document the special needs of every user.

Minimizing Group Policy Objects

If you use as few GPOs as possible, you will be able to troubleshoot problems that arise much more easily than if several GPOs could affect users and computers. Policy settings that are related , such as software restrictions that affect a large group of users, should be added to the same GPO. By adding settings to a single GPO instead of using multiple GPOs to enforce the settings, you will reduce the GPO processing time.

SLAs are starting to become more widespread. As systems become more and more vital to the operation of the company, the need to have these systems online becomes mandatory. Although we think of SLAs controlling servers and server maintenance, SLAs that affect workstations are also being put into place. Some of these dictate the amount of time that a user will have to spend for applications to load and the amount of time spent waiting for logon to complete. This may sound picky to some individuals, but there are financial institutions, brokerage firms, and other organizations that require their workstations to be available at all times so that they can perform their duties .

If your organization falls under an SLA, you will need to determine how long it takes to process the GPOs you are planning. By combining settings into a single GPO, you will decrease the amount of processing time required to process the settings. If the settings are spread out among several GPOs, all of the settings for each of the policies will have to be processed.

Try to determine if you can condense the settings into a single policy, and if you cannot, try to condense to the fewest policies possible. Of course, this is a practice that you should follow whether you are working under an SLA or not. Users do not like to wait to gain access to their systems. The faster they are able to see their logon screen and then have access to their desktop, the happier they are. And the happier the users are, the better your day will be!

Another method of making your GPOs more efficient is to disable part of the GPO from processing. Each of the two sections that you can configure settings in, computer and user, can be disabled. When you do so, you are essentially telling the system to ignore any of the settings in that section. Since the client-side extensions do not have to parse through the GPO to determine what needs to be enforced or disabled, the GPO will process faster, thus reducing the time it takes for the computer to reach the logon screen or the user to log on to their system.

Consider the following scenario. Company X has identified several settings that they want to use. They create a GPO for each of the settings so that they can name the GPO based on the setting that will be used. When finished, they have 14 unique GPOs. When the employees start their computers and log on, all settings in the 14 GPOs need to be processed. Company X starts receiving calls from their users who complain that the startup and logon times are excruciatingly long. After identifying which of the settings can be condensed into individual GPOs, they end up with 3 GPOs and no further complaints from the users.

Identifying Interoperability Issues

Windows XP and Windows Server 2003 are the only operating systems that can take full advantage of the new Group Policy settings in a Windows Server 2003 Active Directory environment.

Windows XP can take advantage of all of the new client specific settings whereas Windows Server 2003 can take advantage of all of the new server-based settings. For users running Windows 2000 Professional or servers running Windows 2000 Server, there will be over 200 possible settings that will not be processed on those platforms. When you are editing the settings for a GPO, make sure each of the settings specify to which operating system platform the setting will apply.

Windows Management Instrumentation (WMI) Filters provide additional functionality to a Group Policy application. By specifying operating system or system options, you can control which computers a GPO will apply. For instance, if you want to make sure that a system has enough free space on a partition or volume in order to install software, you can specify that the free space must exceed the minimum requirement for the application. Figure 6.4 is an example of a GPO that uses a WMI filter to control the installation of software to partitions or volumes with enough free space. If the requirement is not met, the application installation setting is ignored. Again, Windows XP and Windows Server 2003 can take advantage of WMI Filters but Windows 2000 cannot. If a WMI filter is in place that controls whether a GPO is applied and the computer is running Windows 2000, the WMI filter is ignored and the settings are applied.

Figure 6.4: WMI filter for detecting adequate drive space

Real World Scenario ”Minimizing Logon Time

Ornament Retailers Association (ORA) is a group of retailers that sell out-of-print Christmas ornaments. ORA recently implemented Group Policy in Active Directory. They decided to utilize many features of Group Policy, including controlling security, restricting user desktops, and deploying software.

ORA decided to create five levels of user access and created a GPO for each group. They designed it so that a user would log on, and depending on what group they were a member of, they would get a custom Desktop and Start menu from the Folder Redirection portion of Group Policy. All GPOs were then linked to an OU that contained all of the company s users. After the GPO implementation, users started complaining about very slow logon times. This was unacceptable due to a SLA in place that stated that logon times would take no longer than one minute. Some logons were taking from five to seven minutes.

After further investigation, it was found that the only difference among all five of the policies was the appearance of the Desktop and Start menu. All other settings were exactly the same.

ORA decided to streamline their policies and reduce the number that they use. They found that they could reduce their policies to just one at the Users OU, as folder redirection can be defined by group.

ORA reduced their logon time greatly by streamlining their GPOs.

Other operating systems, such as Windows NT 4, Windows 95, and Windows 98, will not process GPOs. If you wish to control computers running these operating systems, you will have to use System Policy Editor. This means that you will have to support two different technologies when trying to set user restrictions. Another drawback comes from the fact that only a small subset of settings are supported by System Policies. In order to efficiently control the systems and users within your environment, try to determine an upgrade path for the older operating systems.

Designing for Inheritance

Just as permissions are inherited from a parent OU to the child OU, Group Policy settings will also pass down through the hierarchy. Taking advantage of inheritance , you will be able to create a Group Policy hierarchy that allows you to efficiently apply GPOs to your organization and make it easy for your staff to troubleshoot issues arising from GPOs. You have several options when you are using inheritance. You should implement best practices that will allow inheritance to work as it should and then only use the options that change the default behavior when necessary. The more the options for enforcing, blocking, and filtering are used, the harder it is to troubleshoot the design.

Organizing OUs

Use the OU structure that is based on the administrative requirements as much as possible. Only create additional OUs if it makes the application of Group Policy easier to maintain and troubleshoot. For instance, if you look at Figure 6.5, an OU structure has been created that allows the Engineering department administration to be broken out into two departments: Graphic Design and Model Shop. Each of the departments has a different internal administrative staff responsible for maintaining the user and computer accounts. Within the Model Shop, some employees work with the Research and Development department to build prototypes . For users to access the plans from the Research and Development (R&D) servers, which are placed in an OU that has the required IPSec policy applied, they need to use IPSecencrypted communication. The GPO that allows the IPSec client policy is applied to the R&D Model Shop OU, where the user accounts are located, giving them the ability to access the plans from which they need to build. The rest of the Model Shop employees accounts are placed with the Users container.

Figure 6.5: OU structure enhanced for Group Policy application

Define Corporate Standards

Once the settings for corporate standards have been identified and configured within a GPO, they should be linked high within the hierarchy, preferably at the domain level. Once linked, the Enforced option should be set so that lower-level GPOs do not override any of the standards. Figure 6.6 shows a domain with the Default Domain Policy and the Corporate Standards policy. Notice that the Corp Standards GPO has the Enforced option turned on. Figure 6.7 shows the inheritance of GPOs at the Accounting OU. Notice that the Corp Standards GPO is the GPO with the highest priority within the list due to its Enforced setting.

Figure 6.6: Corporate Standards GPO enforced at the domain level

Figure 6.7: Corporate Standards affecting the Accounting OU

Use Blocking and Filtering Sparingly

The Block Inheritance option stops the natural inheritance of settings from GPOs higher in the hierarchy. When you use this option, you will block every GPO setting from any parent object with the exception of the domain account policies. Once blocked, the only way that a GPO s settings will override the Block Inheritance option is if you apply the Enforced option. The Enforced option takes precedence over any Block Inheritance option that it encounters, but it is only applied to an individual GPO. You will need to set the Enforced option for every GPO that needs to override the blockage.

Filtering is the process of specifying to which accounts the GPOs will apply. By default, the Authenticated Users group will have the GPO applied to it at the location where the GPO is linked. This may work in some instances, but for most applications, you will not want every account within the OU to be under the GPO s control. For instance, if the user account that has administrative rights to the OU is located within the OU and the GPO restricts the use of administrative tools, the administrative user will not have access to the tools they need to perform their job. Decide upon which accounts will need to have the GPOs applied to them and create a group based on that need. Do not add the administrative users to the group for the user accounts; instead, create another group for the administrators to be members of. Configure the Security Filtering option to include the group to which the GPO will be applied.

Prioritizing

If more than one GPO is attached to a site, domain, or OU, you will need to determine the processing priority for each. The processing priority specifies the order to which GPOs are processed. As the GPOs are processed, the GPO with the lowest processing number, which is the highest priority, will override any of the other GPOs settings that are linked to the same location with the exception of those GPOs that have the Enforced options enabled. Compare Figure 6.5 with Figure 6.8. In Figure 6.9, the processing priorities of the three GPOs linked at the Accounting OU are set so that the Accounting Registry & File GPO has the lowest processing priority. Yet because the Enforced option is set, you can see in Figure 6.5 that the Group Policy Inheritance tab lists it with a higher priority than the other two GPOs.

Figure 6.8: Priorities for GPOs attached to the Accounting OU

Figure 6.9: Processing order for GPOs at the Accounting OU

Enabling Loopback

Some computers within an organization should only be used for certain purposes. Kiosks will have access to public information, but because they are usually accessible to the general public, you may not want such computers to have the ability to access sensitive corporate information. You may encounter other computers that need to have user settings applied to the computer no matter which user is logged on. To enforce these settings, the loopback feature is used. Once enabled, the settings from the User Configuration portion of the Group Policy object that is applied to the computer s OU will take precedence instead of the User Configuration settings at the user s OU.

There are two methods of applying the settings once loopback processing has been enabled. The first, Merge, consolidates all of the settings from the user s and computer s GPOs, and any settings that conflict, the computer s setting will apply. The second method is Replace. When Replace is chosen , the user s settings are not processed. Instead, the computer s settings are applied, thus restricting the user account to just those settings that are allowed by the computer s GPO settings.

Options for Linking Group Policies

At this point in your MCSE studies, you should know that GPOs can be linked at the site, domain, or OU level. Although there are reasons you would want to do so, linking at the site or domain level is usually not suggested. Linking at the OU level allows you to efficiently control the GPOs and how they are applied to users and computers. Of course there are always exceptions.

The primary exception is the security settings that are applied at the domain level. You ll recall that the Default Domain Policy is where the password requirements, account lockout settings, and Kerberos policy settings are configured. These settings are then applied throughout the domain and cannot be overridden. This is the reason that a separate domain must be created if any settings within these options need to be different between user accounts.

As a general rule, you should not make changes to the Default Domain Policy with the exception of setting the account policy options settings. If any settings will define corporate standards other than the account policy settings and you want to apply them at the domain level, create a new policy for these settings. Although this goes against the recommendation that you use the fewest GPOs possible, it will allow you to have a central point to access the account policies for the domain and separate out any other policy settings that are applied. Another reason is that this gives you the ability to re-create the Default Domain Policy if it becomes damaged.

Included with Windows Server 2003 is a utility called dcgpofix.exe. This command line utility will re-create the Default Domain Policy and the Default Domain Controller Policy if necessary. It will not create either policy with any modified settings; it will only re-create the policy with the initial default settings that are applied when the first domain controller in the domain is brought online. Keeping this in mind, only make changes to the security settings that are applied to either of these two policies and make sure the settings are documented. After running dcgpofix.exe, the settings that define the corporate security standards can then be reset.

If you were to add settings to the Default Domain Policy, and then run dcgpofix.exe, the settings would be lost and you would have to re-create them. However, if you were to create a new Group Policy and add the settings to it instead, when the Default Domain Policy is re-created, the new Group Policy would not be affected. The same rule holds true for the Default Domain Controllers Policy. Because some settings should be applied to domain controllers to ensure their security, do not edit the settings on this Group Policy. The dcgpofix.exe utility can be used to regenerate this policy as well.

Note	For more information on dcgpofix.exe and how to regenerate the Default Domain Policy and Default Domain Controllers Policy, look within the Windows Server 2003 Help files.

Design Scenario ”Defining GPOs

Amber Film Distributors is planning an Active Directory infrastructure that will tie together all of their wholesale distribution warehouses. A single forest with a single domain design has been decided upon. The OU structure is based upon departments within the organization. Each department has child OUs based upon the locations where the department is located. They are in the process of deciding upon how much they are going to use GPOs to maintain their environment. Some of the settings that have been decided upon are listed here:

Every user in the domain will need to use strong passwords and have an account lockout setting of three attempts.
Every user must have antivirus software installed on their system.
The Accounting computers will have an accounting software package installed.
The Human Resources personnel can only access the Human Resources database server using IPSec encryption.
All users will have the Control Panel option removed from their computers with the exception of technical administrators.

Question: When deciding upon the settings that will be used within the corporate standards GPO, which of the settings should be combined? Answer: The software installation setting on the GPO making up the corporate standards will include the antivirus software. Another GPO should be created for the removal of the Control Panel options. Password and lockout restrictions should be set within the Default Domain Policy.
Question: Where should the GPOs for corporate standards be linked? Answer: They should be linked at the domain level so that all users in the domain will have the policies applied to them.
Question: Which user accounts should have the policies applied to them? Answer: The corporate standards GPO that includes the antivirus software installation setting should be set so that authenticated users have it applied to them whereas the GPO with the Control Panel removal setting should be applied to a group that includes all users in the domain with the exception of any administrative user accounts.
Question: Are there special GPOs that should be linked to OUs? And if so, which setting should be added to GPOs linked to those OUs? Answer: The Accounting OU should have a GPO created that includes the software installation for the accounting software. The Human Resources OU should have two OUs, one for client workstations and one for servers. A GPO that requires IPSec communication should be linked to the servers OU and another GPO that uses the IPSec client policy should be linked to the workstation OU.

As a general rule of thumb, when planning where the policies should be linked, if the policy applies to a large number of users, link it at the parent OU. If the policy applies to a discreet subset of users, link the policy at the child OU. This should alleviate the need to have elaborate filtering and blocking schemes that will affect the natural inheritance of GPOs.