Skip to content Accesskey=4Skip to sub-navigation Accesskey=3View our Accessibility Options MIT Information Services and Technology Home About IS&T Contact IS&T Site Map Search Advanced Search
Getting StartedGetting Services by Topic or Alphabetically Getting Help
Photo Announcements

Windows Server Platforms


Introduction to Group Policy

Introduction

Group policies are collections of user and computer configuration settings that can be linked to computers, sites, domains, and organizational units (OUs) to specify the behavior of users' desktops. For example, using group policies, you can specify the programs that are available to users, the programs that appear on the user's desktop, and Start menu options.

Much of the first four sections of this document comes out of the Microsoft, MCSE Training Kit--Microsoft Windows 2000 Active Directory Services, Chapter 12, but there are some additions and changes specific to win.mit.edu, the WIN domain. Such changes appear in red. This document contains many comments by its original author, Joe Calzaretta.

  • Group Policy Concepts
    • Group Policy Objects
    • Group Policy Snap-In
    • Computer and User Configuration Settings
    • How Group Policy Affects Startup and Logon
    • How Group Policy is Processed
    • Group Policy Inheritance
    • Using Security Groups to Filter Group Policy
  • Implementing Group Policy
    • Creating a GPO
    • Delegating Administrative Control of a GPO
    • Specifying Group Policy Settings
    • Disabling Unused Group Policy Settings
    • Indicating GPO Processing Exceptions
    • Filtering GPO Scope
    • Linking a GPO
    • Modifying Group Policy
  • Managing Software Using Group Policy
    • Software Management Tools
    • Assigning Applications
    • How Software Installation Works
  • Customizing Windows Installer Packages
    • Implementing Software Installation
    • Managing Special Folders Using Group Policy
  • Additional Group Policy Information
    • What is the actual structure of a GPO?
    • Administrative Template Files
    • Registry.pol Files

Group Policy Concepts

Group Policy Objects
To create a specific desktop configuration for a particular group of users, you create group policy objects (GPOs). GPOs are collections of group policy settings. Each Windows 2000, XP or later (collectively, Windows) computer has one local GPO, and may in addition be subject to any number of nonlocal (Active Directory-based) GPOs.

One local GPO is stored on each computer whether or not the computer is part of an Active Directory environment or a networked environment. However, as the local GPO settings can be overridden by nonlocal GPOs, the local GPO is the least influential if the computer is in an Active Directory environment. In a non-networked environment (or in a networked environment lacking a Windows domain controller, DC), the local GPO's settings are more important because they are not overwritten by nonlocal GPOs.

Nonlocal GPOs are linked to Active Directory objects (sites, domains, or OUs) and can be applied to either users or computers. To use nonlocal GPOs, you must have a DC installed. Following the properties of Active Directory, nonlocal GPOs are applied hierarchically from the least restrictive group (site) to the most restrictive group (OU) and are cumulative.

This lesson discusses nonlocal GPOs unless otherwise specified.

The Group Policy Snap-In
A Microsoft Management Console (MMC) snap-in is used to organize and manage the many group policy settings in each GPO.

Ways to Open the Group Policy Snap-In

You can open the Group Policy snap-in in several ways, depending on what action you want to perform.

•To open the local Group Policy snap-in

  1. Open Microsoft Management Console.
  2. On the MMC console menu bar, click Console, and then click Add/Remove Snap-In.
  3. In the Add/Remove Snap-In dialog box, on the Standalone tab, click Add.
  4. In the Add Standalone Snap-In dialog box, click Group Policy, and then click Add.
  5. In the Select Group Policy Object dialog box, ensure that Local Computer appears in the Group Policy Object box.
  6. Click Finish, then click Close on the Add Standalone Snap-In dialog box.
  7. In the Add/Remove Snap-In dialog box click OK.

The Group Policy snap-in for the local computer is now available.

•To open the Group Policy snap-in from Active Directory Users and Computers

  1. Open Active Directory Users and Computers (dsa.msc). win.mit.edu Specific: Be careful to make sure you use the right snap-in for the right OS. There is a Win2K version and a WinXP version. They are not compatible and using the wrong one may possibly corrupt the Active Directory.
  2. In the console tree, right-click the domain or OU for which you want to set policy for, then click Properties.
  3. Click the Group Policy tab, click an entry in the Group Policy Object Links list to select an existing GPO, then click Edit. (Or, click New to create a new GPO, and then click Edit.)

The Group Policy snap-in for the domain or OU is now available.

•win.mit.edu Specific:

"To open the Group Policy snap-in from AD Container Management

  1. Open AD Container Management (adcontmgr.msc).
  2. In the console tree, right-click the domain root or OU you want to set group policy for, then click Properties.
  3. Click the Group Policy tab, click an entry in the Group Policy Object Links list to select an existing GPO, then click Edit/Properties. (Or, click Add/New/Delete to create a new GPO, and then click Edit/Properties.)

The Group Policy snap-in for the domain or OU is now available.

Computer and User Configuration Settings
Computer configuration settings are used to set group policies applied to computers, regardless of who logs on to them. Computer configuration settings are applied when the operating system initializes. win.mit.edu Specific: Container Administrators for the WIN domain will use only these settings.

User configuration settings are used to set group policies applied to users, regardless of which computer the user logs on to. User configuration settings are applied when users log on to a computer. win.mit.edu Specific: Container Administrators for the WIN domain are unable to use these settings, since there are no users in their OUs.

Both computer configuration settings and user configuration settings include Software Settings, Windows Settings, and Administrative Templates.

Software Settings
For both the computer configuration and user configuration, Software Settings contains only Software Installation settings by default. Software Installation settings help you specify how applications are installed and maintained within your organization. Software Installation settings also provide a place for independent software vendors to add settings.

You manage an application within a GPO that, in turn, is associated with a particular Active Directory container--a site, domain, or OU. Applications can be managed in one of two modes: assigned or published. You assign an application to a computer when you want computers or people managed by the GPO to have the application. You publish an application when you want the application to be available to people managed by the GPO, should a person want the application. You cannot publish an application to computers. win.mit.edu Specific: In the WIN domain, we assign software only to computers; we do not publish software to users.

