Group Policy Extension Snap-ins

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

The Group Policy extension snap-ins constitutes the main nodes in the Group Policy Object Editor namespace; they are all loaded by default when the Group Policy Object Editor is started. You can modify which extensions are loaded by creating custom consoles for Group Policy, and by specifying policy settings for MMC. For more information, see "Creating Custom Group Policy Snap-in Consoles" and "Specifying Group Policy to Control the Behavior of MMC and Snap-ins" in this document.

This section presents additional information about the following topics:

• Administrative Templates

• Security Settings

• Software Installation

• Scripts (Startup/Shutdown and Logon/Logoff)

• Folder Redirection

• Internet Explorer Maintenance

• Remote Installation Services

Administrative Templates

Administrative templates, (or .adm files), enable administrators to control registry settings using Group Policy. Windows comes with a predefined set of Administrative template files, which are implemented as text files (with an .adm extension), that define the registry settings that can be configured in a GPO. These .adm files are stored in two locations by default: inside GPOs in the Sysvol folder and in the %windir%\inf directory on the local computer.

As new versions of Windows are released, new policy settings are added. In addition to supporting these new settings, each successive version of Windows supports all registry policy settings that were available in earlier versions of Windows. For example, the Windows Server 2003 family supports all registry policy settings available in Windows 2000 and Windows XP.

Note that .adm files are Unicode files which consist of a hierarchy of categories and subcategories that define how the options are displayed through the Group Policy Object Editor and GPMC. 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.

It is important to understand that .adm files are not the actual settings that are deployed to client operating systems. The adm file is simply a template file that provides the friendly name for the setting and an explanation. This template file is used to populate the user interface. The settings that are deployed to clients are contained in the registry.pol file inside the GPO. On Windows XP and Windows Server 2003, each registry setting contains a "Supported on" tag that indicates which operating system versions support that policy setting. If a setting is specified and deployed to a client operating system that does not support that setting, the settings are ignored.

Because all successive iterations of .adm files include settings from earlier versions, and because there is no harm if a new setting is applied inadvertently to a computer running an earlier operating system that does not support that setting, it is recommended to always create and edit GPOs from a computer that has the latest .adm files available. Note that the behavior for handling .adm files in GPMC and the Group Policy Object Editor differs.

Windows Server 2003 includes the following .adm files: System.adm, Inetres.adm, Conf.adm, Wmplayer.adm, and Wuau.adm, which contain all the settings initially displayed in the Administrative Templates node.

.Adm file	Contains	For Use on	Description
System.adm	Settings to configure the Operating System	Windows 2000 or Windows Server 2003	Loaded by default.
Inetres.adm	Settings to configure Internet Explorer	Windows 2000 or Windows Server 2003	Loaded by default.
Conf.adm	Settings to configure NetMeeting v3	Windows 2000 or Windows Server 2003. Note This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wmplayer.adm	Settings to configure Windows Media Player	Windows XP, Windows Server 2003. Note This tool is not available on Windows XP 64-Bit Edition and the 64-bit versions of the Windows Server 2003 family.	Loaded by default.
Wuau.adm	Settings to configure Windows Update	Windows 2000 SP3, Windows XP SP1, Windows Server 2003	Loaded by default.

Handling .adm files in Group Policy Object Editor

• Windows Server 2003, Group Policy Object Editor uses .adm files to display available registry-based policy settings in the Administrative Templates section of a GPO. This includes Group Policy for the Windows Server 2003 operating system and its components and for applications.

• By default it attempts to read .adm files from the GPO (from the Sysvol on the domain controller). Alternatively, the .adm file can be read from the local workstation computer. This behavior can be controlled by a policy setting.

• By default, if the version of the .adm file found on the local computer is newer (based on the time stamp of the file) than the version on the Sysvol, the local version is copied to the Sysvol and is then used to display the settings. This behavior can be controlled by a policy setting.

