Group Policy Overview


Group Policy Overview

If you have Windows 2000 or Windows Server 2003 and have created an Active Directory domain, you already have Group Policy installed and operational by default. This is because the creation of a domain also creates default settings for all users and computers in the domain, as well as an additional set of settings for domain controllers. You also already have replication between domain controllers, so your policy configurations can reach all users and computers in your network. All you need to do now is to build on this existing infrastructure.

You use Group Policy to define configurations for groups of users and computers, including policy settings for registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance, and security. You can also use Group Policy to help manage server computers ”domain controllers or member servers ”by configuring operational and security settings. The Group Policy settings that you configure to perform these tasks are contained in a Group Policy Object (GPO).

To see sample standard desktop configurations and the actual policy settings used for those configurations, see the Group Policy scenarios in the whitepaper at the Implementing Common Desktop Management Scenarios link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Group Policy can significantly boost user productivity and satisfaction by doing the following:

  • Providing mobile or portable computer users uninterrupted access to their data in intermittently connected situations.

  • Delivering a consistent computing environment to users who are not assigned use of a specific computer.

  • Minimizing data loss by enabling centralized backup of user data and configuration files.

  • Minimizing user downtime by enabling automated installation and repair of applications.

Implementing Group Policy also boosts administrative efficiency and reduces IT costs by doing the following:

  • Enabling one-to-many management of users and computers throughout the organization.

  • Automating enforcement of information-technology (IT) policies.

  • Simplifying administrative tasks, such as application installations.

  • Enabling rapid deployment of security settings across the enterprise.

  • Efficiently implementing standard computing environments for groups of users.

  • Eliminating the need to manually configure user settings, install applications, or transfer user files to provide users access to their computing environments on any computer.

  • Enabling scenarios where users log in to any available computer in a pool.

  • Easing the IT task of implementing centralized backup of user files.

  • Reducing support costs by using Windows Installer to automatically repair broken application installations.

Comparing Group Policy with System Policy

There is no recommended upgrade path from System Policy-based management to Group Policy-based management. A new Group Policy infrastructure replaces System Policy. System Policy is designed for managing Windows NT and Windows 95/Windows 98, and Group Policy requires that the target be Windows 2000, Windows XP Professional, or Windows Server 2003.

Group Policy is not System Policy for Windows NT 4.0. Although Group Policy does include the functionality from Windows NT 4.0 System Policy, it also provides policy settings for scripts, software installation, security settings, Internet Explorer maintenance, folder redirection, and Remote Installation Services.

The following are examples of Group Policy and System Policy behavior in mixed environments:

  • If a computer is part of a Windows NT 4.0 domain, and the user is part of an Active Directory domain, System Policy is processed for the computer when the user logs on. After logon, the User portion of Group Policy is applied.

  • If both the computer and user are part of a Windows NT 4.0 domain, only System Policy is applied, regardless of operating system.

  • If the computer is part of an Active Directory domain, and the user is part of a Windows NT 4.0 domain, the Computer portion of Group Policy is processed during startup. Then, when the user logs on, User System Policy is applied.

  • If both the computer and user are part of an Active Directory domain, Group Policy is fully applied.

In Windows NT 4.0 (as well as Windows 95 and Windows 98), the System Policy settings:

  • Affect those in domains, subject to the security group restrictions.

  • May be further controlled by user membership in security groups.

  • Are not secure.

  • Persist in users profiles (this is sometimes referred to as tattooing the registry). This means that after a registry setting is set using Windows NT 4.0 System Policy, the setting persists until the setting is specifically reversed or the user edits the registry.

  • Are limited in scope and number.

In Windows 2000 and Windows Server 2003, Group Policy:

  • Represents the primary method for enabling centralized change and configuration management. You use Group Policy to manage registry-based policy, software installation options, security settings, scripts (for computer startup and shutdown, and for user logon and logoff ), Internet Explorer maintenance, folder redirection, and Remote Installation Services.

  • Is implemented by linking GPOs to Active Directory sites, domains, and organizational units (OUs).

  • Affects all users and computers in the specified Active Directory container (site, domain, or organizational unit) by default.

  • May be further controlled by user or computer membership in security groups and, for Windows XP and Windows Server 2003, through WMI filters.

  • Ensures that settings are secure.

  • Settings do not persist in the registry. The Windows NT 4.0 effect of persistent registry settings can be problematic when a user s group membership is changed. An advantage of Group Policy is that this does not occur.

  • Does not overwrite previously set configured user preferences. For example, if a GPO goes out of scope for a particular user, a user preference will have been retained.

  • Can be used for tightly managed desktop configurations and to enhance the user s computing environment.