Windows Settings
For both the computer configuration and user configuration, Windows Settings holds Scripts and Security Settings.

Scripts allow you to specify two types of scripts: startup/shutdown and logon/logoff. Startup/shutdown scripts run at computer startup or shutdown. Logon/logoff scripts run when a user logs on or off the computer. When you assign multiple logon/logoff or startup/shutdown scripts to a user or computer, W2K executes the scripts from top to bottom. You can determine the order of execution for multiple scripts in the Properties dialog box. When a computer is shut down, Windows first processes logoff scripts followed by shutdown scripts.

Administrators can use any ActiveX scripting language they are comfortable with. Some possibilities include VBScript, JScript, Perl, and MSDOS style batch files (.bat and .cmd).

Security Settings allows a security administrator to manually configure security levels assigned to a local or nonlocal GPO. This can be done after, or instead of, using a security template to set system security.

For the user configuration only, Windows Settings holds additional group policy settings for Internet Explorer Maintenance, Remote Installation Services, and Folder Redirection. Folder Redirection allows you to redirect Windows special folders (My Documents, Application Data, Desktop, and Start menu) from their default user profile location to an alternate location on the network, where they can be centrally managed.

Administrative Templates
For both the computer and user configurations, Administrative Templates contains all registry-based group policy settings, including settings for Windows Components, System, and Network. Windows Components allows you to administer Windows components including NetMeeting, Internet Explorer, Windows Explorer, Microsoft Management Console, Task Scheduler, and Windows Installer. System is used to control logon and logoff functions and group policy itself. Network allows you to control settings for Offline Files and Network and Dial-Up Connections.

For the computer configuration only, Administrative Templates contains additional group policy settings for Printers. Additionally, System Settings contains Disk Quotas, and Domain Name System (DNS) Client and Windows File Protection.

For the user configuration only, Administrative Templates contains additional registry-based group policy settings, including settings for Start Menu & Taskbar, Desktop, and Control Panel. Start Menu & Taskbar settings control a user's start menu and taskbar, and desktop settings control the appearance of a user's desktop. Control Panel settings determine the Control Panel options available to a user.

In Administrative Templates there are more than 450 of these settings available for configuring the user environment. In the registry, computer configurations are saved in HKEY_LOCAL_MACHINE (HKLM) and user configurations are saved in HKEY_CURRENT_USER (HKCU).

Note: You can display administrative template settings by clicking the Administrative Templates node, clicking View, then unchecking Show Policies Only to show all settings. win.mit.edu Specific: You never want to select "Show Policies Only". This will hide "preferences", which really are policies, for all intents and purposes. You can also check Show Configured Policies Only to show only those settings that have been configured.

How Group Policy Affects Startup and Logon
The following sequence shows the order in which computer configuration and user configuration settings are applied when a computer starts and a user logs on:

  1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) are started.
  2. An ordered list of GPOs is obtained for the computer. The list contents may depend on these factors:
    • Whether the computer is part of a Windows domain, and is therefore subject to group policy through Active Directory.
    • The location of the computer in Active Directory.
    • If the list of GPOs has not changed, then no processing is done. You can use a group policy setting to change this behavior. win.mit.edu Specific: And we do so in the WIN domain. We process folder redirection, registry, scripts, and security policy, even if the policies are unchanged.
  3. Computer configuration settings are processed. This occurs synchronously by default, and in the following order: local GPO, site GPOs, domain GPOs, OU GPOs, and so on. No user interface is displayed while computer configuration settings are being processed.
  4. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. You can use several group policy settings to modify this behavior.
  5. The user presses Ctrl+Alt+Delete to log on.
  6. After the user is validated, the user profile is loaded, governed by the group policy settings in effect.
  7. An ordered list of GPOs is obtained for the user. The list contents may depend on these factors:
    • Whether the user is part of a Windows domain, and is therefore subject to group policy through Active Directory.
    • Whether loopback is enabled, and the state (Merge or Replace) of the loopback policy setting.
    • The location of the user in Active Directory.
    • If the list of GPOs to be applied has not changed, then no processing is done. You can use a policy setting to change this behavior.
  8. User configuration settings are processed. This occurs synchronously by default, and in the following order: local GPOs, site GPOs, domain GPOs, OU GPOs, and so on. No user interface is displayed while user policies are being processed.
  9. Logon scripts run. Unlike Windows NT 4.0 scripts, group policy-based logon scripts are run hidden and asynchronously by default. The user object script runs last.
  10. The operating system user interface prescribed by group policy appears.

How Group Policy Is Processed
Group policy settings are processed in the following order:

  • Local GPO. Each Windows computer has exactly one GPO stored locally.
  • Site GPOs. Any GPOs that have been linked to the site are processed next. Processing is synchronous; the administrator specifies the order of GPOs linked to a site. win.mit.edu Specific: We do not use this in the WIN domain.
  • Domain GPOs Multiple domain-linked GPOs are processed synchronously; the administrator specifies the order of GPOs linked to a domain.
  • OU GPOs. GPOs linked to the OU highest in the Active Directory hierarchy are processed first, followed by GPOs linked to its child OU, and so on. Finally, the GPOs linked to the OU that contains the user or computer are processed. At the level of each OU in the Active Directory hierarchy, one, many, or no GPOs can be linked. If several group policies are linked to an OU, then they are processed synchronously in an order specified by the administrator.

This order means that the local GPO is processed first, and GPOs linked to the OU of which the computer or user is a direct member are processed last, overwriting the earlier GPOs. For example, you set up a domain GPO to allow anyone to log on interactively. However, an OU GPO, set up for the DC, prevents everyone from logging on except for certain administrative groups.