• If the GPO contains registry settings for which there is no corresponding .adm file, these settings cannot be seen in the Group Policy Object Editor. However, the policy settings are still active and will be applied to users or computers targeted by the GPO.

• Policy settings pertaining to a user who logs on to a given workstation or server are written to the User portion of the registry database under HKEY_CURRENT_USER. Computer-specific settings are written to the Local Machine portion of the registry under HKEY_LOCAL_MACHINE.

Handling .adm files in GPMC

• GPMC uses .adm files to display the friendly names of policy settings when generating HTML reports for GPOs, Group Policy Modeling, and Group Policy Results.

• By default, GPMC uses the local .adm file, regardless of time stamp. If the file is not found, then GPMC will look in the GPO's directory on Sysvol.

• The user can specify an alternate path for where to find .adm files. If specified, this takes precedence over the previous locations.

• GPMC never copies the .adm file to the Sysvol.

For more information, see Recommendations for Managing Group Policy Administrative Template (.adm) Files at https://support.microsoft.com/default.aspx?scid=kb;en-us;816662.

Using Administrative Templates

For Administrative Templates policy settings, the Group Policy Object Editor provides explain text directly in the Web view of the console. You also can find this explain text by double-clicking the policy setting and then clicking the Explain text tab. In either case, this text shows operating system requirements, defines the policy setting, and includes any specific details about the effect of enabling or disabling the policy setting.

New policy settings

Windows Server 2003 includes more than 200 new policy settings. The new Windows Server 2003 policy settings allow administrators to control the behavior of:

• System restore, error reporting, PC Health.

• Terminal Server.

• Networking such as SNMP, QoS, personal firewall, and dialup connections.

• DNS and net logon.

• Roaming user profiles and Group Policy.

• Control panel.

To filter settings based on the "supported on" information: Open the Group Policy Object Editor, click View, and then click Filtering. Select the versions you want to show and click OK.

True Policy Settings Compared with Group Policy Preferences

In Windows 2000 and later, all shipping policy settings set registry keys and values in one of the following locations:

• HKLM\Software\Policies (preferred location).

• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies.

• HKCU\Software\Policies (preferred location).

• HKCU\Software\Microsoft\Windows\CurrentVersion\Policies.

Policy settings that are stored in these specific locations of the registry are known as true policies. Storing settings here has 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 the new policy settings are then rewritten.

This prevents the behavior that was often present in Windows NT 4.0, whereby System Policies resulted in persistent settings in the user and computer registry. 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 System.adm, Inetres.adm, Conf.adm, Wmplayer,adm, and Wuau.adm files use registry settings in the Policies trees of the registry. This means that they will not cause persistent settings in the registry when the GPO that applies them is no longer in effect.

By default, only true policy settings are displayed in the Group Policy Object Editor. The following .adm files are loaded:

• System.adm: contains operating system settings

• Inetres.adm: contains Internet Explorer restrictions

• Conf.adm: contains NetMeeting settings

• Wmplayer,adm: contains Windows Media Player settings

• Wuau.adm: contains Windows Update settings

Creating Custom .adm Files

It is possible to create new .adm files. For example when an application adds Group Policy support, a new .adm file may be necessary to describe the location of the appropriate registry keys and the UI exposed by the Group Policy Object Editor. Through the Group Policy Object Editor, the administrator can optionally add in additional .adm files to the GPO which, by default, will then be copied to the domain controller into the GPO directory.

To view custom .adm files in the Group Policy Object Editor:

• Right click any administrative template node, select View and then click Filtering. In the filtering dialog box, clear the check box for Only show policy settings that can be fully managed and click OK.

Viewing Group Policy Preferences

By default only the settings that are contained in the genuine Group Policy trees (the trees that correspond to the reserved Group Policy registry areas) are visible in the console.

To eliminate use of non-policies, you can enable the policy setting, Enforce Show Policies Only, available in User Configuration\Administrative Templates, under the System\Group Policy nodes.

