Reposted: Group Policy Design Mustproductive
Microsoft Corporation Release Date: November 2000
Summary
This article describes how to design the Group Policy Objects (GPO) structure and how to integrate it with Microsoft® Windows® 2000 Active DirectoryTM services. This article is an introductory article for system administrators.
Thank you
John Kaiser, Technical Editors, Microsoft Corporation
introduction
In a Windows® 2000 operating system, you (System Administrators) use Group Policy to define users and computer configurations for users and computers. You created a specific desktop configuration by using the Group Policy Microsoft Management Console (MMC) snap-in to specific users and computers. The "Group Policy" configuration created is included in a Group Policy Object (GPO) that is associated with the selected Active DirectoryTM service container such as site, domain, or organizational unit (OU).
Using the Group Policy snap-in, you can specify the policy settings of the following items:
Strategy based on the registry. Includes a Windows 2000 operating system and its components and group policies for applications. To manage these settings, you can use the "Management Template" node of the Group Policy management unit. Security options. Includes options for local computers, domain, and network security settings. Software installation and maintenance options. Used to centrally manage the installation, update, and deletion of applications. Script options. Includes scripts for computer startup and closure, and user login and logout. Folder rendering options. Allows you to redirect the user's special folder to the network.
Using Group Policy, you can only define only once the user working environment status, and then rely on the system to implement administrator-defined policies.
This article provides a general description for administrators when setting the Group Policy Objects (GPO), including the following sections:
Define Group Policy Requirements. Describe how to determine the group policy requirements. Policy settings constitute the first set of requirements, including security and user environment settings. The second group requires an object type such as a workstation, user, and domain controller (DC). Determine the setup domain. Describe how to define the scope of the policy objects and suggest some strategies, such as: Creating a GPO for public settings, creating separate GPOs for groups that require different settings. This section also describes the changes to GPO. Verify Active Directory Domain / OU Design. Describe how to determine whether the Active Directory Domain / Organization Unit (OU) design supports GPO. Management group strategy. Introduce Group Policy Management, specifically introduction how management structure, policies, and practices affect the final structure of the GPO model. Test and optimization group strategy. This section describes how to review and test group strategy structures so that it has the right behavior and optimal performance. Maintenance group strategy. This section describes how to eliminate the problem and maintenance group strategy of Group Policy when the organization needs to change.
Define Group Policy requirements
This section describes how to define group policies.
First, you want to determine the type of the required policy settings. Policy settings are usually divided into the following parts:
Security Settings. Applications to be deployed. Computer system settings. User environment settings. The application is set.
Next, determine which types of objects (users, computers) in the directory will apply these settings. Establish cross-references between policy settings and the object types that will apply group policies.
Domain (Password / Account Policy) Workstation User Domain Controller Server (Applications, Files & Print)
After completing this phase, the initial structure of the group policy is formed. At this point, each target object (user, workstation, etc.) should correspond to a single GPO containing all different settings for this object. See Table 1 below for details.
Table 1 Group Policy requirements example
Domain Workstation User Domain Controller Server Security Password, Account, Kerberos Policy PK Trust List User Permissions Files and Registry ACL Audit and Event Logs Local Setting EFS Policy User Permissions Files and Registry ACL Audit and Event Logs Local Set User Permissions Files and Registration ACL Audit and Event Log Local Settings Application Required Core Application Release Optional Applications and Components Administrative Tools Management Tools Computer Settings Startup Scripting Log in Disk Quota Offline File Disk Quota Printer Delete User Settings Login Script Internet Explorer Setting RAS Folder Heavy Desktop locking network system (loopback) Disable Standard User Desktop Settings (Ring Back) Disable Standard User Desktop Setup Application Settings Office 2000 Group Policy Objects Generated by Office 2000
Group Policy Object Domain Security Settings Workstation Settings (Security, Deployment Applications, System Settings) User Settings (Security, Deployment Applications, System Settings, and Application Settings) Domain Controller Settings (Security, Deployment) Program and System Settings) Server Settings (Security, Deployment Applications and System Settings)
Determine the role of the setting
This section describes how to define the scope of the policies objects listed in Table 1.
For each GPO, consider such a problem:
Are the settings of each target (such as computer, user or domain) to all objects in the organization are common? Or do you need to apply different settings in different groups in these objects?
If some GPOs apply different settings to different packets in the user / computer group, GPO needs to be bifurcated. At this stage, you need to determine which settings correspond to which of the groups.
Often appear: Many settings are common to all users / computers in the organization, but there are few settings vary depending on the group. In this case, a GPO can be created for general settings to set separate GPOs for each group that requires different settings.
When defining a scope of the policy, it should be considered what effect when the user policy setting is applied to a computer and these settings do not apply. For example, if a user has an administrative responsibility, set the user to log in to the server console to install its application may not be advisable. To set a "loopback" policy to be protected to supplement or override the normal user settings to avoid this.
Aspects of the Group Policy Scope Another consideration is whether a particular setup group is required to enforce all the slave containers, or whether to prevent some settings from inheritance. This issue is discussed in the "Management Group Policy" section later.
Table 2 Group Policy Object Change Example
Existing GPO Scheme New GPO affects all domains in domain security units without changing workstation security, application, system settings workstation security settings in some physical locations, change all other settings to all workstations Universal workstation security - Global, but some sites have changed. Other settings - globally. User security, application, system settings, and applications set user security for department-wide system settings for all users General Application and Application Settings for Deputy Director Systems - Global Security Settings, Application, Application Settings , Desktop settings - one GPO per sector. Domain controller security, applications, and system settings all domain controllers have no changes. Server security, application, and system settings security and system settings because of server type (file server, application server) and is the server application - global. Security and System Settings - a GPO per server type.
Verify Active Directory Domain / OU Design
This section provides a framework for domain verification / ou design.
At this stage, you need to determine how the functions described earlier are deployed into your domain / ou design. Consider the following questions:
Can domain design support the effective use and management of group strategies? If you can't, what changes need? "Active Directory Network and Distribution" requires what conflicts between "Group Policy"?
In order to eliminate conflicts between directory structure and GPO requirements, it is often necessary to use a safety group to filter GPO. The goal of this phase work is to produce a revised GPO structure (or a revised Active Directory namespace structure) and the definition of the "GPO Filter Security Group". For details, see Figure 1 below.
Figure 1 Design proposed company domain OU structure
In this case, the OU structure is common to all three domains. User account management is carried out in the region and national level. User settings and application deployments are managed by departments. Regional IT Center and National IT Group Management Workstation, Server and Domain Controller.
The first question is that group policies cannot be inherited across domains, nor cannot be copied from one domain to another. The GPO in one domain can be linked from another domain, but in this specific domain model, this will make performance greatly reduced (because the GPO will be loaded through Intercontinental WAN link).
Note The domain controller from multiple domains can be accessed by a relatively high bandwidth, which may not be a big problem. However, the trouble of inter-domain link may be very much because the application of the policy object will be detached from its ownership and control. Typically, only administrators with control of GPOs are available to these GPO links. Otherwise, the settings in the GPO may change without knowing the user (and the owner of the GPO does not necessarily know what these changes have.).
The solution to this problem is to replicate the GPO structure in each domain. At this point, it is necessary to check the domain structure to see if all domains in the proposed domain can be combined into one (or at least few more than a few) to facilitate GPO management.
The second difficulty is that the proposed OU structure may not correspond to the role of GPO. For example, the user object OU may be organized in a geographic location to comply with the regional management delegation structure, and the policy requires the application by department or business unit. The solution is to filter these GPOs in a higher level application group policy object and use the security group (match the required business unit structure).
Group policy object change
In addition to all GPOs must be copied in various fields, the structure of the GPO does not make changes.
Changes to domain / OU structures include adding a "user account OU" on the existing user OU - a universal user policy applies.
GPO screening security group
The following example lists two general types of GPO screening security groups:
Each departmental user / application GPO group server type GPO group
Management group strategy
This section lists some guidelines for the management group policy.
The structure, strategy and practice of the management role will affect the final structure of the GPO model. Please consider these strategies carefully and pay attention to the following guidelines:
The management structure affects the GPO structure. For example, although security settings have the same scope as other workstations, it controls their management groups possible. This may require splitting of a single GPO. Applying to the Group Policy object Access Control List (ACL) should reflect who should manage these objects. Similarly, ACLs on all domains and OUs should limit who can link GPOs to these containers. GPOs that include settings that must be applied to all objects in the subless may need to be enforced to prevent these settings overwritten by the lower level of GPO in the OU hierarchy. Some global security policy settings usually require this. In some cases, the local administrator may want to specify their GPO settings to block the inheritance setting, so that higher level policy settings are not inherited. It is necessary to do this less - and because it is easy to cause confusion - this approach should be avoided. The need to delegate the control of some of the settings in a GPO may require split GPO and allow the appropriate ACL to apply to each new GPO. Delegate to the control of GPO settings and the ability to create / delete group policies on the OU. Create a Custom Group Policy Editor console. (This may include specify which "Group Policy" management units can be loaded in the policy.
Table 3 shows an example of a change to a GPO structure. Table 3 may change the possible changes to the group policy object structure
Existing GPO New GPO Domain Safety Domain Safety Global Workstation Security and System Settings Global Workstation Security Global Workstation System Settings Site Workstation Security Site Workstation Security Global User System Settings Global User System Setting Security Settings, Applications and Applications Program setting, desktop settings (per sector). Global User Security Settings Space Security Division Applications and Applications Set Data Controller Security, Applications and System Settings Domain Controller Security Domain Controller Systems and Applications Settings Server Application Server Application Security and System Settings - a GPO server security system setting per server type
Table 4 Possible GPO enforcement and management example
GPO enforcement / block GPO administrator domain safety safety global workstation security enforcement safety global workstation system settings desktop engineering site workstation security to implement security global user system settings desktop project Global User Security Settings Security Services User Security Business Unit Management Department applications and applications set application deployment unit controller security security domain controller systems and applications set infrastructure projects. Server Application Application Deployment Server Security Security Server System Setting Infrastructure Engineering
Test and optimization group strategy
This section outlines what you need to do correctly and optimize group strategies.
At this stage, the group policy structure needs to be reviewed and tested so that it has the right behavior and optimal performance. Some of the contents that should be tested include:
If the user is constantly switching, the combination of group policies exhibited expected behavior in all different arrangements? If the laptop constantly transforms the site, does the combination of site and domain / ou strategy settings exhibit expected behavior? It should be checked and the test group policy design makes it more efficient. If there are too many GPOs to be applied to a user or computer, login or startup time may be difficult to accept. Excessive GPO is applicable to a single user or computer to make it difficult for the understanding of the policy structure. You should check each policy to see if it is optimized. Screening with a security group prevents unnecessary client processing of GPO. The user or computer that is not used in the policy object should be disabled to minimize unnecessary client processing. For large or more complicated GPOs that frequently change, you should see if the constant setting part can be moved to a new GPO. Each change to GPO will cause replication between the domain controllers and to the client's downloads. Moving the constant changes to a separate GPO can make the network and the network and the client GPO processing time is minimized.
Remarks, but this may cause the GPO structure to be too complicated, so we must weigh the pros and cons between the two.
Maintenance group strategy
This section describes how to eliminate the problem and maintenance group strategies of Group policies as the unit needs to change. The wrong GPO setting will bring a wide range of serious consequences. Each change should be tested in the laboratory before deploying into a production environment. The GPO is currently not copying or moved between the domain, so when the GPO test in the laboratory test is copied into the production environment, you need to manually edit the GPO settings.
To add a new GPO, put it in a test OU (in the production domain) and let a group user tries it.
To change an existing GPO, you can try your changes in a test OU. First create a temporary link to this existing GPO from the test OU, then create a new GPO (higher priority) that implements these changes in this OU. After these changes have been tested, these changes can be placed in the production of GPOs and delete a temporary link.
Because the changes to GPO will have a huge impact, they must have a complete change management step. Each proposed changes should be inspected and correct before approved the introduction of the production environment.
For more information on maintaining group strategies, see Troublehshooting Group Policy (Group Policy Troubleshooting).
to sum up
Group Policy allows you to only define only once the user's work environment status, and then rely on the system to implement the defined strategy. To achieve this state, you need to first create, organize, and plan GPOs while planning the Active Directory domain structure. This article made a high summary of the recommendations of the proposed consideration. For further information, see the related links below. Related Links
See further information in the following resources:
Windows 2000 Group Policy (Windows 2000 Group Policy) Troubleshooting Group Policy in Windows 2000 (Troubleshooting Group Policy in Windows 2000) Implementing Registry-Based Group Policy (Group Policy Based Registry) Implementing Common Desktop Management Scenarios (to achieve common desktop management Program) Microsoft Technet.
For the latest information about Windows 2000 Server, see Microsoft TechNet and Windows 2000 Server Web Site.
The information contained in this document represents the current view of the issued problem in the date of publication, Microsoft Corporation to the discussion. Because Microsoft must comply with the changing market conditions, the document should not be understood as the commitment of the Microsoft party, and Microsoft does not guarantee the accuracy after the information given to the date of publication.
This document is for reference only. In this document, Microsoft does not make any promises or instructions.
Users must comply with all applicable copyright laws. Without restricting the rights required by the copyright law, it is not possible to copy any form or means (electronic, mechanical, photocopying, recording, etc.), and disseminate this article in any form or means (electronic, mechanical, photocopy, recording, etc.). Any part of it is not allowed to store or introduce it into the retrieval system.
Microsoft may have patents, patents, trademarks, copyrights, or other intellectual property rights involved in this document. Unless explicitly mentioned in the Microsoft Written License Agreement, purchasing this document does not provide you with any patents, trademarks, copyrights, or other intellectual property rights.
Here, as described in Example, organization, product, people, and events are fictitious. Never refer to any actual company, institution, product, personnel and events.
© 2000. Microsoft Corporation. All rights reserved.
Microsoft, Active Directory and Windows are registered trademarks or trademarks of Microsoft Corporation in the US and / or other countries (regions).
The actual companies and product names mentioned here may be a trademark of its respective owners.