Exceptions to the Processing Order
The default order of processing group policy settings is subject to the following exceptions:

  • A computer that is a member of a workgroup processes only the local GPO.
  • No Override. Any GPO linked to a site, domain, or OU (not the local GPO) can be set to No Override with respect to that site, domain, or OU, so that none of its policy settings can be overridden. When more than one GPO has been set to No Override, the one highest in the Active Directory hierarchy (or higher in the hierarchy specified by the administrator at each fixed level in Active Directory) takes precedence. No Override is applied to the GPO link.

  • Block Policy Inheritance. At any site, domain, or OU, group policy inheritance can be selectively marked as Block Policy Inheritance. However, GPO links set to No Override are always applied and cannot be blocked.
    Note: Block Policy Inheritance is applied directly to the site, domain, or OU. It is not applied to GPOs, nor is it applied to GPO links. Thus, Block Policy Inheritance deflects all group policy settings that reach the site, domain, or OU from above (by way of linkage to parents in the Active Directory hierarchy) no matter from what GPOs those settings originate.

  • Loopback setting. Loopback is an advanced group policy setting that is useful on computers in certain closely managed environments such as kiosks, laboratories, classrooms, and reception areas. win.mit.edu Specific: This can be dangerous! Loopback provides alternatives to the default method of obtaining the ordered list of GPOs whose user configuration settings affect a user. By default, a user's settings come from a GPO list that depends on the user's location in Active Directory. The ordered list goes from site-linked to domain-linked to OU-linked GPOs, with inheritance determined by the location of the user in Active Directory and in an order specified by the administrator at each level.
    Note: Loopback can be Not Configured, Enabled, or Disabled, as can any other group policy setting. In the Enabled state, loopback can be set to Merge or Replace mode.
    • Replace. In this case, the GPO list for the user is replaced in its entirety by the GPO list already obtained for the computer at computer. The computer's GPOs replace the user GPOs normally applied to the user.
    • Merge. In this case, the GPO list is concatenated. The GPO list obtained for the computer at computer startup is appended to the GPO list obtained for the user at logon (Step 7). Because the GPO list obtained for the computer is applied later, it has precedence if it conflicts with settings in the user's list.

Group Policy Inheritance
In general, group policy is passed down from parent to child containers. If you have assigned a separate group policy to a parent container, that group policy applies to all containers beneath the parent container, including the user and computer objects in the container. However, if you specify a group policy setting for a child container, the child container's group policy setting overrides the setting inherited from the parent container.

If a parent OU has policy settings that are not configured, the child OU doesn't inherit them. Policy settings that are disabled are inherited as disabled. Also, if a policy is configured for a parent OU, and the same policy is not configured for a child OU, the child inherits the parent's policy setting.

If a parent policy and a child policy are compatible, the child inherits the parent policy, and the child's setting is also applied. Policies are inherited as long as they are compatible. For example, if the parent's policy causes a certain folder to be placed on the desktop and the child's setting calls for an additional folder, the user sees both folders.

If a policy configured for a parent OU is incompatible with the same policy configured for a child OU, the child does not inherit the policy setting from the parent. The setting in the child is applied.

Using Security Groups to Filter Group Policy
Because you can link more than one GPO to a site, domain, or OU, you may need to link GPOs associated with other directory objects. By setting the appropriate permissions for security groups, you can filter group policy to influence only the computers and users you specify.

[Back to top]

Implementing Group Policy

Creating a GPO
The first step in implementing a group policy is to create a GPO. Recall that a GPO is a collection of group policy settings. win.mit.edu Specific: In the WIN domain, only Domain Administrators can create a GPO. The most common time to do this is when a new container is created, and we want to give the container admin a GPO to use.

•To create a GPO

  1. Open Active Directory Users and Computers or AD Container Management.
  2. Right-click the domain, or OU for which you want to create a GPO, click Properties, and select the Group Policy tab.
  3. Click New, then type the name you would like to use for this GPO. win.mit.edu Specific: For the WIN domain, we try to follow a "GP.containername" naming convention. If you have multiple GPOs per container, you might want to append a number to the name or choose another reasonable convention.

    4. By default, the new GPO is linked to the site, domain, or OU that was selected in the MMC when it was created and its settings apply to that site, domain, or OU.

  4. Click Close.

    5. win.mit.edu Specific: Unfortunately, when you create a GPO, the administrative templates (.adm files) are copied from the machine with which you create the GPO. This is unfortunate because it would be much more useful if all GPOs had a consistent set of .adm files. We keep such a set of files in \\win.mit.edu\sysvol\win.mit.edu\utils\Administrative Templates. After you create a GPO, you should copy all the adm files into the GPO's directory structure. We also have a program which copies these .adm files into all the GPOs in the WIN domain. It takes a minute or so to complete but then you know that at least all GPOs have a common baseline.

  5. Run \\win.mit.edu\sysvol\win.mit.edu\utils\Administrative Templates\copy-adms.cmd.

Delegating Administrative Control of a GPO
After you create a GPO, it is important to determine which groups of administrators have access permissions to the GPO. win.mit.edu Specific: You typically want to give full control (or at least read-write) to the container administrator group.

•To delegate administrative control of a GPO

  1. Access the Group Policy snap-in for the GPO.
  2. Right-click the root node of the console and click Properties.
  3. Click the Security tab, then click the security group for which you want to allow or deny administrative access to the GPO.
    Note: If you need to change the list of security groups for which you want to allow or deny administrative access to the GPO, you can add or remove security groups using Add and Remove.
  4. To provide administrative control of all aspects of the GPO, set the Read permission to Allow and set the Write permission to Allow.
    Note: A user or administrator who has Read access but does not have Write access to a GPO cannot use the Group Policy snap-in to see the settings that it contains. All extensions to the Group Policy snap-in require Write access to open a GPO. win.mit.edu Specific: As of 2003, there are GP tools that allow you to view GPO settings if you only have read access. We regard GPMC as such a tool.
  5. Click OK.

Specifying Group Policy Settings
After you create a GPO and determine the administrators who have access permissions to the GPO, you can specify the group policy settings.