Administrative Templates

In Windows NT 4.0, the System Policy Editor uses files called administrative templates (.adm files) to determine which registry settings can be modified. These files define which settings are displayed by the System Policy Editor user interface. In Windows 2000 and Windows Server 2003, the Administrative Templates node of the Group Policy snap-in uses .adm files to define the registry settings that can be configured in a GPO.

Windows 2000 and Windows Server 2003 each come with a predefined set of Administrative template files. An .adm file is a template that provides the friendly name for the setting and an explanation, not the actual policy settings that are deployed to client operating systems; these settings are contained in the registry.pol file inside the GPO.

.Adm files are text-based Unicode files which consist of a hierarchy of categories and subcategories that define how the options are displayed through the Group Policy Object Editor user interface. They also indicate the registry locations where changes should be made if a particular selection is made, specify any options or restrictions (in values) that are associated with the selection, and in some cases, indicate a default value to use if a selection is activated.

The version of System Policy Editor for Windows 95 and Windows 98 is different than the version designed for Windows NT 4.0. While the System Policy Editor interface is similar, the different registry formats in Windows 95 and Windows 98 and Windows NT 4.0 prevent policy creation across these operating system platforms. One template, Common.adm, contains policy common to both the Windows NT 4.0 and Windows 95 and Windows 98 registry structures, as shown in Table 7.1. The administrative template files included in Windows 2000 and Windows Server 2003 are intended to configure policy in these later versions of the Windows registry.

Table 7.1: Administrative Templates in Windows Server 2003

Template File

Where the Template Is Used

Description

 

System.adm

The Group Policy Object Editor snap-in - loaded by default in Windows 2000 and WindowsServer 2003

Contains all of the policy settings for the core operating system for users and computers

Inetres.adm

The Group Policy Object Editor snap-in - loaded by default in Windows 2000 and WindowsServer 2003

Contains policy settings for Internet Explorer

Conf.adm

The Group Policy Object Editor snap-in - loaded by default in Windows 2000 and WindowsServer 2003

Contains policy settings used to configure Microsoft NetMeeting

Wmplayer.adm

The Group Policy Object Editor snap-in - loaded by default in Windows 2000 and WindowsServer 2003

Contains policy settings used to configure Windows Media Player

Wuau.adm

The Group Policy Object Editor snap-in - loaded by default in WindowsServer 2003

Contains policy settings used to configure Windows Automatic Updates

Winnt.adm

Windows NT4.0 System Policy Editor

Contains policy for Windows NT4.0 clients

Common.adm

WindowsNT4.0 or Windows 95 and Windows 98 System Policy Editor

Contains policy for Windows NT4.0 and Windows 95 and Windows 98 clients

Windows.adm

Windows 95 and Windows 98 System Policy Editor

Contains policy for Windows 95 and Windows 98 clients

The Administrative Templates node in the Group Policy Object Editor includes all registry-based Group Policy information. This includes Group Policy for the Windows 2000, Windows XP Professional, and Windows Server 2003 operating systems and their components and applications.

By default, when a GPO is created, the .adm files loaded into the Group Policy snap-in are located in the %systemroot%\Inf folder on the computer where the snap-in is run. The .adm files are subsequently stored in a specific GPO folder on the SYSVOL volume of the domain controller to which the snap- in connects ”by default, the Primary Domain Controller (PDC) Emulator ”and this folder is replicated to other domain controllers. On subsequent editing of the GPO, the SYSVOL-based .adm files are used by the snap-in. This is the default behavior, but Group Policy settings are available to control the way .adm files are used. See KB article 816662 for more details.

The five templates that are loaded by default do not create persistent registry entries because they write registry changes under the \Software\Policies and \Software\Microsoft\Windows\CurrentVersion\Policies registry keys. The other .adm files located in the Inf folder do create persistent registry entries and are available primarily to support system policy (Config.pol and Ntconfig.pol). Therefore, do not use the other .adm files unless absolutely necessary.