If you enable this setting, the Show Policies Only command is turned on, and administrators cannot turn it off. As a result, Group Policy displays only true settings; preferences do not appear. If you disable this setting or do not configure it, the Show Policies Only command is turned on by default, but administrators can view preferences by turning off the Show Policies Only command.

In Group Policy, preferences are indicated by a red icon to distinguish them from true policy settings, which are indicated by a blue icon.

Impact of GPO Replication

By default, when you add a new domain to the console, GPMC uses the PDC emulator in that domain to help ensure that all administrators are using the same domain controller. For managing sites, GPMC uses the PDC emulator in the user's domain by default. You can change the default choice of domain controller using the Change Domain Controller dialog box in GPMC. If you are located at a remote site with a slow connection to the default domain controller, you may want to do this.

It is important for administrators to consider the choice of domain controller in order to avoid replication conflicts particularly because both Active Directory and FRS use multi-master replication. This is especially important to consider because GPO data resides in both Active Directory and on Sysvol, and two independent replication mechanisms must be used to replicate GPO data to the various domain controllers in the domain. If two administrators are simultaneously editing the same GPO on different domain controllers, it is possible for the changes written by one administrator to be overwritten by another administrator, depending on replication latency.

Security Settings

You can define a security configuration within a GPO. A security configuration consists of settings applied to one or more security areas supported on Windows 2000 Professional, Windows XP Professional or Windows Server 2003. The specified security configuration is then applied to computers as part of the Group Policy application.

The Security Settings extension of the Group Policy Object Editor complements existing system security tools such as the Security tab on the Properties page (of an object, file, directory, and so on), and Local Users and Groups in Computer Management. You can continue to use existing tools to change specific settings, whenever necessary.

The security areas that can be configured for computers include the following:

• Account Policies. These are computer security settings for password policy, lockout policy, and Kerberos policy in domains on Windows 2000 and Windows Server 2003.

• Local Policies. These include security settings for audit policy, user rights assignment, and security options. Local policy allows you to configure who has local or network access to the computer and whether or how local events are audited.

• Event Log. This controls security settings for the Application, Security, and System event logs. You can access these logs using the Event Viewer.

• Restricted Groups. This allows you to control who should and should not belong to a restricted group, as well as which groups a restricted group should belong to. This allows administrators to enforce security policy settings regarding sensitive groups, such as Administrators or Payroll. For example, it may be decided that only Joe and Mary should be members of the Administrators group. Restricted groups can be used to enforce that policy. If a third user is added to the group (for example, to accomplish some task in an emergency situation), the next time policy is enforced, that third user is automatically removed from the Administrators group.

• System Services. These control startup mode and security options (security descriptors) for system services such as network services, file and print services, telephone and fax services, Internet and intranet services, and so on.

• Registry. This is used to configure security settings for registry keys including access control, audit, and ownership. When you apply security on registry keys, the Security Settings extension follows the same inheritance model as that used for all tree-structured hierarchies in Windows 2000 and Windows Server 2003 (such as Active Directory and NTFS). Microsoft recommends that you use the inheritance capabilities to specify security only at top-level objects, and redefine security only for those child objects that require it. This approach greatly simplifies your security structure and reduces the administrative overhead that results from a needlessly complex access-control structure.

• File System. This is used to configure security settings for file-system objects, including access control, audit, and ownership.

• Public Key Policies. You use these settings to:

  • Specify that computers automatically submit a certificate request to an enterprise certification authority and install the issued certificate.

  • Create and distribute a certificate trust list.

  • Establish common trusted root certification authorities.

  • Add encrypted data recovery agents and change the encrypted data recovery policy settings.

• IP Security Policies on Active Directory. IP Security (IPSec) policy can be applied to the GPO of an Active Directory object. This propagates that IPSec policy to any computer accounts affected by that GPO.