•To specify group policy settings for a GPO

  1. Access the Group Policy snap-in for the GPO.
  2. In the console tree, expand the item that represents the particular policy you want to set.
  3. In the details pane, right-click the policy that you want to set, then click Properties.
  4. Click Enabled to apply the policy to users or computers that are subject to this GPO, then click OK.
    Note: Not Configured indicates that no change will be made to the registry regarding this setting. Disabled indicates that the registry will indicate that the policy does not apply to users or computers that are subject to this GPO.

Disabling Unused Group Policy Settings
If a GPO has, under the Computer Configuration or User Configuration node of the console, only settings that are Not Configured, then you can avoid processing those settings by disabling the node. This action expedites startup and logon for those users and computers subject to the GPO. win.mit.edu Specific: Most containers in the WIN domain contain computers or users but not both. GPOs linked only to such containers are good candidates for this procedure.

•To disable the Computer Configuration or User Configuration settings for a GPO

  1. Access the Group Policy snap-in for the GPO.
  2. Right-click the root node of the console and click Properties.
  3. In the General tab in the Properties dialog box:
    • To disable the Computer Configuration settings, click the Disable Computer Configuration Settings check box.
    • To disable the User Configuration settings, click the Disable User Configuration Settings check box.
  4. Click OK.

Indicating GPO Processing Exceptions
GPOs are processed according to the Active Directory hierarchy: local GPO, site GPOs, domain GPOs, and OU GPOs. However, the default order of processing group policy settings may be changed by modifying the order of GPOs for an object, specifying the Block Policy Inheritance option, specifying the No Override option, or by enabling the Loopback setting.

•To modify the order of GPOs for an object

  1. Open Active Directory Users and Computers to set the order of GPOs for a domain or OU.
  2. In the console tree, right-click the domain or OU for which you want to modify the GPO order, click Properties, then click the Group Policy tab.
  3. In the Group Policy Object Links list, select the GPO and click the Up or Down button to change the priority for a GPO for this site, domain, or OU. Windows processes GPOs from the top of the list to the bottom of the list.

•To specify the Block Policy Inheritance option

  1. Open Active Directory Users and Computers to specify the Block Policy Inheritance option for a domain or OU.
  2. In the console tree, right-click the domain or OU for which you want to specify the Block Policy Inheritance option, click Properties, then click the Group Policy tab.
  3. Select the Block Policy Inheritance check box to specify that all GPOs linked to higher level sites, domains, or OUs should be blocked from linking to this site, domain, or OU. You cannot block GPOs that use the No Override option (see later).

•To specify the No Override option

  1. Open Active Directory Users and Computers to specify the No Override option for a domain or OU.
  2. In the console, right-click the domain or OU to which the GPO is linked, click Properties, then click the Group Policy tab.
  3. Select the GPO, click Options, select the No Override check box in the Options dialog box to specify that other GPOs should be prevented from overriding settings in this GPO, then click OK.

•To enable the Loopback setting

(win.mit.edu Specific: It is not recommended that you do this unless you know what you are doing. It could have very bizarre results.)

  1. Access the Group Policy snap-in for the GPO.
  2. In the console tree, expand Computer Configuration, Administrative Templates, System, and Group Policy.
  3. In the details pane, double-click User Group Policy Loopback Processing Mode.
  4. In the User Group Policy Loopback Processing Mode Properties dialog box, click Enabled.
  5. Select one of the following modes in the Mode list:
    • Replace to replace the GPO list for the user with the GPO list already obtained for the computer at computer startup.
    • Merge to append the GPO list obtained for the user at logon with the GPO list already obtained for the computer at computer startup.
  6. Click OK.

Filtering GPO Scope
The policies in a GPO apply only to users or computers who have both Read and Apply Group Policy permissions for that GPO. You can filter the scope of a GPO by creating security groups and then assigning Read permission to the selected groups. Thus, you can prevent a policy from applying to a specific group by denying that group Read permission to the GPO. (win.mit.edu Specific: These groups can be groups of computers. In Moira there are groups of computers corresponding to the containers in the WIN domain. Most of them are named "cnt-containername," but you can query Moira to find out.)

•To filter the scope of a GPO

  1. Access the Group Policy snap-in for the GPO.
  2. Right-click the root node of the console, then click Properties.
  3. Click the Security tab, and then click the security group through which to filter this GPO.
    Note: If you need to change the list of security groups through which to filter this GPO, you can add or remove security groups using Add and Remove.
  4. Set the permissions as shown in the table below, then click OK.

    5. GPO Scope
    Set These Permissions
    Result
    Members of this security group should have this GPO applied to them. Set Apply Group-Policy (AGP) to Allow. Set Read to Allow. This GPO applies to members of this security group unless they are members of at least one other security group that has AGP set to Deny, or Read set to Deny, or both.
    Members of this security group are exempt from this GPO. Set AGP to Deny. Set Read to Deny. This GPO never applies to members of this security group regardless of the permissions those members have in other security groups.
    Membership in this security group is irrelevant to whether the GPO should be applied. Set AGP to neither Allow nor Deny. Set Read to neither Allow nor Deny. This GPO applies to members of this security group only if they have both AGP and Read set to Allow as members of at least one other security group. They also must not have AGP or Read set to Deny as members of any other security group.

Linking a GPO
By default, a new GPO is linked to the domain or OU that was selected in the MMC when it was created. Therefore, its settings apply to that domain or OU. Use the Group Policy tab for the domain or OU properties to link a GPO to additional domains or OUs.

•To link a GPO to a domain or OU

  1. Open Active Directory Users and Computers to link a GPO to a domain or OU.
  2. In the console, right-click the site, domain, or OU to which the GPO should be linked.
  3. Click Properties, then click the Group Policy tab.
  4. If the GPO already appears in the Group Policy Object Links list, then click Cancel. If the GPO does not appear in the Group Policy Object Links list, then click Add.
  5. In the Add A Group Policy Object Link dialog box, click the All tab, click the desired GPO, then click OK.
  6. In the Properties dialog box for the site, domain, or OU, click OK.

