Defining Client Administration and Configuration Standards
Defining Client Administration and Configuration Standards |
|
Windows 2000 client management is most fully enabled in an environment that includes Windows 2000 Professional, Windows 2000 Server, and an Active Directory namespace.
Group Policy settings are associated with an Active Directory container — a domain, site, or OU. Group Policy settings that you configure in conjunction with your organization's Active Directory structure allow you to define client standards as broadly (for an entire organization) or as narrowly (for members of a single workgroup, job function, or location) as you need. The level at which Group Policy settings are implemented needs to align with your organization's administration model, which was defined along with your Active Directory and domain model.
Although the IT team tasked with creating and implementing client standards historically does not get involved in domain namespace planning, it is strongly recommended that you do so if your organization is planning an Active Directory namespace. The earlier in the planning process that the domain namespace team understands your client administration needs and goals, the more likely it becomes that the organization's eventual namespace design will enhance your ability to manage and support user needs.
Caution
If the Active Directory namespace has not yet been developed, the client administration teams need to work with the directory and namespace team so that client standards can be set, Group Policy settings defined, and administrative tasks performed at the most efficient level in the organization.
A well-designed Active Directory namespace makes it relatively simple to implement certain client standards, such as
For example, you might want to define security and basic
Similarly, a domain-level administrator might not be the best person to reset passwords when a help desk person at the site or OU level is typically the first person to be called when a new password is needed. With Windows 2000 Group Policy, you can delegate password-related tasks to help desk personnel without giving them access to settings that you do not want them to alter.
As part of your Client administration plan:
For more information about the relationship of Group Policy to your Active Directory structure, see "Designing the Active Directory Structure" in this book.
Organizations that deploy Active Directory can also delegate control of portions of the directory service, and thereby delegate responsibility for the many client administration tasks described earlier in this chapter. This section explains how Group Policy can allow you to delegate administrative tasks at the site, domain, and OU levels.
Delegating administration through Group Policy involves the following three tasks, which can be performed together or separately, as your situation requires:
By default, only members of the Domain Administrators and Enterprise Administrators groups can configure Group Policy for sites, domains, or organizational units. The Group Policy tab in the site's, domain's, or OU's Properties page allows you to specify which Group Policy objects are linked to a site, domain, or OU.
Active Directory supports security settings on a per-property basis. This means that you can give a nonadministrator read and write access to specific properties. In this case, if nonadministrators have been delegated the Manage Group Policy links task, they can manage the Group Policy objects linked to that site, domain, or OU. To give a user this ability, use the Delegation Wizard.
By default, only members of Domain Administrators, Enterprise Administrators and Group Policy Creator Owners groups can create new Group Policy objects. If the Domain Administrator wants a nonadministrator or group to be able to create Group Policy objects, that user or group can be added to the Group Policy Creator Owners security group. When a nonadministrator who is a member of the Group Policy Creator Owners group creates a Group Policy object, that user becomes the creator and owner of the Group Policy object and can edit the object. Being a member of the Group Policy Creator Owners group gives the nonadministrator full control of only those Group Policy objects that the user creates or those explicitly delegated to that user.
By default, Group Policy objects allow members of the Domain Administrators, Enterprise Administrators, and Group Policy Creator Owners groups full control without the Apply Group Policy attribute set. This means that they can edit the Group Policy object, but the policies contained in that Group Policy object do not apply to them.
By default, Authenticated Users have read access to the Group Policy object with the Apply Group Policy attribute set. This means that Group Policy affects them.
Domain Administrators and Enterprise Administrators are also members of Authenticated Users; therefore, members of those groups are, by default, affected by Group Policy objects unless you explicitly exclude them.
When a nonadministrator creates a Group Policy object, this person becomes the Creator Owner of the Group Policy object. When an administrator creates a Group Policy object, the Domain Administrators group becomes the Creator Owner of the Group Policy object.
To edit a Group Policy object, the user must have both read and write access to the Group Policy object. To edit a Group Policy object, the user must be one of the following:
You can delegate Group Policy by creating and saving Group Policy snap-in consoles (.msc files), and then specifying which users and groups have access permissions to the Group Policy object or to an Active Directory container. You can define permissions for a Group Policy object by using the Security tab on the Properties page of the Group Policy object; these permissions grant or deny access to a Group Policy object to specified groups.
This type of delegation is also enhanced by the policy settings available for MMC. Several policies are available in the Administrative Templates node, under Windows Components in the Microsoft Management Console. These policies enable the administrator to define which MMC snap-ins the affected user might or might not run. The policy definitions can be inclusive, which only allows a set of snap-ins to run, or they can be exclusive, which does not allow a set of snap-ins to run.
By applying Group Policy options carefully, you can improve network response times, even when you begin to use the more data-intensive folder redirection and software installation options. Apply Group Policy options conservatively, especially at the beginning, and test all proposed changes carefully to ensure that network performance is not compromised.
In addition, a number of implementation options allow you to fine tune the application of Group Policy without creating additional Group Policy objects. The following are some of the options available:
Each of these options is explained briefly in the following sections.
You can refine which groups of computers and users a particular Group Policy object affects by using Windows 2000 security groups. This means that you can filter the effect that any Group Policy object has on members of specified security groups. To do this, use the Security tab on the Properties page of the Group Policy object.
For example, based on the level of autonomy that is appropriate for your users, assign different types of users to Windows 2000 user groups. Windows 2000 provides the following default user groups, which are similar — but not identical — to the default groups in Microsoft® Windows NT® version 3.51 and Windows NT 4.0:
Note
Windows 2000 allows administrators to exercise more precise control over users than Windows NT 4.0. Therefore, the default permissions that applied to Users in Windows NT 3.51 and 4.0 now apply to Power Users. And the default permissions that applied to Restricted Users in Windows NT 3.51 and 4.0 now apply to Users.
In Table 23.1, the Chief Financial Officer, Branch Manager, and Sales Person might be added to the Power Users group, and the Receptionist and Factory Floor Worker to the Users group. You can create additional groups based on the tasks that members perform, the degree of authority they have to modify their own or other computers, and the configurations you want them to have. For example, you might subdivide the Users group by department within the organization (Sales, Human Resources, Engineering, and so on) so that you can create and deploy appropriate standard configurations for all employees who perform identical tasks. This can greatly simplify the process of administering users with disparate configuration and permission requirements.
Preventing Group Policy object policy settings from applying to a specified group requires removing the Apply Group Policy Access Control entry from that group.
For groups containing nonadministrators, the Read Access Control entry must also be removed, because data is viewable to anyone with read access.
For more information about setting up and using security groups, see "Planning Distributed Security" in this book.
Options exist that allow you to enforce the settings contained in a specific Group Policy object so that Group Policy objects in lower-level Active Directory containers are prevented from overriding that policy. For example, if you have defined a specific Group Policy object at the domain level and you have specified that the Group Policy object be enforced (No Override), the policy settings that the Group Policy object contains apply to all OUs under that domain; that is, the lower-level containers (OUs) cannot override that domain Group Policy.
You can also block inheritance of Group Policy from parent Active Directory containers. For example, if you specify "Block Policy inheritance" for an OU, this prevents Group Policy objects specified in higher-level Active Directory containers (such as a higher-level OU or domain) from applying. However, the No Override (enforced) policy option always take precedence over the Block Policy option.
You apply Group Policy to a user or computer based on where the user or computer object is located in Active Directory. However, you might need to apply Group Policy to users based on the physical location of the computer object as opposed to the logical location of the user object in the organization — in a library, for example, or when a user in one OU logs onto a computer in a different OU. The Group Policy loopback feature gives the administrator the ability to apply User Group Policy settings based on the computer to which the user logs on.
For example, you might set the loopback option when you do not want applications that have been assigned or published to the users of the Marketing OU to be installed while they are logged on to the computers in the Servers OU. With the Group Policy loopback support feature, you can specify two other ways to retrieve the list of Group Policy objects for any user of the computers in the Servers OU:
Merge Mode In the Merge mode, the user's list of Group Policy objects is processed normally by using the GetGPOList Application Programming Interface (API) function during the logon process, and then the GetGPOList API function is called again using the computer's location in Active Directory. Next, the list of Group Policy objects for the computer is added to the end of the Group Policy objects for the user. This causes the computer's Group Policy objects to have higher precedence than the user's Group Policy objects.
Replace Mode In this mode, the Group Policy objects that apply to the user are not processed. Only the Group Policy objects based upon the computer object are used.
The path to this policy setting is: Computer Configuration\Administrative Templates\System\Group Policy. The Policy name is: User Group Policy loopback processing mode.
Many users, such as those with portable computers and those who work off the premises or in a branch location, sometimes connect to the network by using slow connections. Many Group Policy settings can be configured to run only when there is an adequate network connection. These Group Policy settings include:
When Group Policy detects a slow link, it applies the following default settings, unless they are modified:
For all but the Administrative Templates and the Security Settings snap-in, a policy is provided for toggling the settings on and off. For more information about configuring computers with slow network connections, see "Using Group Policy for Configuration Control" later in this chapter.
You can specify that Group Policy be processed periodically. By default, this is done every 90 minutes, with a randomized offset of 30 minutes. The offset is a random time added to the refresh interval to prevent all clients from requesting Group Policy at the same time. It is designed to prevent unnecessary peak loads on the network, for example, 90 minutes after a large number of users turn on their computers and log on at the same time. You can alter this refresh rate as needed, using smaller intervals in test or demonstration environments, for example, and larger intervals if desired.
There are two policy settings that allow you to alter the refresh rate, located in: Computer Configuration\Administrative Templates\System\Group Policy. One policy setting is for domain controllers; the other is for all other computers (including other servers). These policy settings are named "Group Policy refresh interval for..."
By default, Group Policy processing is synchronous, for both computer and user policy settings. For computer processing, users cannot log on until all computer Group Policy settings have been updated. For user processing, users do not have access to the desktop until all user Group Policy settings have been updated. These processing rules provide the safest mode of operation.
There is a Group Policy setting for both computer and user Group Policy processing that makes processing asynchronous. It directs the system to proceed without waiting to complete Group Policy updates before displaying the logon prompt (computer settings) or the desktop (user settings).
As a result of asynchronous processing, the logon dialog box might appear sooner, or the Windows interface can appear to be ready before all Group Policy settings have been applied.
If you specify asynchronous processing and the user can complete the logon process and begin working on the computer before the computer or user settings have been processed, you can create significant problems for the user. If, for example, the user begins working in an application that is being modified, the process might fail or the user might experience unwanted events after the computer and user settings have been processed.
Some Group Policy components include client-side extensions (.dlls) that are responsible for implementing Group Policy on the client computer.
The client-side extensions are loaded on an as-needed basis when a client is processing policy. The client first obtains a list of Group Policy objects. Next, it loops through all the client-side extensions and determines whether each client-side extension has any data in any of the Group Policy objects. If a client-side extension has data in a Group Policy object, the client-side extension is called with the list of Group Policy objects that it needs to process. If the client-side extension does not have any settings in any of the Group Policy objects, it is not called.
A computer policy setting exists for each of the Group Policy client-side extensions. Each policy includes a maximum of three options (check boxes). Some of the client-side extensions include only two computer policy options because the third option is not appropriate for that extension.
The following section explains client-side Group Policy processing options.
When a client-side extension registers itself with the operating system, it sets values of entries in the registry specifying whether it must be called when policy is being applied across a slow link. Some extensions (such as software installation and maintenance) move large amounts of data, so processing across a slow link can affect performance (consider the time involved in installing a large application across a 28.8 kilobytes per second (KBps) modem line).
An administrator can set the connection speed that is considered slow. Also, if an administrator decides that the client-side extension must run across a slow link regardless of the amount of data, he or she can enable this policy. The path to this is Computer Configuration\Administrative Templates\System\Group Policy.
Computer policy is applied at boot time, and then again in the background approximately every 90 minutes. User policy is applied when the user logs on, and then approximately every 90 minutes.
Some extensions can process policy only during the initial run because it is risky to process policy in the background. For example, with software installation and maintenance it is only safe to process application changes during computer startup or the user logon process. Otherwise, a user that is using an application might have the application uninstalled and a new version installed while they are still trying to work.
Some extensions allow their default behavior to be changed. The Do not apply during periodic background processing option can be used to override this default behavior and force the extension to either run or not run in the background.
By default, if the Group Policy objects on the server have not changed, it is not necessary to continually reapply them to the client, because the client already has all the settings. However, if users are administrators of their computers they can change policy settings. In this case, it might make sense to reapply these settings during the logon process or during the periodic refresh cycle to return the computer to the wanted state.
For example, assume that you have used Group Policy to define a specific set of security options for a file. Then the user (with administrative privileges) logs on and changes it. You might want to set the policy to process Group Policy even if the Group Policy objects have not changed, so that security is reapplied at every startup or when logging on. This also applies to applications. Group Policy installs an application, but the end user can remove the application or delete the icon. The Process even if the Group Policy objects have not changed option gives the administrator the ability to forcibly restore the application the next time the user logs on.