• Wireless Networking. This lets you configure wireless network settings that are part of Group Policy for Computer Configuration. Wireless network settings include the list of preferred networks, WEP settings, and IEEE 802.1X settings. These settings are downloaded to targeted domain members, making it much easier to deploy a specific configuration for secure wireless connections to wireless client computers.

• Software Restriction Policies. This lets you protect your computer environment from untrusted code by identifying and specifying which applications are allowed to run. With software restriction policies, you can:

  • Control the ability of programs to run on your system. For example, if you are concerned about users receiving viruses through e-mail, you can apply a policy setting that does not allow certain file types to run in the e-mail attachment directory of your e-mail program.

  • Permit users to run only specific files on multi-user computers. For example, if you have multiple users on your computers, you can set up software restriction policy settings in such a way that users do not have access to any software but those specific files that are necessary for their work.

  • Decide who can add trusted publishers to your computer.

  • Control whether software restriction policy settings affect all users or just certain users on a computer.

  • Prevent any files from running on your local computer, organizational unit, site, or domain. For example, if your system has a known virus, you can use software restriction policy settings to stop a computer from opening the file that contains the virus.

    Note

    Software restriction policy settings should not be used as a replacement for antivirus software.

• You can configure security settings policies in Computer Configuration\Windows Settings\Security Settings in the Group Policy Object Editor.

Default Security Templates

Windows 2000 and Windows Server 2003 include three default security templates called Basic. These new default security settings are applied to Windows 2000 or Windows Server 2003 systems that have been installed onto an NTFS partition. When Windows 2000 or Windows Server 2003 is installed onto a FAT file system, security cannot be applied.

The following Basic security templates are used:

• Basicwk.inf for workstations.

• Basicsv.inf for member servers.

• Basicdc.inf for domain controllers.

The Basic security templates specify default Windows 2000 or Windows Server 2003 security settings for all security areas, with the exception of User Rights and Groups. These templates can be applied to Windows 2000 or Windows Server 2003 systems using the Security Configuration and Analysis MMC snap-in or by using the Secedit.exe command-line tool.

Incremental Security Templates

Windows 2000 and Windows Server 2003 include several incremental security templates. By default, these templates are stored in %systemroot%\Security\Templates. These predefined templates can be customized using the Security Templates MMC snap-in and can be imported into the Security Settings extension of the Group Policy Object Editor.

These security templates were constructed based on the assumption that they would be applied to computers running Windows 2000 or later and that are configured with Windows 2000 or later default security settings. In other words, these templates incrementally modify the default security settings. They do not include the default security settings plus the modifications.

The following table lists the incremental security templates included in Windows 2000 and Windows Server 2003.

For information about the default security settings contained in the Default Domain Policy GPO and Default Domain Controller Policy GPO, see "Appendix A: Security Settings and User Rights" later in this paper.

Using Software Installation and Maintenance

You can use the software installation and maintenance feature to install software applications at computer startup, user logon, or on demand. You can also use this feature to upgrade deployed applications, remove earlier applications that are no longer required, and deploy service packs and operating system upgrades. They can ensure that a person cannot install any software from local media, such as a CD-ROM or disk.

This feature also provides for the following situations:

• If users inadvertently delete files from an application it will repair itself.

• If users move from one computer to another their software will always be available to them.

• If users do not have an application installed on their computer and they try to open a document associated with that application, the application will automatically be installed and the document will open.

Deploying software through Group Policy requires applications to use the Windows Installer service, which provides much more than just the capability to install applications. It also protects the integrity of the application against inadvertent mishaps with local files. For example, if a user attempted to use a copy of Microsoft Word that was missing some essential files, the Windows Installer service would reinstall the files from the install point, the next time that the application is launched.

In addition, Windows Installer-based applications that are deployed using Group Policy can install with elevated privileges, meaning users don't have to be administrators on their local machines to install software that you, as a network administrator, want them to have.