Modifying Group Policy
The tasks for modifying group policy are

  • Removing a GPO link
  • Deleting a GPO
  • Editing a GPO or its settings

Removing a GPO link
Removing a GPO link simply unlinks the GPO from the specified domain or OU. The GPO remains in Active Directory until it is deleted.

•To remove a GPO link

  1. Open Active Directory Users and Computers to unlink a GPO from a domain or OU.
  2. In the console, right-click the domain or OU from which the GPO should be unlinked.
  3. Click Properties, then click the Group Policy tab.
  4. In the Group Policy tab, select the GPO that you want to unlink, then click Delete.
  5. In the Delete dialog box, click Remove The Link From The List.

The GPO remains in Active Directory but is no longer linked.

Deleting a GPO
If you delete a GPO, it is removed from Active Directory, and any domains or OUs to which it is linked will no longer be affected by it. You may wish to take the less drastic step of removing the GPO link, which disassociates the GPO from its OU but leaves the GPO intact in Active Directory.

•To delete a GPO

  1. Open Active Directory Users and Computers to delete a GPO from a domain or OU.
  2. In the console, right-click the domain or OU from which the GPO should be deleted.
  3. Click Properties, then click the Group Policy tab.
  4. In the Group Policy tab, select the GPO that you want to delete, then click Delete.
  5. In the Delete dialog box, click Remove The Link And Delete The Group Policy Object Permanently, then click OK.

The GPO is removed from Active Directory.

Editing a GPO or its settings

To edit a GPO or its settings, follow the procedures outlined earlier in this lesson for creating a GPO and for specifying group policy settings.

[Back to top]

Managing Software Using Group Policy

The Software Installation extension, a software management feature of Windows, is the administrator's primary tool for managing software within an organization. Managing software using Software Installation provides your users with immediate access to the software they need to perform their jobs and ensures that users have an easy and consistent experience when working with software throughout its life cycle. Users no longer need to look for a network share, use a CD-ROM, or install, fix, and upgrade software themselves. This lesson walks you through the steps for implementing Software Installation.

Software Management Tools
Three tools are provided with Windows Server for software installation and maintenance:

    Tool

    Role

    The Software Installation extension of the Group Policy snap-in

    Used by administrators to manage software

    Windows Installer

    Installs software packaged in Windows Installer files

    Add/Remove Programs in Control Panel

    Used by users to manage software on their own computers

Software Installation Extension
The Software Installation extension is the administrator's primary tool for managing software within an organization. Software Installation works in conjunction with group policy and Active Directory, establishing a group policy-based software management system that allows you to centrally manage:

  • Initial deployment of software.
  • Mandatory and non-mandatory upgrades, patches, and quick fixes for software. You can update a version of the software or replace it. You can even upgrade the operating system using service packs. win.mit.edu Specific: Unfortunately in practice, the service pack MSIs are the barest of wrappers around the executable. They do not know that they have been successfully installed, and cause constant failure messages in the event logs even when everything is fine.
  • Removal of software.

Using Software Installation, you can centrally manage the installation of software on a client computer by assigning applications to users or computers or by publishing applications for users. Assign required or mandatory software to users or to computers. Publish software that users might find useful to perform their jobs. win.mit.edu Specific: MIT does not assign or publish software to users.

Assigning Applications
When you assign an application to the computer, the application is advertised and the installation is performed when it is safe to do so. Typically this happens when the computer starts up so that there are no competing processes on the computer. win.mit.edu Specific: Startup is the only time this has been noted to have occurred.

How Software Installation Works
The Software Installation extension uses Windows Installer technology to systematically maintain software. Windows Installer is a service that allows the operating system to manage the installation process. Windows Installer is composed of three key parts:

  • An operating system service that performs the installation, modification, and removal of the software in accordance with the information in the Windows Installer package.
  • The Windows Installer package, a database containing information that describes the installed state of the application.
  • An application programming interface (API) that allows applications to interact with Windows Installer to install or remove additional features of the application after the initial installation is complete.

Because Software Installation leverages Windows Installer, users can take advantage of self-repairing applications. Windows Installer notes when a program file is missing and immediately reinstalls the damaged or missing files, thereby fixing the application.

The Windows Installer package is a file that contains explicit instructions on the installation and removal of specific applications. The developer who produces the application provides the Windows Installer package .msi file and ships it with the application. If a Windows Installer package does not come with an application, you might need to create a Windows Installer package, or repackage the application, using a third-party tool.

You can deploy software using the Software Installation extension only if the file type fits one of the following categories:

  • Native Windows Installer package (.msi) files are developed as a part of the application and take full advantage of the Windows Installer.
  • Repackaged application (.msi) files allow you to repackage applications that do not have a native Windows Installer package in much the same way that you repackage software today to customize installations.
  • An existing setup program--an application (.zap) file--installs an application by using its original SETUP.EXE (or other executable) program.

In addition, you can make modifications (usually called transforms) to customize the installation of a Windows Installer package at the time of assignment or publication. Modifications are saved with the .mst file extension.

Other files you may encounter during Software Installation are:

  • Patch (.msp) files, which are used for bug fixes, service packs, and similar files
  • Application assignment scripts (.aas files), which contain instructions associated with the assignment or publication of a package

[Back to top]

Customizing Windows Installer Packages

You can customize Windows Installer applications by using modifications, also called transforms. The Windows Installer package format provides for customization by allowing you to "transform" the original package using authoring and repackaging tools like Wise for Windows Installer. Some applications also provide wizards or templates that permit a user to create modifications.

For example, Microsoft Office 2000 supplies a Customization Wizard that builds modifications. Using the Microsoft Office 2000 Customization Wizard, you can create a modification that allows you to manage the configuration of Microsoft Office 2000 that is deployed to users. A modification might be designed to accommodate Microsoft Word as a key feature, installing it during the first installation. Less popular features, such as revision support or document translators, could install on first usage, and other features, such as clip art, might not install at all. You might have another modification that provides all of the features of Word and does not install Microsoft PowerPoint. The exact mix of which features to install and when to install them varies based on the audience for the application and how they use the software.