It is also possible to create new, custom .adm files. For example, when an application adds Group Policy support, you might need to create a new .adm file to describe the location of the appropriate registry settings and the UI exposed by the Group Policy Object Editor. By using the Group Policy Object Editor, you can add additional .adm files to the GPO, which, by default, are then copied to the domain controller.

Distinguishing True Policies from Group Policy Preferences

In Windows 2000 and Windows Server 2003, all settings set registry entries and values in either the \Software\Policies (the preferred location for all new policies) or \Software\Microsoft\Windows\CurrentVersion\Policies trees, in either HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE.

Group Policy settings that are stored in these specific locations of the registry are known as true policies. Because they are stored here, you have the following advantages:

  • These trees are secure and cannot be modified by a non-administrator.

  • When Group Policy changes, for any reason, these trees are cleaned, and any new settings ”if they exist after the change ”are then rewritten.

  • If a user has set a user preference for the setting ”which is stored by the application outside of the Group Policy trees ”when a Group Policy no longer affects the setting (for example, when a GPO is unlinked from an OU to which a user belongs), the user preference is returned. In short, Group Policy can override ”but does not overwrite ”a user preference.

This prevents the behavior that was present in Windows NT 4.0, where System Policy settings resulted in persistent settings in the user and computer registry (also known as tattooing ). The policy remained in effect until the value was reversed, either by a counteracting policy or by editing the registry. These settings are stored outside the approved registry locations above and are known as preferences.

All the policy settings in the .adm files listed in Table 7.1, except the .adm files used for System Policy, describe registry settings in the Policies trees of the registry. This means that they clean up the registry when the GPO that applies them is no longer in effect. By default, only true policies are displayed in the Group Policy snap-in.

It is still possible for administrators to add additional .adm files that set registry values outside of the Windows 2000 and Windows Server 2003 Group Policy locations mentioned previously, and Internet Explorer settings can be managed in Preference Mode . These settings are more appropriately referred to as preferences because the user, application, or other parts of the system can also change them. In this case, the administrator ensures that this registry entry or value is set in a particular way, but a user can change this after Group Policy has configured the setting. Although it is possible to add any .adm file, if you use an .adm file from a previous version of Windows, the registry keys are unlikely to have an effect on Windows 2000, Windows XP Professional, and Windows Server 2003, or they actually set preference settings and mark the registry with these settings; that is, the registry settings persist.

In the Group Policy Object Editor, preferences are indicated by a red icon to distinguish them from true Group Policy settings, which are indicated by a blue icon. Note that, by default, they are not visible; you must set the UI preference first then they show up blue. To do so, clear the Only show policy settings that can be fully managed check box on the Filtering dialog box in the View menu of the Group Policy Object Editor. You need to clear this check box each time you need to see these preferences after restarting the Group Policy Object Editor.

You can manage advanced settings for Internet Explorer, such as setting a size limit for users Temporary Internet files. In order to do this, you need to first enable Preference Mode for Internet Explorer Maintenance. By default, the Preference Mode option is hidden. You access this option by right-clicking Internet Explorer Maintenance node and selecting Preference Mode on the shortcut menu.

This adds an Advanced node to the results pane. This node contains settings for managing Temporary Internet files and other UI features. Note that switching to Preference Mode disables some of the Internet Explorer Maintenance nodes. If a setting name has Preference Mode appended to it, it can be used in that mode; otherwise , it means that setting is disabled. For example, the Connection Settings (Preference Mode) option under the Connection node can be used in Preference Mode as indicated by its labeling in the UI, whereas the User Agent String option (note the exclusion of Preference Mode ) cannot be used in Preference Mode , and this is reflected in its labeling.

Use of non-Group Policy settings within the Group Policy infrastructure is strongly discouraged. To set registry settings on Windows NT 4.0, Windows 95, and Windows 98 clients, use the Windows NT 4.0 System Policy Editor tool, Poledit.exe.




The Microsoft Windows Server Team Migrating from Microsoft Windows NT Server 4.0 to Windows Server 2003
Migrating from Microsoft Windows NT Server 4.0 to Windows Server 2003
ISBN: 0735619409
EAN: 2147483647
Year: 2004
Pages: 96

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net