Application repair follows the same logic as on-demand installation. Whenever an application authored by Windows Installer is invoked, the Windows Installer service checks to ensure that the appropriate files are available; if required, files or settings are repaired automatically.

You use Group Policy to define software installation options that specify which applications are to be deployed, upgraded, or removed from a computer. You can apply software installation policies to groups of users or to groups of computers, depending on your organization's needs. There are two methods by which you can install applications on users' computers: assigning and publishing.

Assigning Applications

You can assign applications to either a user or a computer using Group Policy. When you assign applications to a computer, the application is automatically installed the next time the computer is started. When you assign applications to a user with Group Policy, the administrator can choose to either have the application installed on-demand when the user selects the application or in-full when the user next logs on:

• On Demand. If the application is installed on demand, the user's computer is set up with a Start menu shortcut, and the appropriate file associations are created in the registry. To the user, it looks and feels as if the application is already present. However, the application is not fully installed until the user needs the application. When the user attempts to open the application or a file associated with that application, Windows Installer checks to make sure that all the files and parameters of the application are present for the application to properly execute. If they are not present, Windows Installer retrieves and installs them from a predetermined distribution point. Once in place, the application opens.

• Full Install. The full-install option is useful for specific groups of users such as frequent travelers who might require all available applications to be fully installed before they travel. With full install, a user's applications are installed at logon.

Assigning applications makes them resilient — they are available no matter what the user does; for example, if the user removes an application, it will automatically be reinstalled on demand.

Publishing Applications

When you publish an application, it appears in Add or Remove Programsin Control Panel. Users can choose to install published applications. Installation can also be configured to occur automatically when a user attempts to open a file that requires a specific published application. You publish applications when the software is not absolutely necessary for users to perform their jobs.

In order to obtain the full benefits of publishing technology, all published applications should be authored to install using the Windows Installer service. Although you can still publish non-Windows Installer service applications using .ZAP files, you won't get the benefits of elevated privileges as explained earlier, and of course, you won't get the benefits of using Windows Installer either.

A .zap file is a text file that provides a pointer to the setup package, which enables the application to be listed in Add or Remove Programs.

For more information, see the "Software Installation and Maintenance" white paper at https://go.microsoft.com/fwlink/?linkid=13293 and the Step-by-Step Guide to Software Installation and Maintenance at https://www.microsoft.com/windows2000/techinfo/planning/management/swinstall.asp.

Scripts

With the Scripts extensions, you can assign scripts to run when the computer starts or shuts down or when users log on or off their computers. For this purpose, you can use Windows Script Host to include both Visual Basic® Scripting Edition (VBScript) and Jscript® development software script types.

Windows 2000 and later include Windows Script Host, a language-independent scripting host for 32-bit Windows platforms. For more information about Windows Script Host, see the Microsoft Windows Script Web site at https://www.microsoft.com/scripting.

The names of scripts and their command lines (in the form of registry keys and values) are stored in the Registry.pol file, described in "Registry.pol Files" later in this document.

Types of Scripts

The five script types are as follows:

• Group Policy logon scripts.

• Group Policy logoff scripts.

• Group Policy startup scripts.

• Group Policy shutdown scripts.

• Legacy logon scripts (those specified on the User object). This includes support for Windows Script Host scripts. Windows Script Host supports scripts written in VBScript or JavaScript. This means that you can now enter a command line like sample.vbs in the logon script path of the user object.

Specifying Policy Settings for Script Behavior

The following table lists the Group Policy options that are available to control the behavior of scripts.

Best Practice: For easier manageability, it is a good idea to use Group Policy scripts and to avoid using legacy logon scripts, if at all possible. Rather than using a single monolithic script with lots of internal logic branching, Group Policy-based logon scripts allow for use of tiered and modular scripts targeted to the desired set of users.

Folder Redirection

The Folder Redirection extension is used to redirect any of the following special folders in a user profile to an alternate location (such as a network file share):

• Application Data