Implementing Software Installation
The tasks for implementing software installation are:

  • Planning and preparing the software installation
  • Setting up a software distribution point
  • Specifying software installation defaults
  • Deploying software applications
  • Setting automatic installation options
  • Setting up application categories
  • Setting software application properties
  • Maintaining software applications

Planning and preparing the software installation
When planning a software installation:

  • Review your organization's software requirements on the basis of your overall organizational structure within Active Directory and your available GPOs.
  • Determine how you want to deploy your applications.
  • Create a pilot to test how you want to assign or publish software to users or computers.
  • Prepare your software using a format that allows you to manage it based on what your organization requires, and test all of the Windows Installer packages or repackaged software.

Software licenses are required for software written by independent software vendors and distributed using software distribution points (SDPs). It is your responsibility to match the number or identities of users or computers, dongles, etc., who can access software to the number of licenses you have on hand. It is also your responsibility to verify that you are working within the guidelines provided by each independent software vendor with the software. Gather the package formats for the software and perform any necessary modifications to the packages.

Setting up a software distribution point (SDP)
After you have planned and prepared for software management, the next step is to copy the software to one or more SDPs, network locations from which people are able to get the software that they need.

•To set up a software distribution point:

  1. Create the folders for the software on the file server that will be the SDP and make the folders network shares. For example: \\win.mit.edu\dfs\msi\folder.
  2. Replicate the software to the SDPs by placing or copying the software, packages, modifications, all necessary files, and components to a distribution share(s). Place all software (the package and all related installation files) in a separate folder on the SDP.
  3. Set the appropriate permissions on the folders so that only administrators can change the files (Read and Write), and that only the appropriate users/computers can only read the files from the SDP folders and shares. Use group policy to manage the software within the appropriate GPO.

Specifying software installation defaults
A GPO can contain several settings that affect how an application is installed, managed, and removed. You can globally define the default settings for the new packages within the GPO in the General tab of the Software Installation Properties dialog box. Some of these settings can be changed later by editing the package properties in the Software Installation extension.

•To specify software installation defaults:

  1. Open the Group Policy snap-in, then in Computer or User Configuration open Software Settings.
  2. Right-click the Software Installation node, then click Properties.
  3. In the General tab of the Software Installation Properties dialog box, type the path to the default SDP for packages (.msi files) in the Default Package Location box. win.mit.edu Specific: A good choice is \\win.mit.edu\dfs\msi.
  4. In the New Packages section, select one of the following:
    • Display The Deploy Software Dialog Box to specify that when you add a new package, the Deploy Software dialog box will display, allowing you to assign, publish, or configure package properties.
    • Advanced Published Or Assigned to specify that when you add a new package, the Configure Package Properties form should appear.
  5. Depending on your preference, you can check the Uninstall The Applications When They Fall Out Of The Scope Of Management check box to specify that the package should be removed when the GPO no longer applies to users or computers.
  6. Click OK.

Deploying software applications

Feature

Assign (Computer)

Following deployment the software is available for installation after:

The next time the computer starts

Can the user remove the software using Add/Remove Programs in Control Panel?

No. Only the local administrator can remove the software; a user can run a repair on the software

Supported installation files:

Windows Installer packages

Modifications, or .mst files, are customizations applied to Windows Installer packages. A modification must be applied at the time of assignment or publication, not at the time of installation.

Assigning applications
Assign an application when you want everyone to have the application on his or her computer.

•To assign applications:

  1. Open the Group Policy snap-in, then, in Computer Configuration, open Software Settings.
  2. Right-click the Software Installation node, click New, and click Package.
    Result: The File Name list in the Open dialog box shows those Windows Installer packages located at the SDP you specified as the default. If the Windows Installer package is located on a different network share, you can browse to find the SDP for the package.
  3. In the File Name list in the Open dialog box, select the Windows Installer package to be assigned, then click Open.
  4. In the Deploy Software dialog box, click Assigned (or Advanced Published and Assigned), then click OK. If this is an application under the Computer Configuration node of the Group Policy snap-in, the Published choice appears dimmed, because packages can only be assigned to computers, not published.

Deploying applications with modifications
Modifications are associated with the Windows Installer package at deployment time rather than when the Windows Installer is actually using the package to install or modify the application. Modifications (.mst files) are applied to Windows Installer packages (which have the .msi extension) in an order specified by the administrator. This order must be determined before the application is assigned or published.

•To add or remove modifications for applications:

  1. Open the Group Policy snap-in, then, in Computer or User Configuration, open Software Settings.
  2. Right-click the Software Installation node, click New, then click Package.
  3. In the File Name list in the Open dialog box, select the Windows Installer package to be published, then click Open.
  4. In the Deploy Software dialog box, click Advanced Published Or Assigned, then click OK.
  5. In the Properties dialog box for the package, click the Modifications tab.
    • To add modifications, click Add. In the Open dialog box, browse to find the modification file (.mst), then click Open. You can add multiple modifications.
    • To remove modifications, click the modification you want to remove, then click Remove. Repeat until each unwanted modification has been removed.
    • To set the order of modifications, select a modification and then click Move Up or Move Down. Modifications are applied according to the order specified in the list.
  6. Make sure that the modifications are configured exactly the way you want them, then click OK.

Important: Do not click OK until you have finished configuring the modifications. When you click OK, the package is assigned or published immediately. If the modifications are not properly configured you will have to uninstall the package or upgrade the package with a correctly configured version.

Setting automatic installation options
To determine which application users install when they select a file, you can select a file extension and configure a priority for installing applications associated with the file extension using the File Extensions tab in the Software Installation Properties dialog box. The first application listed is the application installed in association with the file extension.

For example, if you use a GPO to deploy both Microsoft Word 2000 and Microsoft FrontPage 2000, both of these applications can edit HyperText Markup Language (HTML) documents, files with the .htm extension. To configure the file extension priority so that users who are managed by this GPO always install Microsoft FrontPage, set FrontPage as the application with the highest priority for the .htm extension. When users managed by this GPO who have installed neither Microsoft Word 2000 nor Microsoft FrontPage 2000 receive an .htm file (by email or other means) and they double-click on the .htm file, Software Installation installs FrontPage 2000 and opens the .htm file for editing. Without Software Installation, the user would see the Open With dialog box and be asked to select the best alternative from the software already present on his or her computer.

File extension associations are managed on a per-GPO basis. Changing the priority order in a GPO affects only those users who have that GPO applied to them.

•To set automatic installation options based on file name extension:

  1. Open the Group Policy snap-in, then, in Computer Configuration, open Software Settings.
  2. Right-click the Software Installation node, then click Properties.
  3. In the File Extensions tab of the Software Installation Properties dialog box, select the file extension for which you want to specify an automatic software installation from the Select File Extension list.
  4. In the Application Precedence list box, move the application with the highest precedence by default to the top of the list using the Up or Down buttons. The application at the top of the list is automatically installed if a document with the selected file name extension is invoked before the application has been installed.
  5. Click OK.

Setting up application categories
You can organize assigned and published applications into logical categories to make it easier for users to locate the appropriate application from within Add/Remove Programs in Control Panel. Windows does not ship with any predefined categories. win.mit.edu Specific: MIT has not done this.

Setting software application properties
You can fine-tune each application by editing installation options, specifying application categories to be used, and setting permissions for the software installation.

Editing installation options for applications
Although you may have globally defined the default settings for new packages within the GPO in the General tab of the Software Installation Properties dialog box, some of these same settings can be changed later by editing the package properties. Installation options affect how an application is installed, managed, and removed.

•To edit installation options for applications:

  1. Open the Group Policy snap-in, then, in Computer Configuration, open Software Settings.
  2. Click the Software Installation node.
  3. In the details pane, right-click the application for which you want to edit installation options, then click Properties.
  4. In the Deployment tab of the Properties dialog box for the application, select the Assigned Deployment Type to allow users in the selected site, domain, or OU to receive this application the next time they log on (for assignment to users) or when the computer restarts (for assignment to computers).
  5. In the Deployment Options area, select one of the following:
    • Uninstall This Application When It Falls Out Of The Scope Of Management to remove the application at logon (for users) or startup (for computers) if they move to a site, domain, or OU for which the application is not deployed.
    • Do Not Display This Package In The Add/Remove Programs Control Panel to specify that this package should not be displayed in Add/Remove Programs in Control Panel.
  6. In the Installation User Interface Options area, select one of the following: (win.mit.edu Specific: These should not matter, as the install will always be non-interactive. Leave it at Basic.)
    • Basic to provide only a basic display to users during the install process.
    • Maximum to provide all installation messages and screens to users during the package installation.
  7. Click Advanced to display the Advanced Deployment Options dialog box. In the Advanced Deployment Options area, select either of the following check boxes:
    • Ignore Language When Deploying This Package to specify whether to deploy the package even if it is in a different language.
      or
    • Remove Previous Installs Of This Product From Computers If Product Was Not Installed By Group Policy-Based Software Installation to specify whether to remove previous installs of this product from computers if product was not installed by group policy-based Software Installation.
  8. Click OK.
  9. In the Properties dialog box, click OK.

Setting permissions for software installation
Permissions set for software installation pertain to only the application installation.

•To set permissions for software installation:

  1. Open the Group Policy snap-in, then, in Computer or User Configuration, open Software Settings.
  2. Click the Software Installation node.
  3. In the details pane, right-click the application for which you want to specify software installation permissions, then click Properties.
  4. In the Security tab of the application's Properties dialog box, click the security group on which to set permissions.
    Note: Administrators who manage the application installation should have the Full Control permission set to Allow. Computers who use the software assigned by the application should have the Read permission set to Allow.
  5. Click OK.

Maintaining software applications
After the deployment of software applications it may be necessary to upgrade or remove them at some point in the software life cycle.

Upgrading applications
Several events in the life cycle of the software can trigger an upgrade, including the following:

  • The original developer of the software might release a new version with new and improved features
  • The organization might choose to use a different vendor's application

Upgrades typically involve major changes to the software and normally have new version numbers. Usually a substantial number of files change for an upgrade. You can use the Software Installation extension to establish the procedure to upgrade an existing application to the current release.

•To upgrade applications:

  1. Open the Group Policy snap-in, then, in Computer Configuration, open Software Settings.
  2. Click the Software Installation node.
  3. In the details pane, right-click the Windows Installer package that will function as the upgrade (not the package to be upgraded), then click Properties. You will have previously assigned this package.
  4. In the Upgrades tab of the application's Properties dialog box, click Add to create or add to the list of packages that are to be upgraded by the current package.
  5. In the Add Upgrade Package dialog box, specify either Current Group Policy Object or A Specific GPO as the source of the package to be upgraded. In the latter case, click Browse, click the GPO you want, and then in the Browse For A Group Policy Object dialog box, click OK.
    Result: A list of all the other packages assigned to be published within the selected GPO appears under the heading Package To Upgrade. Depending on the GPO, this list may have zero or more entries.
  6. Click the package to upgrade.
  7. Click either Uninstall The Existing Package, Then Install The Upgrade Package, or Package Can Upgrade Over The Existing Package, then click OK. Typically, the uninstall option is for replacing an application with a completely different one (perhaps from a different vendor). The upgrade option is for installing a newer version of the same product while retaining the user's application preferences, document type associations, and so on.

Removing applications
At some point, users may no longer require an application, so you may need to remove it. The following two scenarios are addressed through the removal choices set within the Software Installation extension:

  • A version of a software application is no longer supported. Administrators can remove the software version from Software Installation without forcing the (physical) removal of the software from the computers of users who are still using the software.
  • A software application is no longer used. Administrators can force the removal of the software. The software is automatically deleted from a computer, the next time the computer is turned on.  Users cannot install or run the software.