• Desktop

• My Documents

  • My Pictures

• Start Menu

For example, you could redirect a user's My Documents directory to \\Server\Share\%username%. By redirecting the My Documents directory, you can provide the following advantages:

• Ensure that users' documents are available when they roam from one computer to another.

• Reduce the time it takes to log on to and log off from the network. The My Documents folder is part of the Roaming User Profile (RUP), which means that the My Documents folder and its contents are copied back and forth between the client computer and the server when users log on and log off. Relocating the My Documents folder outside of the user profile can significantly decrease that time.

• Store user data on the network (rather than on the local computer). The data can then be managed and protected by the Information Technology department.

• Make users' network-based My Documents folder available to users when they are disconnected from the corporate network by using Offline Folder technologies.

Folder Redirection Improvements for Windows XP and Windows Server 2003

This section provides information about the differences between Windows 2000 and Windows Server 2003.

User Interface changes

The Folder Redirection user interface has been simplified for Windows Server 2003. The main goals of these changes were to simplify the use of Folder Redirection by removing the requirement that administrators be familiar with environment variables such as %USERNAME%.

In addition to the simplified UI, several new redirection options have been added:

• Create a directory for each user under the root path. Rather than having to enter a UNC path such as \\server\share\%username%\MyDocuments, the administrator can simply type in the path to the file share such as \\server\share, and Folder Redirection will automatically append the user name and the directory name when the policy is applied. This removes the need for administrators to be familiar with environment variables, and minimizes the chances of errors and spelling mistakes.

• Redirect to home directory (My Documents Only). Windows Server 2003 and Windows XP allow you to redirect a user's My Documents folder to their home directory. This option is intended only for organizations that have a legacy deployment of home directories and want to transition users to the My Documents metaphor while maintaining compatibility with their existing home directory environment. You should only select this option if you have already deployed home directories in your organization.

• Folder redirection treats redirection to the home directory as a special case and certain checks are skipped:

  • Redirection to the home directory is only supported on Windows XP and Windows Server 2003 computers. Redirection to the home directory policy will fail to apply on Windows 2000 computers.

  • No security check is performed and no setting of access permissions is done. The administrator must set restrictive permissions on the directory to ensure that proper access is granted. The Grant the user exclusive rights to My Documents check box on the settings page of the property sheet is disabled.

  • No ownership checks are made. Normally folder redirection will fail if a user is not the owner of the directory they are being redirected to. Because redirection to the home directory is intended for use in a legacy environment, this ownership check is skipped.

  • Users must have the home folder property correctly set on their user object. The folder redirection client side extension retrieves the actual path for the user's home directory from the user object at logon time. Users affected by Folder Redirection Policy must have this path correctly set or folder redirection will not apply.

• Redirect to a specific path. This option is intended to allow an administrator to redirect folders to an alternate local drive/partition, or to enter unusual configurations not anticipated by the new user interface. Functionally it works in exactly the same way as the Windows 2000 folder redirection user interface.

• Redirect to the local user profile. This option is intended to allow an administrator to redirect the selected folder to the default location in the local user profile, for example: %userprofile%\<Folder Name>. This setting can be used to remove redirection for a particular folder, without removing the GPO. Note: Setting the redirection option to "Not Configured" (or "No Administrative policy specified" in the Windows 2000 UI) does not redirect the folder to the local profile, this option means that Folder Redirection is not configured – if a folder was previously redirected it will continue to be redirected to the previous location. If an administrator wanted to return the folder to the local user profile they can use this redirection setting.

My Pictures no longer shown in the Folder Redirection Node

To simplify the user interface and to help support the best practice that the My Pictures folder should always follow the My Documents folder, the My Pictures folder is not shown in the Folder Redirection node for new GPO's. If you have previously redirected the My Pictures folder separately, the My Pictures node will still appear.

Redirected Folders automatically made available offline

By default in Windows XP and Windows Server 2003, any redirected shell folders such as My Documents, Desktop, Start Menu, and Application Data are automatically made available offline. This is in contrast to Windows 2000, which required administrators to configure the "Administratively assigned offline files" policy setting to ensure all files in the redirected folders were always available offline. This setting was difficult to use with advanced folder redirection, and involved extra administrative overhead.

The default behavior can be overridden by enabling the Do not automatically make redirected folders available offline policy. This setting can be found in the Group Policy Object Editor in the User Configuration\Administrative Templates\Network\Offline Files section.

Note that on Windows Server 2003 Offline files are disabled by default.

More information about Folder Redirection will be available in the white paper, "User Data and Settings Management" at https://www.microsoft.com/grouppolicy.

Internet Explorer Maintenance

The Internet Explorer Maintenance extension snap-in includes policy settings to manage the following:

• Browser User Interface. You use these options to customize the browser's appearance. For example, you can specify settings for the browser title bar, toolbar button options, and so on.

• Connection Settings. You can preset and manage the connection settings, such as local area network (LAN) and dial-up options.

• Custom URLs. You can specify which URLs are displayed by the browser, for example, for the Home page, those on the Favorites list, and for the Search page.

• Security. You can preset security settings such as security zones, content ratings, and Authenticode. (A browser can be configured to allow only signed code to be downloaded. Authenticode is the Microsoft version of object signing; it provides a basis for verifying the origin and integrity of an object, as well as links to policies of a certification authority).

• Program Associations. You can specify which Internet programs to use by default for Internet-related tasks such as reading e-mail or viewing newsgroups.

Exporting Internet Explorer Settings for Earlier Clients

Administrators can export Internet Explorer policy settings into an auto-configuration package (an .ins file and its associated .cab files) to be used to apply these settings to Windows 95, Windows 98, and Windows NT 4.0 clients. The exported packages are auto-configuration packages. Before the original Group Policy Object Editor was created in Windows 2000, Internet Explorer settings were applied to Internet Explorer clients using auto-configuration packages after Internet Explorer installation. Using GPOs is the preferred method of applying Internet Explorer policy settings on clients running Windows 2000 or later, although Windows 2000 and Windows Server 2003 support auto-configuration packages.

Managing Internet Explorer Maintenance Advanced Settings

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.

For more information, see this Microsoft Knowledge Base article, How to Set Advanced Settings In Internet Explorer by Using Group Policy Objects.   

Using Internet Explorer Customization Wizard and Internet Explorer Profile Manager

Besides the Internet Explorer Maintenance Group Policy options mentioned above, it is also possible to customize Internet Explorer before deployment and to manage Internet Explorer on other operating systems by using the Internet Explorer Administration Kit (IEAK) at https://www.microsoft.com/windows/ieak/default.asp.These tools provide options for System Policies and restrictions that administrators can use to specify desktop, shell, and security settings, for example.

Remote Installation Services

Remote Installation Services is an optional component that is included in the Windows Server operating system and works with other Windows Server 2003 technologies to implement the Remote Operating System Installation feature. Administrators use Remote Operating System Installation to remotely install a copy of the Windows XP Professional operating system on supported computers. (Computers that are PC98-compliant ship with a PXE Remote Boot ROM.) Administrators use the Remote Installation Services extension of Group Policy to specify which options are presented to users by the Client Installation Wizard, for example, Automatic Setup, Custom Setup, and Restart Setup.

Client computers that are enabled with Pre-boot Execution Environment (PXE) remote-boot technology access the RIS server to install the operating system, and then the Remote Installation Services server checks for Group Policy that affects remote installation options defined for the user. The Boot Information Negotiation Layer (BINL) service running on the RIS server performs this work. It impersonates the user who logs on to the RIS client-side pre-boot user interface, and evaluates the GPOs to determine the resulting policy. Based on the resulting policy, it determines which screens to send to the pre-boot RIS client code for display to the user.