Note: When you originally deploy the software, if you want the application to be removed when a GPO no longer applies, select the Uninstall This Application When It Falls Out Of The Scope of Management option.

•To remove applications:

  1. Open the Group Policy snap-in, then in Computer Configuration, open Software Settings.
  2. Click the Software Installation node.
  3. In the details pane, right-click the application you want to remove, click All Tasks, then Remove.
  4. In the Remove Software Dialog box, select one of the following removal options:
    • Immediately Uninstall The Software From Users And Computers. Select this option to specify that the application be removed the next time a user restarts the computer.
    • Allow Users To Continue To Use The Software, But Prevent New Installations. Select this option to specify that users can continue to use the application if they have already installed it. If they remove the application or have never installed it, they will not be able to install it.
  5. Click OK.

Managing Special Folders Using Group Policy

win.mit.edu Specific: MIT uses Folder Redirection, but not via the straight Group Policy interface. Instead, we use a Registry.pol file to explicitly set registry entries to effect folder redirection. Group Policy does not allow %HOMESHARE% to appear in the redirected folders.

This section ends the material adapted from the MCSE Training Kit.

[Back to top]

Additional Group Policy Information

Here is some information left out of the training kit, but very useful to know. I am not making distinctions here between Group Policy in general and the setup in the WIN domain.

What is the actual structure of a GPO?
GPOs are stored as a hierarchy of files, located in the sysvol share, specifically here: \\win.mit.edu\sysvol\win.mit.edu\Policies. Each subdirectory corresponds to a GPO. Unfortunately, these subdirectories are 128-bit GUIDs represented in hex. Like this: {01234567-89AB-CDEF-0123-456789ABCDE}. If you open the Group Policy editor snap-in for the object, this GUID will be listed in the Properties tab.

Under the GUID-named directory are the following subdirectories:

Adm: administrative template files with the extension .adm reside here.

Machine: files corresponding to Computer Configuration settings reside here. Specifically, "registry.pol", which pushes registry settings into HKLM. These settings correspond to choices made in the Administrative Templates portion of the snap-in, or from manual editing of registry.pol.

Machine\Scripts\Shutdown: If you assign machine shutdown scripts via Group Policy and do not point them to a particular UNC path, you can place the scripts here.

Machine\Scripts\Startup: If you assign machine startup scripts via Group Policy and do not point them to a particular UNC path, you can place the scripts here.

User: files corresponding to User Configuration settings reside here. Specifically, "registry.pol," which pushes registry settings into HKCU. These settings correspond to choices made in the Administrative Templates portion of the snap-in, or from manual editing of registry.pol.

User\Scripts\Logoff: If you assign user logoff scripts via Group Policy and do not point them to a particular UNC path, you can place the scripts here.

User\Scripts\Logon: If you assign user logon scripts via Group Policy and do not point them to a particular UNC path, you can place the scripts here.

Administrative Template Files
Administrative template (.adm) files, when placed in the proper subdirectory of a GPO, extend the "Administrative Templates" portion of the Computer or User Configuration in the group policy snap-in. These extensions are settings which can be enabled, disabled, or otherwise configured by a container or domain administrator, and which correspond to registry settings pushed to computers/users by the GPO. The administrative template file is therefore a mapping between user interface elements and registry settings.

Microsoft says:

The Group Policy Object Editor obtains registry-based policy settings from an administrative template file. An administrative template (.adm) file is a text file that specifies the registry-based policy that can be modified through the Group Policy Object Editor. If you need to provide policy settings specific to your application, you can extend registry-based policy by using .adm files. The Administrative Templates extension to Group Policy provides this capability. The extension writes the settings that you specify to secure registry keys. Your application can read the registry keys and use them accordingly.

Registry-based data is appropriate for many types of policy settings, and it is also the least complex way to create your own policy settings. In addition, registry-based policy managed through .adm files automatically supports Resultant Set of Policy (RSoP) capabilities.

The Administrative Template File Format is available online at the MSDN web site.

It is a nested tag-based format, but unfortunately is not xml.

Microsoft recommends that adm files only refer to keys underneath HKEY_LOCAL_MACHINE\Software\Policies or HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies or HKEY_CURRENT_USER\Software\Policies or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies. Values placed under this key will be secured (in some way), and the corresponding settings will show up as "Policies" in the Group Policy snap-in. If you place values in other places, they will not necessarily be secured, and they will show up as "Preferences" in the Group Policy snap-in.

WIN settings are all placed in HKLM\Software\Pismere and below. Therefore, they show up as "Preferences," and any security measures must be taken manually. Oh well.

Registry.pol Files
The Group Policy Object Editor stores registry-based configuration settings in two binary Registry.pol files. One file contains computer settings and the other file contains user settings. The Group Policy Object Editor saves the settings to these files on exit, and imports the settings on startup.

The Registry Policy File Format is available online at the MSDN web site.

As a binary format, it is cumbersome to edit directly. (Again, it could easily have been text. It could also easily have been in .reg format. Oh well.) Usually, you can use administrative template files to extend the group policy GUI to automate writing to this file. However, administrative template files do not allow for writing of REG_MULTI_SZ values. In such cases, you may want to directly edit Registry.pol.

IS&T developed a tool named regpoledit.exe which allows you to manually insert registry keys into a .pol file. There is a help file called regpoledit.html which contains information on how to use this tool. Regpoledit.exe and regpoledit.html are included on all win.mit.edu computers and can be accessed by running the file name from a command prompt.

IS&T shared this tool with Microsoft a few years ago and we are pleased to mention that they have bundled this functionality into their Windows Server 2008 product.

[Back to top]
MIT Home | Getting Started | Getting Services | Getting Help | About IS&T | Accessibility
Ask a technology question or send a comment about this web page.