Group Policy

You can use Group Policy to define policy settings that are applied to computers or users.

  • Before you use Group Policy, see Checklist: Implementing Group Policy
    • .
  • To find features that have been moved in the Microsoft® Windows® Server 2003 family, see New ways to do familiar tasks
    • .
  • For tips about using Group Policy, see Best practices
    • .
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting
    • .


Checklist: Implementing Group Policy

Step | References
Review key concepts about Group Policy. | Group Policy overview; Group Policy settings overview
Open Group Policy Object Editor. | Open Group Policy Object Editor; Ways to open Group Policy Object Editor
Create a new Group Policy object or edit an existing Group Policy object. | To create a new Group Policy object; To edit a Group Policy object
Configure Group Policy settings. | Software settings; Windows settings; Use administrative templates
(Optional) Link a Group Policy object to a site, domain, or organizational unit. | To link a Group Policy object to a site, domain, or organization unit
(Optional) Set Group Policy Software Installation options. | Group Policy Software Installation overview; To set Group Policy Software Installation defaults; Work with applications; Set application properties
(Optional) Configure Folder Redirection to redirect special folders. | Folder Redirection; Use Folder Redirection


New ways to do familiar tasks

Windows NT 4.0 introduced the System Policy Editor, which you could use to create a system policy to control user actions and the work environment and to enforce system configuration settings for all computers that run Windows NT 4.0. Policy settings define the various components of the desktop environment, including the applications that are available to users, the applications that appear on users' desktops, and the options that are displayed on the Start menu.

Group Policy and its extensions, included with XOX, XOX, and the Windows Server 2003 family, replace many of the tools that you are familiar with in Windows NT 4.0.

The following table lists common tasks for configuring policy. The user interface for performing these tasks is different in this version of Windows from the way it was in Windows NT version 4.0.

Note

  • XOX
If you want to | In Windows NT 4.0 use | In this version of Windows use
Set policies on users and computers in a site | Not applicable | Group Policy, accessed through Active Directory Sites and Services
Set policies on users and computers in a domain | System Policy Editor (Poledit.exe) | Group Policy, accessed through Active Directory Users and Computers
Set policies on users and computers in an organizational unit | Not applicable | Group Policy, accessed through Active Directory Users and Computers
Link a Group Policy object to a site, domain, or organizational unit | Not applicable | Group Policy, accessed through Active Directory Users and Computers
Use security groups to filter the scope of policy | Not applicable | Permissions on the Security tab in the Group Policy object's properties dialog box.
Manage software For an administrator, Systems Management Server. For a user, Add/Remove Programs in Control Panel. Systems Management Server and the three Group Policy Software Installation and Maintenance tools:
  • Group Policy Software Installation, an extension to the Group Policy Object Editor snap-in
  • Windows Installer
  • Add or Remove Programs in Control Panel
Create a safe user interface for editing the registry Windows NT 4.0 Administrative Templates for System Policy Editor Administrative Templates for Group Policy

For an explanation of how the role of .adm files has changed in the Windows Server 2003 family, see The role of Administrative Templates.
Perform general administrative tasks Administrative wizards, User Manager, and Server Manager Microsoft Management Console (MMC) snap-ins:
Active Directory Users and Computers,
Active Directory Sites and Services,
and Group Policy and its extensions.

The following table lists a common task for configuring Folder Redirection in Group Policy. The user interface for performing this task is different in this version of Windows from the way it was in Windows 2000. For more information about additional changes to Group Policy, see New features.

If you want to | In Windows 2000 use | In this version of Windows use
Redirect a special folder to a shared network directory with a Universal Naming Convention (UNC) path that is personalized to the user | A UNC path that incorporates UserName, for example, \\ServerName\ShareName\UserName\My Documents | The special folder's properties dialog box, as described in To redirect special folders to the root directory


Best practices

  • Best practices for Group Policy objects
  • Best practices for Group Policy Software Installation
  • Best practices for Folder Redirection


Best practices for Group Policy objects

Do not process policy settings that are not configured.

  • If a Group Policy object contains only settings that are set to Not Configured, you can avoid processing these settings by disabling User Configuration or Computer Configuration. This expedites the startup and logon processes for those users and computers that are subject to the Group Policy object. For more information, see To disable the User Configuration settings in a Group Policy object, To disable the Computer Configuration settings in a Group Policy object, User Configuration and Computer Configuration.
  • To prevent an entire Group Policy object from affecting a site, domain, or organizational unit, see To unlink a Group Policy object from a site, domain, or organizational unit and To disable a Group Policy object link. With these procedures, you can enable or re-link the Group Policy object.
  • If you never want to use a certain Group Policy object again, see To delete a Group Policy object.

Use Block Policy inheritance and No Override sparingly.

  • Routine use of these features makes it difficult to troubleshoot policy. If you must use them, see To block policy inheritance and To prevent a Group Policy object from being overridden.

Do not use the same name for different Group Policy objects.

  • By using the same name for two different Group Policy objects, you do not cause Group Policy to function incorrectly, but you might cause confusion. For more information, see Group Policy objects.

    • Caution

    • If you type a name for a Group Policy object that is longer than 255 characters, the name is truncated without warning to 255 characters.

Minimize the number of WMI Filters used with Group Policy objects.

  • The more WMI Filters that are applied to a Group Policy object, the longer it will take to process the object.

Filter policy based on security group membership.

  • Users who do not have an access control entry (ACE) directing that a particular Group Policy object be applied to them can avoid the associated logon delay, because the Group Policy object is not processed for those users.
  • Filtering can only be done by using membership in security groups. For more information, see To filter the scope of Group Policy according to security group membership.
  • To see the ACEs, click the Security tab in the Properties dialog box for a Group Policy object.

Override user-based Group Policy with computer-based Group Policy only when necessary.

  • Override user-based Group Policy with computer-based Group Policy only if you want the desktop configuration to be the same regardless of who logs on. The mechanism for doing this is called loopback, an advanced Group Policy setting that is useful in certain closely managed environments, such as laboratories, classrooms, public kiosks, and reception areas. The User Group Policy loopback processing mode policy setting is located in Group Policy Object Editor. For more information, see Order of processing settings.

Use Group Policy rather than System Policy.

  • Use System Policy only to manage computers that run an operating system that is earlier than Windows 2000 or if you need to manage desktops for multiple users on a stand-alone computer. For more information, see Migration issues.

Avoid assigning Group Policy objects across domains.

  • The processing of Group Policy objects slows the startup and logon processes if Group Policy is obtained from another domain.

Do not set File System policy on a drive or directory, such as Sysvol, that is replicated by the NTFS file replication system (FRS).

  • Settings that are under File System in Group Policy Object Editor can cause excessive replication and can waste network bandwidth. For more information, see File System security settings.

Do not link a Group Policy object to the same organizational unit more than once.

  • When more than one link for the same organizational unit is applied to a single object, the client-side Group Policy extension may interpret the links differently and produce unexpected resultant set of policy.

    For more information, see Link a Group Policy object to a site, domain, or organizational unit and Unlink a Group Policy object from a site, domain, or organizational unit.


Best practices for Group Policy Software Installation

Understand the difference between Group Policy Software Installation and Systems Management Server.

  • For simple software installation and deployment scenarios, Group Policy provides Group Policy Software Installation. For more information, see Group Policy Software Installation. For software installation scenarios where scheduling, inventory, reporting, status, and support for installation across a wide area network (WAN) is required, use Systems Management Server (SMS).

Specify application categories for your organization.

  • Using categories makes it easier for users to find an application in Add or Remove Programs in Control Panel. You can define application categories, such as Sales Applications, Accounting Applications, and so on. For more information, see To specify categories for applications to be managed.

Verify that Windows Installer packages are correctly transformed before they are published or assigned.

  • Transforms are applied to packages at the time of assignment or publication. Transforms (.mst files) are customizations that are applied to Windows Installer packages. A transform is applied at the time of assignment or publication, not at the time of installation. In practical terms, this means that you should verify that the Modifications tab in the package Properties dialog box is set up the way that you want it before you click OK. If you neglect to do this, and you assign or publish a transformed package before you have completely configured it, you can remove the software and republish or reassign it, or you can upgrade the software with a completely transformed version. For more information, see To remove a managed application, To upgrade applications, and Add or remove modifications for an application package.

Assign or publish just once per Group Policy object.

  • It is recommended that a Windows Installer package be used to assign an application or to publish an application no more than once in the same Group Policy object. For example, if you assign Microsoft Office to the computers that are affected by a Group Policy object, do not assign or publish it to the users who are affected by the Group Policy object. For more information, see To assign an application and To publish an application.

Take advantage of authoring tools.

  • Developers who are familiar with the files, registry entries, and other requirements that are necessary for an application to work properly can author native Windows Installer packages by using tools that are available from various software vendors.

Repackage existing software.

  • You can use commercially available tools to create Windows Installer packages for software that does not include natively authored .msi files. These tools work by comparing a computer's state before and after installation. For best results, install them on a computer that is free of other application software (clean installation).

Assign or publish applications at a high level in the Active Directory hierarchy.

  • Because Group Policy settings apply by default to child Active Directory containers, it is efficient to assign or publish applications by linking a Group Policy object to a parent organizational unit or domain. Use security descriptors (ACEs) on the Group Policy object for finer control over who receives the software. For more information, see To filter the scope of Group Policy according to security group membership.

Use required, rather than optional, upgrades.

  • For the correct upgrade procedures, both required and optional, see To upgrade an application.
  • The Upgrades tab for a package in Group Policy Software Installation has a Required upgrade for existing packages check box. It is recommended that you select this check box. If two users use the application on one computer, and one user upgrades the application and the other does not, both versions of the application exist on the computer. Some applications do not support this configuration.
  • Authenticated Users need the Read and Apply Group Policy ACE to be able to install applications from the software distribution point.
  • Administrators need Full Control to manage software.

Use Group Policy Software Installation properties for widely scoped control.

  • By using Group Policy Software Installation, you save administrative keystrokes when you assign or publish a large number of packages with similar properties in a single Group Policy object. For example, when all of the software is published and it all comes from the same software distribution point. For specific procedures, see Set options for Group Policy Software Installation.

Use Windows Installer package properties for fine control.

  • Use this method for assigning or publishing a single package. For specific procedures, see Work with applications.


Best practices for Folder Redirection

Accept the default settings.

  • In general, accept the default Folder Redirection settings.

Allow the system to create the folders.

  • If you create the folders yourself, they will not have the correct permissions.
  • If you must, or already have, created the folders, the information in the "Folder Redirection permissions" section in the Folder Redirection Help topic might not apply.

Do not redirect My Documents to the home directory unless you have already deployed home directories in your organization.

  • Redirection to the home directory offers less security than standard folder redirection, and it is offered only for backward compatibility. For more information, see Folder Redirection and To redirect My Documents to the home directory.

If you redirect My Documents to the home directory, and if your users log on to the domain through Terminal Server clients, do not specify a separate Terminal Services Home Directory.

  • The properties dialog box for a user in Active Directory has a Profile tab, where the Home Folder can be set, and also a Terminal Services Profile tab, where the Terminal Services Home Directory can be set. If these network folders are different, logging on to the terminal server causes the Profile Home Folder to be copied to the Terminal Services Home Directory. Logging off the terminal server causes copying to occur in the opposite direction. This is probably not the intended behavior, and it might result in delay in the logon and logoff processes for users. For more information, see To redirect My Documents to the home directory.

Enable client-side caching.

  • This is especially important for users with portable computers. For information about how to configure Folder Redirection and Offline Files to work together, see Folder Redirection.
  • Always enable the Synchronize all offline files before logging off Group Policy setting in the Group Policy Object Editor under \Computer Configuration (or User Configuration)\Administrative Templates\Network\Offline Files. By enabling this setting, you ensure that offline files are fully synchronized and that all of the files in the user's redirected folder are available when the user is working offline. If this setting is not enabled, the system performs only a cursory synchronization, and as a result only recently used files are cached.

    • Note

    • On client computers running XOX and Windows Server 2003 operating systems, redirected folders are automatically cached to client-side caching. In Windows 2000, you must enable this feature.

Use fully qualified universal naming convention (UNC) paths.

  • Although you can use paths like C:\FolderName, it is not recommended because the path might not exist on the target computer. Use fully qualified UNC paths.

    • Caution

    • UNC paths that are longer than 260 characters are truncated. If the path is truncated, redirection fails.

Always place the My Pictures folder in the My Documents folder.

  • My Pictures can be redirected independently of My Documents, or it can follow My Documents (to remain its subfolder whenever My Documents is redirected), as it does by default. The default behavior is recommended unless you have a specific reason (such as server scalability) for separating My Pictures from My Documents.

Consider the impact of policy removal.

  • Consider the behavior of your Folder Redirection policies at the time of policy removal, as described in the table of policy removal considerations in Folder Redirection. Changing the redirection option to Not configured does not redirect the folder to the user's local profile location. It will continue to be redirected to the previous location. If you want to return the folder to the local user profile location, use the Redirect to the local user profile policy setting, as described in To redirect special folders to the local profile location.


How to...

  • Open the Group Policy Object Editor
  • Work with Group Policy objects
  • Work with Group Policy object properties
  • Use Administrative Templates
  • Use startup, shutdown, logon, and logoff scripts
  • Use Group Policy Software Installation
  • Use Folder Redirection
  • Configure Group Policy
  • Delegate control of Group Policy


Open Group Policy Object Editor

  • Open Group Policy Object Editor from Active Directory Users and Computers
  • Open Group Policy Object Editor from Active Directory Sites and Services
  • Open Group Policy Object Editor as an MMC snap-in


Open Group Policy Object Editor from Active Directory Users and Computers

Microsoft Windows graphic

To open Group Policy Object Editor from Active Directory Users and Computers

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click the domain or organizational unit for which you want to set Group Policy.

    Where?

    • Active Directory Users and Computers
    • domain
    • organizational unit
    • child organizational unit
  3. Click Properties, and then click the Group Policy tab.
  4. Do one of the following:
    • To edit an existing Group Policy object, click the Group Policy object in the list, and then click Edit.
    • To create a new Group Policy object, click New, type a name for the new Group Policy object, and then click Edit.

Notes

  • XOX
  • You can open Group Policy Object Editor in several ways, depending on the action that you want to perform and the object to which you want to apply Group Policy. For information about the different ways you can open Group Policy Object Editor, see Related Topics.
Related Topics


Open Group Policy Object Editor from Active Directory Sites and Services

Microsoft Windows graphic

To open Group Policy Object Editor from Active Directory Sites and Services

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the site for which you want to set Group Policy.

    Where?

    • Active Directory Sites and Services
    • Sites
    • site name
  3. Click Properties, and then click the Group Policy tab.
  4. Do one of the following:
    • To edit an existing Group Policy object, click the Group Policy object in the list, and then click Edit.
    • To create a new Group Policy object, click New, type a name for the new Group Policy object, and then click Edit.

Notes

  • XOX
  • You can open Group Policy Object Editor in several ways, depending on the action that you want to perform and the object to which you want to apply Group Policy. For information about the different ways you can open Group Policy Object Editor, see Related Topics.
Related Topics


Open Group Policy Object Editor as an MMC snap-in

Microsoft Windows graphic

To open Group Policy Object Editor as an MMC snap-in

  1. Open Microsoft Management Console.
  2. On the File menu, click Add/Remove Snap-in.
  3. On the Standalone tab, click Add.
  4. In the Available Standalone Snap-ins list, click Group Policy Object Editor, and then click Add.
  5. In the Select Group Policy Object dialog box, click Local Computer to edit the local Group Policy object, or click Browse to find the Group Policy object that you want to edit.
  6. Click Finish, click Close, and then click OK. Group Policy Object Editor opens the Group Policy object for you to edit.

Notes

  • XOX
  • If you want to save a Group Policy Object Editor console and choose which Group Policy object opens in it from the command line, select the Allow focus of the Group Policy Snap-in to be changed when launching from the command line check box in the Select Group Policy Object dialog box.
  • You can open Group Policy Object Editor in several ways, depending on the action that you want to perform and the object to which you want to apply Group Policy. For information about the different ways you can open Group Policy Object Editor, see Related Topics.
Related Topics


Work with Group Policy objects

  • Edit a Group Policy object
  • Edit the local Group Policy object
  • Create a new Group Policy object
  • Delete a Group Policy object
  • Link a Group Policy object to a site, domain, or organizational unit
  • Block policy inheritance
  • Unlink a Group Policy object from a site, domain, or organizational unit
  • Disable a Group Policy object link
  • Prevent a Group Policy object from being overridden


Edit a Group Policy object

Microsoft Windows graphic

To edit a Group Policy object

  1. Open the Group Policy object that you want to edit.
  2. In the console tree, double-click the folders to view the policies in the details pane.
  3. In the details pane, double-click a policy to open the Properties dialog box, and then change the policy settings.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • You must have Read and Write permissions for a Group Policy object to open it.
  • Because changes to a Group Policy object take place immediately, you might want to disable the Group Policy object while you are editing it. For information about disabling a Group Policy object, see Related Topics.

Related Topics


Edit the local Group Policy object

Microsoft Windows graphic

To edit the local Group Policy object

  1. Open Group Policy Object Editor.
  2. In the console tree, double-click the folders to view the policies in the details pane.
  3. In the details pane, double-click a policy to open the Properties dialog box, and then change the policy settings.

Notes

  • XOX
  • To open the local Group Policy object, click Start, click Run, type gpedit.msc, and then click OK.
  • To open Group Policy Object Editor, see Related Topics.
  • Changes that you make to the local Group Policy object are saved automatically.

Related Topics


Create a new Group Policy object

Microsoft Windows graphic

To create a new Group Policy object

  1. Do one of the following:
    • To create a Group Policy object that is linked to a domain or to an organizational unit, open Active Directory Users and Computers.
    • To create a Group Policy object that is linked to a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit to which you want the newly created Group Policy object to be linked.

    The Group Policy object will be stored in the current domain, that is, the domain that contains the domain controller that is being used by Active Directory Users and Computers or Active Directory Sites and Services.

  3. Click Properties, and then click the Group Policy tab.
  4. Click New, type a name for the Group Policy object, and then click Close.

Notes

  • XOX
  • XOX
  • XOX
  • The newly created Group Policy object is linked by default to the site, domain, or organizational unit that you select when you create the Group Policy object,and its settings apply to that site, domain, or organizational unit. If you want to unlink the Group Policy object from that site, domain, or organizational unit, see Related Topics.

Related Topics


Delete a Group Policy object

Microsoft Windows graphic

To delete a Group Policy object

  1. Open Active Directory Users and Computers.

  2. In the console tree, right-click the domain, or right-click any organizational unit in the domain.
  3. Click Properties, and then click the Group Policy tab.
  4. To find all the Group Policy objects that are stored in the domain, click Add.
  5. In the Add a Group Policy Object Link dialog box, click the All tab, right-click the Group Policy object that you want to delete, and then click Delete.
  6. Click Yes, click Cancel, and then click OK.

Notes

  • XOX
  • XOX
  • When you delete a Group Policy object, any sites, domains, or organizational units to which it is linked are no longer affected by it. You might want to disable the Group Policy object instead. For more information, see Related Topics.

Related Topics


Link a Group Policy object to a site, domain, or organizational unit

Microsoft Windows graphic

To link a Group Policy object to a site, domain, or organizational unit

  1. Do one of the following:
    • To link to a domain or an organizational unit, open Active Directory Users and Computers.
    • To link to a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit to which you want the Group Policy object to be linked.
  3. Click Properties, and then click the Group Policy tab.
  4. To add the Group Policy object to the Group Policy Object Links list, click Add. This opens the Add a Group Policy Object Link dialog box.
  5. Click the All tab, click the Group Policy object that you want, and then click OK.
  6. In the properties dialog box for the site, domain, or organizational unit, click OK.

Notes

  • XOX
  • XOX
  • XOX
  • You can link a Group Policy object to specify that its settings are applied to users and computers in the site, domain, or organizational unit and that its settings are applied to users and computers in Active Directory containers that inherit policy settings from the site, domain, or organizational unit.
Related Topics


Block policy inheritance

Microsoft Windows graphic

To block policy inheritance

  1. Do one of the following:
    • To block policy inheritance in a domain or organizational unit, open Active Directory Users and Computers.
    • To block policy inheritance in a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit in which you want to block Group Policy inheritance, and then click Properties.
  3. Click the Group Policy tab, select the Block Policy inheritance check box, and then click OK. This option is recommended, and it is selected by default.

Notes

  • XOX
  • XOX
  • XOX
  • The Block Policy inheritance option blocks Group Policy objects that apply higher in the Active Directory hierarchy of sites, domains, and organizational units. It does not block Group Policy objects if they have No Override enabled.
  • The Block Policy inheritance option is set only on sites, domains, and organizational units, but not on individual Group Policy objects.

Related Topics


Unlink a Group Policy object from a site, domain, or organizational unit

Microsoft Windows graphic

To unlink a Group Policy object from a site, domain, or organizational unit

  1. Do one of the following:
    • To unlink a Group Policy object from a domain or organizational unit, open Active Directory Users and Computers.
    • To unlink a Group Policy object from a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit from which you want to unlink the Group Policy object.
  3. Click Properties, and then click the Group Policy tab.
  4. Click the Group Policy object that you want to unlink, and then click Delete.
  5. In the Delete dialog box, click Remove the link from the list, and then click OK.

Important

  • If you click Remove the link and delete the Group Policy object permanently in the Delete dialog box, all sites, domains, and organizational units to which the Group Policy object is linked will no longer have those Group Policy settings applied to them, and the Group Policy object will be deleted.

Notes

  • XOX
  • XOX
  • XOX
  • Unlinking prevents the Group Policy object from affecting that site, domain, or organizational unit.

Related Topics


Disable a Group Policy object link

Microsoft Windows graphic

To disable a Group Policy object link

  1. Do one of the following:
    • To disable a Group Policy object link to a domain or organizational unit, open Active Directory Users and Computers.
    • To disable a Group Policy object link to a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit to which the Group Policy object is linked, and then click Properties.
  3. Click the Group Policy tab.
  4. Right-click the Group Policy object link that you want to disable, click Disabled, and then click Yes. This switches the Disabled state to Active, and a check appears in the Disabled column.

Notes

  • XOX
  • XOX
  • XOX
  • When you disable a Group Policy object link, the settings in the Group Policy object no longer apply to users or computers in the site, domain, or organizational unit to which the Group Policy object was linked; and they no longer apply to users and computers in child Active Directory containers that inherit those Group Policy settings.

Related Topics


Prevent a Group Policy object from being overridden

Microsoft Windows graphic

To prevent a Group Policy object from being overridden

  1. Do one of the following:
    • For a Group Policy object that is linked to a domain or organizational unit, open Active Directory Users and Computers.
    • For a Group Policy object that is linked to a site, open Active Directory Sites and Services.
  2. In the console tree, right-click the site, domain, or organizational unit to which the Group Policy object is linked.
  3. Click Properties, and then click the Group Policy tab.
  4. In the Group Policy Object Links list, right-click the Group Policy object link that you want to enforce, click No Override, and then click OK. A check mark appears in the No Override column.

Notes

  • XOX
  • XOX
  • XOX
  • If you set No Override on a Group Policy object link, the Group Policy settings are enforced on all users or computers in the site, domain, or organizational unit and on all users and computers in Active Directory containers that inherit Group Policy from it.
  • Group Policy settings that are enforced by using No Override cannot be blocked.

Related Topics


Work with Group Policy object properties

  • Filter the scope of Group Policy according to security group membership
  • Find the sites, domains, and organizational units to which a Group Policy object is linked
  • Disable the User Configuration settings in a Group Policy object
  • Disable the Computer Configuration settings in a Group Policy object
  • Add a new WMI Filter to a Group Policy object
  • Delete a WMI Filter from a Group Policy object
  • Duplicate a WMI Filter in a Group Policy object
  • Import a WMI Filter to a Group Policy object
  • Export a WMI Filter from a Group Policy object
  • Sort the WMI Filters in a Group Policy object
  • View a WMI Filter linked to a Group Policy object


Filter the scope of Group Policy according to security group membership

Microsoft Windows graphic

To filter the scope of Group Policy according to security group membership

  1. Open the Group Policy object whose scope you want to filter.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. Click the Security tab, and then click the security group through which you want to filter this Group Policy object. If you want to change the list of security groups through which to filter this Group Policy object, use the Add and Remove buttons to add or remove security groups.
  4. In the Permissions box for the selected security group, select or clear the appropriate check boxes to set permissions as shown in the following table, and then click OK.
    5. Your intention | Permissions | Result
Members of this security group have this Group Policy object applied to them. | Set Apply Group Policy to Allow. Set Read to Allow. | This Group Policy object applies to members of this security group, unless they are members of at least one other security group that has Apply Group Policy set to Deny, or Read set to Deny, or both.
Members of this security group are exempt from this Group Policy object. | Set Apply Group Policy to Deny. Set Read to Deny. | This Group Policy object never applies to members of this security group, regardless of the permissions these members have in other security groups.
Membership in this security group is irrelevant to whether the Group Policy object should be applied. | Set Apply Group Policy to neither Allow nor Deny. Set Read to neither Allow nor Deny. | This Group Policy object applies to members of this security group if and only if they have both Apply Group Policy and Read set to Allow as members of at least one other security group. They also must not have Apply Group Policy or Read set to Deny as members of any other security group.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • Group Policy objects are applied only to sites, domains, and organizational units. Group Policy settings affect only the users and computers that they contain. In particular, Group Policy objects are not linked to security groups.
  • The location of a security group in Active Directory has no relation to, and no effect on, filtering through that security group as described in this procedure.
  • If a user or computer is not contained in a site, domain, or organizational unit that is subject to a Group Policy object, either directly through a link or indirectly through inheritance, there is no combination of permissions on any security group that can cause those Group Policy settings to affect that user or computer.
  • Filtering at the Group Policy object level, as described in this procedure, causes the Group Policy object to be processed or not processed as a whole. The Group Policy Software Installation and Folder Redirection extensions use security groups to refine control beyond the Group Policy object level. Except for Folder Redirection and Group Policy Software Installation, security groups are not used to filter individual settings, or subsets, of a Group Policy object. For control over individual settings, edit or create a Group Policy object instead.

Related Topics


Find the sites, domains, and organizational units to which a Group Policy object is linked

Microsoft Windows graphic

To find the sites, domains, and organizational units to which a Group Policy object is linked

  1. Open the Group Policy object.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. Click the Links tab, and then click Find Now. The sites, domains, and organizational units to which the Group Policy object is linked are listed in the Sites, Domains or Organizational Units found box.

Notes

  • To open Group Policy Object Editor, see Related Topics.
  • If the Group Policy object is linked to more than one domain, you can limit your search for organizational units to one domain at a time by using the Domain list.

Related Topics


Disable the User Configuration settings in a Group Policy object

Microsoft Windows graphic

To disable the User Configuration settings in a Group Policy object

  1. Open the Group Policy object that you want to edit.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. On the General tab, select the Disable User Configuration settings check box, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • When you disable the User Configuration settings in a Group Policy object, they no longer affect any site, domain, or organizational unit to which this Group Policy object is linked.

Related Topics


Disable the Computer Configuration settings in a Group Policy object

Microsoft Windows graphic

To disable the Computer Configuration settings in a Group Policy object

  1. Open the Group Policy object that you want to edit.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. On the General tab, select the Disable Computer Configuration settings check box, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • When you disable the Computer Configuration settings in a Group Policy object, they no longer affect any site, domain, or organizational unit to which this Group Policy object is linked.

Related Topics


Use Administrative Templates

  • Add or remove an Administrative Template (.adm file)
  • Use the view provided by Administrative Templates
  • Filter the view provided by Administrative Templates


Add or remove an Administrative Template (.adm file)

Microsoft Windows graphic

To add or remove an Administrative Template (.adm file)

  1. Open the Group Policy object that you want to edit.
  2. In the console tree, right-click Administrative Templates.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Administrative Templates
  3. Click Add/Remove Templates.
  4. Do one of the following:
    • To add a template, click Add. In the Policy Templates dialog box, click the template that you want to add, and then click Open.
    • To remove a template, in the Current Policy Templates list, click the template, and then click Remove.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • Because the role of Administrative Templates in the Windows Server 2003 family is different from Windows NT 4.0, the use of Windows NT 4.0 .adm files on client computers running XOX, XOX, and Windows Server 2003 operating systems is not recommended.

    If you do use the older .adm files to create namespaces in the Group Policy console, you can control whether the Windows NT 4.0 System Policy settings are visible in the details pane. To do this, in the console tree, click Administrative Templates. On the View menu, click Filtering, and then select or clear the Only show policy settings that can be fully managed check box. By selecting this check box, you cause System Policy settings to not be visible in the details pane. You can also use the Group Policy setting Enforce Show Policies Only to do this.

    Where?

    • Group Policy object
    • User Configuration
    • Administrative Templates
    • System
    • Group Policy

Related Topics


Use the view provided by Administrative Templates

Microsoft Windows graphic

To use the view provided by Administrative Templates

  1. Open Group Policy Object Editor.
  2. In the console tree, click the folder under Administrative Templates that contains the policy settings that you want to set.

    3. Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Administrative Templates
    • policy folder
  3. At the bottom of the details pane, click the Extended tab.
  4. In the Setting column, click the name or icon for a setting to read a description of the setting.
  5. To change that setting from its default (not configured) state, double-click the name or icon for the setting.
  6. On the Setting tab, click one of the buttons described in the following table.
    Button | Result
    Not Configured | The registry is not modified.
    Enabled | The registry reflects that the policy setting is selected.
    Disabled | The registry reflects that the policy setting is not selected.
  7. Select any other available options that you want on the Setting tab, and then click OK.
  8. To view and set other settings in the current folder, click Previous Setting or Next Setting.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • In Group Policy Object Editor, there are two Administrative Templates branches. Settings for HKEY_LOCAL_MACHINE are under Computer Configuration, and settings for HKEY_CURRENT_USER are under User Configuration.
  • If computer policy conflicts with user policy, computer policy generally takes precedence. Application authors can disregard that convention, however, and if they do, Group Policy cannot enforce it.
  • The Extended tab feature displays the text that explains the policy setting and indicates which versions of Windows are supported as clients for the setting. If you prefer a view of the policy setting without the explanatory text, click the Standard tab.

Related Topics


Filter the view provided by Administrative Templates

Microsoft Windows graphic

To filter the view provided by Administrative Templates

  1. Open Group Policy Object Editor.
  2. In the console tree, click Administrative Templates, or click a folder under Administrative Templates that contains the policy settings that you want to filter.

    3. Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Administrative Templates
    • policy folder
  3. On the View menu, click Filtering.
  4. Select the Filter by Requirements information check box.
  5. In the list box, select the check boxes for the categories that you want to make visible.
  6. To hide settings that are not configured, select the Only show configured policy settings check box. If you do this, only enabled or disabled settings will be visible.
  7. To hide Windows NT 4.0 system policy settings, select the Only show policy settings that can be fully managed check box. This option is recommended, and it is selected by default.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • This filtering procedure is useful if there are too many Administrative Templates settings at one time in Group Policy Object Editor. This filtering only selects which settings are visible in the console. It does not affect whether the settings apply to users or computers, and it is not the same as filtering the scope of Group Policy according to security group membership.

Related Topics


Use startup, shutdown, logon, and logoff scripts

  • Set up scripts on the domain controller
  • Assign computer startup scripts
  • Assign computer shutdown scripts
  • Assign user logon scripts
  • Assign user logoff scripts


Set up scripts on the domain controller

Microsoft Windows graphic

To set up scripts on the domain controller

  • Copy the script and dependent files to the Netlogon shared folder, or another shared folder, on the domain controller from which you want the script to run.

Note

  • You must be a domain administrator to configure scripts on a domain controller.

Related Topics


Assign computer startup scripts

Microsoft Windows graphic

To assign computer startup scripts

  1. Open Group Policy Object Editor.
  2. In the console tree, click Scripts (Startup/Shutdown).

    Where?

    • Group Policy object
    • Computer Configuration
    • Windows Settings
    • Scripts (Startup/Shutdown)
  3. In the details pane, double-click Startup.
  4. In the Startup Properties dialog box, click Add.
  5. In the Add a Script dialog box, do the following:
    • In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.
    • In Script Parameters, type any parameters that you want, the same way as you would type them on the command line. For example, if your script includes parameters called //logo (display banner) and //I (interactive mode), type //logo //I.
  6. In the Startup Properties dialog box, specify the options that you want as follows:
    • Startup Scripts for Group Policy object—Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, click it, and then click Up. To move a script down in the list, click it, and then click Down.
    • Add—Opens the Add a Script dialog box, where you can specify any additional scripts to use.
    • Edit—Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.
    • Remove—Removes the selected script from the Startup Scripts list.
    • Show Files—Displays the script files that are stored in the selected Group Policy object.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • Startup scripts are run as Local System, and they have the full rights that are associated with being able to run as Local System.

Related Topics


Assign computer shutdown scripts

Microsoft Windows graphic

To assign computer shutdown scripts

  1. Open Group Policy Object Editor.
  2. In the console tree, click Scripts (Startup/Shutdown).

    Where?

    • Group Policy object
    • Computer Configuration
    • Windows Settings
    • Scripts (Startup/Shutdown)
  3. In the details pane, double-click Shutdown.
  4. In the Shutdown Properties dialog box, click Add.
  5. In the Add a Script dialog box, do the following:
    • In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.
    • In Script Parameters, type any parameters that you want, the same way as you would type them on the command line. For example, if your script includes parameters called //logo (display banner) and //I (interactive mode), type //logo //I.
  6. In the Shutdown Properties dialog box, specify the options that you want as follows:
    • Shutdown Scripts for Group Policy object—Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, click it, and then click Up. To move a script down in the list, click it, and then click Down.
    • Add—Opens the Add a Script dialog box, where you can specify any additional scripts to use.
    • Edit—Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.
    • Remove—Removes the selected script from the Shutdown Scripts list.
    • Show Files—Displays the script files that are stored in the selected Group Policy object.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • Shutdown scripts are run as Local System, and they have the full rights that are associated with being able to run as Local System.

Related Topics


Assign user logon scripts

Microsoft Windows graphic

To assign user logon scripts

  1. Open Group Policy Object Editor.
  2. In the console tree, click Scripts (Logon/Logoff).

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Scripts (Logon/Logoff)
  3. In the details pane, double-click Logon.
  4. In the Logon Properties dialog box, click Add.
  5. In the Add a Script dialog box, do the following:
    • In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.
    • In Script Parameters, type any parameters that you want, the same way as you would type them on the command line. For example, if your script includes parameters called //logo (display banner) and //I (interactive mode), type //logo //I.
  6. In the Logon Properties dialog box, specify the options that you want as follows:
    • Logon Scripts for Group Policy object—Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, click it, and then click Up. To move a script down in the list, click it, and then click Down.
    • Add—Opens the Add a Script dialog box, where you can specify any additional scripts to use.
    • Edit—Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.
    • Remove—Removes the selected script from the Logon Scripts list.
    • Show Files—Displays the script files that are stored in the selected Group Policy object.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.

Related Topics


Assign user logoff scripts

Microsoft Windows graphic

To assign user logoff scripts

  1. Open Group Policy Object Editor.
  2. In the console tree, click Scripts (Logon/Logoff).

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Scripts (Logon/Logoff)
  3. In the details pane, double-click Logoff.
  4. In the Logoff Properties dialog box, click Add.
  5. In the Add a Script dialog box, do the following:
    • In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.
    • In Script Parameters, type any parameters that you want, the same way as you would type them on the command line. For example, if your script includes parameters called //logo (display banner) and //I (interactive mode), type //logo //I.
  6. In the Logoff Properties dialog box, specify the options the you want as follows:
    • Logoff Scripts for Group Policy object—Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, click it, and then click Up. To move a script down in the list, click it, and then click Down.
    • Add—Opens the Add a Script dialog box, where you can specify any additional scripts to use.
    • Edit—Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.
    • Remove—Removes the selected script from the Logoff Scripts list.
    • Show Files—Displays the script files that are stored in the selected Group Policy object.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • Logoff scripts are run as User, not Administrator, and their rights are limited accordingly.

Related Topics


Use Group Policy Software Installation

  • Open Group Policy Software Installation
  • Set options for Group Policy Software Installation
  • Work with applications
  • Set application properties
  • Add or remove modifications for an application package


Open Group Policy Software Installation

Microsoft Windows graphic

To open Group Policy Software Installation

  1. Open Group Policy Object Editor.
  2. To assign software applications to computers, in the console tree double-click Computer Configuration. To assign or publish software applications to users, in the console tree double-click User Configuration.
  3. Double-click Software Settings, and then click Software installation.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.

Related Topics


Set options for Group Policy Software Installation

  • Set Group Policy Software Installation defaults
  • Specify automatic installation options based on file name extension
  • Specify categories for applications to be managed


Set Group Policy Software Installation defaults

Microsoft Windows graphic

To set Group Policy Software Installation defaults

  1. Open Group Policy Software Installation.
  2. In the console tree, right-click Software installation.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. Click Properties, and on the General tab specify the following options:
    • In Default package location, specify the default software distribution point.
    • In New packages, specify how to add new packages to user settings. By default, packages can either be published or assigned. (To computers, they can only be assigned). If you want to select these options for each package, click Display the Deploy Software dialog box. For even more control on a per-package basis, click Advanced.
    • In Installation user interface options, click Basic or Maximum, depending on how apparent you want the installation process to be to the users.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.

Related Topics


Specify automatic installation options based on file name extension

Microsoft Windows graphic

To specify automatic installation options based on file name extension

  1. Open Group Policy Software Installation.
  2. In the console tree, right-click Software installation.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. Click Properties, and then click the File Extensions tab.
  4. On the File Extensions tab, specify the following options:
    • Select file extension—Displays a list of all available file name extensions for the managed software. When an extension is selected, all applications in Active Directory that are associated with the selected file name extension are displayed in the Application precedence list box. For example, for an .htm extension, many applications can be associated, such as Microsoft Word, Microsoft Internet Explorer, Netscape Communicator, and so on.
    • Application precedence—Lists all the applications that are associated with the selected file name extension. By default, the application with the highest precedence is at the top of the list.
    • Up—Moves the selected application higher in the precedence list. 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. The Up button is unavailable when the selected application is at the top of the list.
    • Down—Moves the selected application lower in the priority list. The Down button is unavailable when the selected application is at the bottom of the list.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • When you upgrade an application, turn off the autoinstall option for the older version.

Related Topics


Specify categories for applications to be managed

Microsoft Windows graphic

To specify categories for applications to be managed

  1. Open Group Policy Software Installation.
  2. In the console tree, right-click Software installation.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. Click Properties, and then click the Categories tab.
  4. To create or change the list of categories under which programs appear in Add or Remove Programs in Control Panel, do any of the following:
    • To create a new category, click Add, and then type the new category name. If you do not have permission to add categories, this button is unavailable.
    • To modify an existing category, click the category that you want to modify, click Modify, and then change the text of the selected category. If you do not have permission to edit categories, this button is unavailable.
    • To remove a category from the Categories list, click the category name, and then click Remove. If you do not have permission to edit categories, this button is unavailable.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • The changes that you make to the application categories apply throughout the domain in which this Group Policy object is stored.
  • To perform this procedure, you must be a domain administrator or have equivalent rights.

Related Topics


Work with applications

  • Assign an application
  • Publish an application
  • Upgrade an application
  • Remove a managed application


Assign an application

Microsoft Windows graphic

To assign an application

  1. Open Group Policy Software Installation.
  2. In the console tree, right-click Software installation, point to New, and then click Package.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. In the Open dialog box, click the Windows Installer package, and then click Open.
  4. In the Deploy Software dialog box, click Assigned, and then click OK.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • The Open dialog box shows the packages that are located at a software distribution point that you specify as the default. For instructions on how to set the default software distribution point, see Related Topics.
  • If the Windows Installer package is located on a different shared network directory, navigate to the correct software distribution point in the Open dialog box, click the package, and then click Open.

Related Topics


Publish an application

Microsoft Windows graphic

To publish an application

  1. Open Group Policy Software Installation.
  2. Right-click in the details pane, point to New, and then click Package.
  3. In the Open dialog box, click the Windows Installer package to be published, and then click Open.
  4. In the Deploy Software dialog box, click Published.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • Packages can be published only to users, not to computers.
  • The Open dialog box shows the packages that are located at a software distribution point that you specify as the default. For instructions on how to set the default software distribution point, see Related Topics.
  • If the Windows Installer package is located on a different shared network directory, navigate to the correct software distribution point in the Open dialog box, click the package, and then click Open.
  • The application is available for users to install either by using Add or Remove Programs in Control Panel or by opening a file with a file name extension that you have associated with the application. For information about how to associate a file name extension with an application, see Related Topics.

Related Topics


Upgrade an application

Microsoft Windows graphic

To upgrade an application

  1. Open Group Policy Software Installation.
  2. In the details pane, right-click the new Windows Installer upgrade package (that is, not the package to be upgraded).
  3. Click Properties, and then click the Upgrades tab.
  4. Click Add to create or add to the list of packages that you want to upgrade with the new upgrade package.
  5. In the Add Upgrade Package dialog box, under Choose a package from, do one of the following:
    • Click Current Group Policy object (GPO).
    • Click A specific GPO, click Browse, and then click the Group Policy object that you want to upgrade.
  6. Review the list of packages under Package to upgrade, which lists all of the other packages that are assigned or published within the selected Group Policy object.
  7. Click the package that you want to upgrade, and then do one of the following:
    • To replace an application with a completely different application (perhaps an application from a different vendor), click Uninstall the existing package, then install the upgrade package.
    • To install a newer version of the same product while retaining the user's application preferences, document type associations, and so on, click Package can upgrade over the existing package.
  8. (Optional) To make the upgrade mandatory, on the Upgrades tab, select the Required upgrade for existing packages check box.

Notes

  • XOX
  • Before you can perform this procedure, you must first assign or publish the upgrade package.
  • Depending on the Group Policy object, the list of packages under Package to upgrade might have zero or more entries.
  • If this is an upgrade under Computer Configuration in the Group Policy console tree, the Required upgrade for existing packages check box is selected and unavailable because packages can only be assigned to computers, not published.
  • To open Group Policy Software Installation, see Related Topics.

Related Topics


Remove a managed application

Microsoft Windows graphic

To remove a managed application

  1. Open Group Policy Software Installation.
  2. In the details pane, right-click the application that you want to remove, point to All Tasks, and then click Remove.
  3. In the Remove Software dialog box, click one of the following removal methods:
    • To specify that the application is removed the next time a user logs on or restarts the computer, click Immediately uninstall the software from users and computers.
    • To specify that users can continue to use the application if they have already installed it, click Allow users to continue to use the software, but prevent new installations. If users have removed the application or if they have never installed it, they will not be able to install it.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.

Related Topics


Set application properties

  • View properties for managed applications
  • Edit installation options for applications
  • Specify application categories for Add or Remove Programs in Control Panel
  • Set the autoinstall option for an application
  • Set permissions for Group Policy Software Installation


View properties for managed applications

Microsoft Windows graphic

To view properties for managed applications

  1. Open Group Policy Software Installation.
  2. In the details pane, right-click the application for which you want to view properties, and then click Properties.

Note

  • To open Group Policy Software Installation, see Related Topics.

Related Topics


Edit installation options for applications

Microsoft Windows graphic

To edit installation options for applications

  1. XOX
  2. Open Group Policy Software Installation.
  3. In the details pane, right-click the application for which you want to set installation options, and then click Properties.
  4. In the properties dialog box for the application, click the Deployment tab.
  5. On the Deployment tab, click one of the following options under Deployment type:
    • Published—Users in the selected site, domain, or organizational unit can install the application by using either Add or Remove Programs in Control Panel or file activation.
    • Assigned—Users in the selected site, domain, or organizational unit receive this application the next time that they log on (for assignment to users) or when the computer restarts (for assignment to computers).
  6. Under Deployment options, select the check boxes for the following options that you want:
    • Auto-install this application by file extension activation—Select this option if you want to use the application precedence for the file name extension as it is determined on the File Extensions tab in the Software installation Properties dialog box. If the application is not already installed, selecting this option causes the application to be installed when the user opens a file with this file association, for example, by double-clicking the file.
    • Uninstall this application when it falls out of the scope of management—Select this option if you want the application to be removed when users log on, or when computers start up, if they move to a site, domain, or organizational unit for which the application is not deployed.
    • Do not display this package in Add or Remove Programs in Control Panel—This option removes the most obvious method for users to uninstall the application. This may be useful from time to time during the software life cycle.
    • Install this application at logon—This option fully installs the application using the package defaults. It does not merely advertise the application to the user by means of a shortcut. Note that the package defaults themselves might call for installation of all features or of only some features.
  7. Under Installation user interface options, click one of the following options:
    • Basic—Only progress bars and errors are displayed.
    • Maximum—The entire user interface that is supported by the package is displayed.
  8. If you want to set the following advanced options, click Advanced:
    • Ignore language when deploying this package—Select this check box if you are installing an application whose language differs from the language of the operating system.
    • Remove existing installs of this product for users, if the product was not installed by Group Policy–based Software Installation—This option might be useful, for example, if company policy does not allow users to install applications from their own compact discs.
    • Make this 32-bit X86 application available to IA64 machines—Specifies whether the 32-bit application should be assigned or published to 64-bit computers.
    • Include OLE class and product information—Specifies whether to deploy information about COM components with the package so that software on the client can install them from Active Directory as needed, in a manner similar to activation by file extension.

Notes

  • To open Group Policy Software Installation, see Related Topics.
  • The Advanced Deployment Options dialog box, which appears when you click Advanced, provides advanced diagnostic information, which can be useful for troubleshooting. The following table lists and describes this information.
    Field | Data
    Product code | A globally unique identifier (GUID) representing the product
    Deployment Count | The number of times the package has been deployed in this Group Policy object
    Script name | The full network path, including GUIDs, to the application assignment script (.aas file)

Related Topics


Specify categories for Add or Remove Programs in Control Panel

Microsoft Windows graphic

To specify application categories for Add or Remove Programs in Control Panel

  1. Open Group Policy Software Installation.
  2. In the details pane, double-click the managed application for which you want to set categories.
  3. In the properties dialog box for the application, click the Categories tab.
  4. On the Categories tab, do any of the following:
    • To associate an application category that has been defined for your organization with this application, click a category in the Available categories list, and then click Select.
    • To remove a category that is associated with this application, click a category in the Selected categories list, and then click Remove.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • The categories that you set in this dialog box generally pertain to published applications only, because assigned applications do not appear in Add or Remove Programs in Control Panel. The application appears in the selected categories in Add or Remove Programs, which the user can use to install the application.
  • This procedure is not used to create or remove categories, but only to associate applications with existing categories. To manage the categories themselves, see Related Topics.

Related Topics


Set the autoinstall option for an application

Microsoft Windows graphic

To set the autoinstall option for an application

  1. Open Group Policy Software Installation.
  2. In the console tree, click Software installation.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. In the details pane, right-click the application that you want to be installed automatically when the user tries to open a file with the associated extension.
  4. Click Properties, and then click the Deployment tab.
  5. Under Deployment options, select the Auto-install this application by file extension activation check box, and then click OK. This option is recommended, and it is selected by default.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • When you upgrade an application, turn off the autoinstall option for the older version.

Related Topics


Set permissions for Group Policy Software Installation

Microsoft Windows graphic

To set permissions for Group Policy Software Installation

  1. Open the Group Policy object that you want to edit.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. Click the Security tab, and in the Group or user names box, click the security group for which you want to set permissions.
  4. Do any of the following:
    • To change the set of security groups that have permissions on this Group Policy object, click Add or Remove to add or remove security groups.
    • If the security group represents administrators (who manage software for users and computers in the organization), in the Permissions box for the selected security group, select the Allow check box for Full Control, and then click OK.
    • If the security group represents users (who use software that is assigned or published by an administrator), in the Permissions box for the selected security group, select the Allow check box for both Apply Group Policy and Read, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • The permissions that you set in this procedure pertain only to the Group Policy object. In addition, the network must have a shared folder (a software distribution point) containing the packages to be installed. Administrators must have Full Control of the software distribution point, and users must have Read permission. For information about permissions and how to set them, see Related Topics.

Related Topics


Add or remove modifications for an application package

Microsoft Windows graphic

To add or remove modifications for an application package

  1. Open Group Policy Software Installation.
  2. In the console tree, right-click Software installation, point to New, and then click Package.

    Where?

    • Group Policy object
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software installation
  3. In the Open dialog box, click the Windows Installer package, and then click Open.
  4. In the Deploy Software dialog box, click Advanced, and then click OK.
  5. In the properties dialog box for the package, click the Modifications tab.
  6. Do any of the following:
    • To add modifications, click Add. In the Open dialog box, browse to the transform file (.mst), and then click Open.
    • To remove modifications, on the Modifications tab, click the modification that you want to remove, and then click Remove. Repeat this step until you have removed each modification that you do not want.
  7. When you are sure that the modifications are configured the way you want them, click OK.

    8. 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.

Notes

  • XOX
  • To open Group Policy Software Installation, see Related Topics.
  • The Open dialog box shows the packages that are located at a software distribution point that you specify as the default. For instructions on how to set the default software distribution point, see Related Topics.
  • If the Windows Installer package is located on a different shared network directory, navigate to the correct software distribution point in the Open dialog box, click the package, and then click Open.
  • Modifications (.mst files) are applied to Windows Installer packages (which have the .msi extension) in an order that you specify. This order must be determined before the application is assigned or published.
  • You can add multiple modifications, which are also called transforms. The transforms are applied in the order that you specify in the Modifications list, from top to bottom. To rearrange the list, click a transform in the list, and then click Move Up or Move Down.

Related Topics


Use Folder Redirection

  • Redirect special folders to the same location for all users
  • Redirect special folders to different locations based on security group membership


Redirect special folders to the same location for all users

  • Redirect My Documents to the home directory
  • Redirect special folders to the root directory
  • Redirect special folders to a specific path
  • Redirect special folders to the local profile location


Redirect My Documents to the home directory

Microsoft Windows graphic

To redirect My Documents to the home directory

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose My Documents folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display My Documents.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
    • My Documents
  3. Right-click My Documents, and then click Properties.
  4. On the Target tab, in Setting, click Basic - Redirect everyone's folder to the same location.
  5. Under Target folder location, click Redirect to the user's home directory, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • This option is intended only for organizations that have already deployed home directories and that want to maintain compatibility with their existing home directory environment.
  • If you redirect My Documents to the home directory, domain administrators have full control over the user's My Documents folder. This is the case even if you select the Grant the user exclusive rights to My Documents check box on the Settings tab in the My Documents Properties dialog box.
  • Redirection to the home directory requires a client computer running XOX, XOX, or a Windows Server 2003 operating system. It does not work for Windows NT clients, Windows 2000 clients, or XOX clients.
  • In redirection of the home directory, security is not checked, and permissions are not changed. Folder Redirection assumes that the administrator has set directory security correctly. This relaxed security is why redirection to the home directory is only recommended if it is needed for backward compatibility.
  • In home directory redirection, no ownership checks are made. Normally, folder redirection fails if a user is not the owner of the folder to which he or she is being redirected. Because redirection to the home directory is intended for use in a legacy environment, this ownership check is skipped.
  • Users must have the home directory property set correctly on their user object in Active Directory. The client computer finds the path for the user's home directory from the user object in Active Directory at logon time. Users who are affected by Folder Redirection policy must have this path set correctly, or folder redirection will fail.

Related Topics


Redirect special folders to the root directory

Microsoft Windows graphic

To redirect special folders to the root directory

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Basic - Redirect everyone's folder to the same location.
  5. Under Target folder location, click Create a folder for each user under the root path.
  6. In Root Path, type a Universal Naming Convention (UNC) path (for example, \\servername\sharename), and then click OK.
  7. In the properties dialog box for the special folder, click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • The user name and folder name are appended to the UNC path automatically.

Related Topics


Redirect special folders to a specific path

Microsoft Windows graphic

To redirect special folders to a specific path

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Basic - Redirect everyone's folder to the same location.
  5. Under Target folder location, click Redirect to the following location.
  6. In Root Path, type a UNC path (for example, \\ServerName\ShareName), or type a locally valid path (for example, C:\FolderName).

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • In most cases, you want to redirect special folders to the root directory rather than to a specific location, as described in this procedure. For more information, see Related Topics.

Related Topics


Redirect special folders to the local profile location

Microsoft Windows graphic

To redirect special folders to the local profile location

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Basic - Redirect everyone's folder to the same location.
  5. Under Target folder location, click Redirect to the local user profile location, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • This procedure is useful for returning redirected folders to their original, default location.
  • If you change the setting to No administrative policy specified on the Target tab of the properties dialog box for a special folder, you do not cause the special folder to be redirected back to its default location.

Related Topics


Redirect special folders to different locations based on security group membership

  • Redirect My Documents to the home directory based on security group membership
  • Redirect special folders to the root directory based on security group membership
  • Redirect special folders to a specific path based on security group membership
  • Redirect special folders to the local profile location based on security group membership


Redirect My Documents to the home directory based on security group membership

Microsoft Windows graphic

To redirect My Documents to the home directory based on security group membership

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose My Documents folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display My Documents.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
    • My Documents
  3. Right-click My Documents, and then click Properties.
  4. On the Target tab, in Setting, click Advanced - Specify locations for various user groups.
  5. Click Add.
  6. In the Specify Group and Location dialog box, under Security Group Membership, type the name of the security group, or click Browse to search for it.
  7. Under Target Folder Location, click Redirect to the user's home directory, and then click OK.
  8. In the My Documents Properties dialog box, click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • This option is intended only for organizations that have already deployed home directories and that want to maintain compatibility with their existing home directory environment.
  • If you redirect My Documents to the home directory, domain administrators have full control over the user's My Documents folder. This is the case even if you select the Grant the user exclusive rights to My Documents check box on the Settings tab in the My Documents Properties dialog box.
  • Redirection to the home directory requires a client computer running XOX, XOX, or a Windows Server 2003 operating system. It does not work for Windows 2000 clients, Windows NT clients, or XOX clients.
  • In home directory redirection, security is not checked, and permissions are not changed. Folder Redirection assumes that the administrator has set directory security correctly. This relaxed security is why redirection to the home directory is only recommended if it is needed for backward compatibility.
  • In home directory redirection, no ownership checks are made. Normally, folder redirection fails if a user is not the owner of the folder to which he or she is being redirected. Because redirection to the home directory is intended for use in a legacy environment, this ownership check is skipped.
  • Users must have the home directory property set correctly on their user object in Active Directory. The client computer finds out the path for the user's home directory from the user object in Active Directory at logon time. Users who are affected by Folder Redirection policy must have this path set correctly, or folder redirection will fail.

Related Topics


Redirect special folders to the root directory based on security group membership

Microsoft Windows graphic

To redirect special folders to the root directory based on security group membership

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Advanced - Specify locations for various user groups.
  5. Click Add.
  6. In the Specify Group and Location dialog box, under Security Group Membership, type the name of the security group, or click Browse to search for it.
  7. Under Target Folder Location, click Create a folder for each user under the root path.
  8. In Root Path, type the UNC path to use for redirection (for example, \\servername\sharename), and then click OK.
  9. In the properties dialog box for the special folder, click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • The user name and folder name are appended to the UNC path automatically.

Related Topics


Redirect special folders to a specific path based on security group membership

Microsoft Windows graphic

To redirect special folders to a specific path based on security group membership

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Advanced - Specify locations for various user groups.
  5. Click Add.
  6. In the Specify Group and Location dialog box, under Security Group Membership, type the name of the security group, or click Browse to search for it.
  7. Under Target Folder Location, click Redirect to the following location.
  8. In Root Path, type the UNC path to use for redirection (for example, \\servername\sharename), and then click OK.
  9. In the properties dialog box for the special folder, click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • In most cases, you want to redirect special folders to the root directory rather than to a specific location, as described here. For more information, see Related Topics.

Related Topics


Redirect special folders to the local profile location based on security group membership

Microsoft Windows graphic

To redirect special folders to the local profile location based on security group membership

  1. Open a Group Policy object that is linked to the site, domain, or organizational unit that contains the users whose special folders you want to redirect.
  2. In the console tree, double-click Folder Redirection to display the special folder that you want to redirect.

    Where?

    • Group Policy object
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder that you want to redirect (for example, Desktop or My Documents), and then click Properties.
  4. On the Target tab, in Setting, click Advanced - Specify locations for various user groups.
  5. Click Add.
  6. In the Specify Group and Location dialog box, under Security Group Membership, type the name of the security group, or click Browse to search for it.
  7. Under Target Folder Location, click Redirect to the local user profile location, and then click OK.
  8. In the properties dialog box for the special folder, click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • This procedure is useful for returning redirected folders to their original, default location.
  • If you change the setting to No administrative policy specified on the Target tab of the properties dialog box for a special folder, you do not cause the special folder to be redirected back to its default location.

Related Topics


Configure Group Policy

  • Extend the functionality of Group Policy
  • Refresh Group Policy immediately
  • Set permissions on a Group Policy object
  • Set the Group Policy refresh rate for computers
  • Set other policies for Group Policy


Extend the functionality of Group Policy

Microsoft Windows graphic

To extend the functionality of Group Policy

  1. Open Group Policy Object Editor as an MMC snap-in.
  2. On the File menu, click Add/Remove Snap-in.
  3. Click the Extensions tab, click the snap-ins that you want to extend, click the extensions that you want to add, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.

Related Topics


Refresh Group Policy immediately

Microsoft Windows graphic

To refresh Group Policy immediately

  1. Click Start, and then click Run.
  2. In the Open box, type gpupdate, and then click OK.

Note

  • To learn more about gpupdate, gpresult, and other command-line tools, see Related Topics.

Related Topics


Set permissions on a Group Policy object

Microsoft Windows graphic

To set permissions on a Group Policy object

  1. Open Group Policy Object Editor.
  2. In the console tree, right-click the icon or the name of the Group Policy object for which you want to set permissions, and then click Properties.
  3. Click the Security tab, and then specify the following options:
    • Add—Opens the Select Users, Computers, or Groups dialog box, where you can specify the users and groups for whom you want to assign permissions.
    • Remove—In the Group or user names box, removes selected users or groups and their associated permissions from this object.
    • Permissions for Authenticated Users—Lists the standard permissions that you can allow or deny to users, for example, Full Control, Read, Write, and so on.
    • Advanced—Use this option to set special permissions, auditing information, and owner information for the selected object.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • You can only set permissions on a nonlocal Group Policy object.

Related Topics


Set Group Policy refresh rate for computers

Microsoft Windows graphic

To set the Group Policy refresh rate for computers

  1. Open Group Policy Object Editor.
  2. In the console tree, click Group Policy.

    3. Where?

    • Group Policy object
    • Computer Configuration
    • Administrative Templates
    • System
    • Group Policy
  3. In the details pane, double-click Group Policy refresh interval for computers.
  4. On the Setting tab, click Enabled.
  5. In the Minutes boxes, type or click the number of minutes for the refresh interval and random offset, and then click OK.
  6. In the details pane, double-click Turn off background refresh of Group Policy.
  7. On the Setting tab, click Disabled, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • By default, the System.adm file is installed in Computer Configuration\Administrative Templates so that you can view these options. For information about how to add or remove an Administrative Templates file like System.adm, see Related Topics.
  • Client computers request policy from a domain controller when any of the following events occur:
    • A computer starts up.
    • A user logs on.
    • An application requests a refresh through the RefreshPolicy() application programming interface (API).
    • The user requests an immediate refresh.
    • One of the Group Policy refresh interval policies is enabled, and the interval has transpired.
    • Policy is not imposed by the domain controller; it is requested by the client computer.
  • The minimum setting for the Group Policy refresh interval (zero minutes) actually takes about seven seconds between requests for a refresh. Very short refresh interval settings should not be used in a production environment, except briefly for testing.
  • Group Policy Software Installation and Folder Redirection are not affected by policy refreshes.

Related Topics


Set other policies for Group Policy

Microsoft Windows graphic

To set other policies for Group Policy

  1. Open Group Policy Object Editor.
  2. Do one of the following:
    • To edit a computer policy, in the console tree click Group Policy.

      • Where?

      • Group Policy object
      • Computer Configuration
      • Administrative Templates
      • System
      • Group Policy
    • To edit a user policy, in the console tree click Group Policy.

      • Where?

      • Group Policy object
      • User Configuration
      • Administrative Templates
      • System
      • Group Policy
  3. In the details pane, double-click the icon or the name of the policy that you want to set.
  4. On the Setting tab, select the options that you want, and then click OK.

Notes

  • XOX
  • To open Group Policy Object Editor, see Related Topics.
  • By default, the most common Administrative Templates are displayed. You can add Administrative Templates by right-clicking the Administrative Templates folder, and then clicking Add/Remove Templates. For more information, see To add or remove an Administrative Template (.adm file).

Related Topics


Delegate control of Group Policy

  • Delegate Group Policy object editing
  • Delegate creation of Group Policy objects
  • Delegate Group Policy object linking


Delegate Group Policy object editing

Microsoft Windows graphic

To delegate Group Policy object editing

  1. Open Group Policy Object Editor.
  2. In the console tree, right-click the icon or name of the Group Policy object, and then click Properties.
  3. Do any of the following:
    • To add a user or group of users, click the Security tab, and then click Add. Type the name of the user or group of users, and then click OK.
    • To give a user or group Group Policy object editing permissions, in Permissions for Authenticated Users, select the check boxes that correspond to the permissions you want to give. When you are finished, click OK.
    • If you do not want to apply the policy to a user or group of users, under Permissions for Authenticated Users, clear the Allow check box for Apply Group Policy. When you are finished, click OK.

Notes

  • To complete this procedure, you must be logged on as a member of the Domain Admins group or the Enterprise Admins group.
  • To open Group Policy Object Editor, see Related Topics.

Related Topics


Delegate creation of Group Policy objects

Microsoft Windows graphic

To delegate creation of Group Policy objects

  1. Open Active Directory Users and Computers.
  2. In the console tree, click Users.
  3. In the Name column in the details pane, double-click Group Policy Creator Owners.
  4. In the Group Policy Creator Owners Properties dialog box, click the Members tab.
  5. Click Add, and then double click the name of each user or security group to whom you want to delegate creation rights.

Notes

  • To complete this procedure, you must be logged on as a member of the Domain Admins group or the Enterprise Admins group.
  • XOX
  • By default, only domain administrators, enterprise administrators, Group Policy Creator Owners, and the operating system can create new Group Policy objects. If the domain administrator wants a nonadministrator or a group to be able to create Group Policy objects, that user or group can be added to the Group Policy Creator Owners security group. When a user who is not an administrator, but who is a member of the Group Policy Creator Owners group, creates a Group Policy object, that user becomes the creator and owner of the Group Policy object; therefore, that user can edit the Group Policy object. Being a member of the Group Policy Creator Owners group gives the user full control of only those Group Policy objects that the user creates or those Group Policy objects that are explicitly delegated to that user. It does not give the nonadministrator user any additional rights over other Group Policy objects for the domain—these users are not granted rights over Group Policy objects that they did not create.
  • When an administrator creates a Group Policy object, the Domain Admins group becomes the Creator Owner of the Group Policy object.
  • When you delegate this task to nonadministrators, also consider delegating the ability to manage the links for a specific organizational unit. The reason for this is that, by default, nonadministrators cannot manage links, and the inability to manage links prevents them from being able to use Active Directory Users and Computers to create a Group Policy object.

Related Topics


Delegate Group Policy object linking

Microsoft Windows graphic

To delegate Group Policy object linking

  1. Open Active Directory Users and Computers.
  2. Right-click the organizational unit to which you want to delegate the right to link Group Policy objects, and then click Delegate Control.
  3. In the Delegation of Control Wizard, click Next, and then click Add.
  4. In the Select Users, Computers, or Groups dialog box, enter the object name to select, and then click OK, and then click Next.
  5. On the Task to Delegate page, in Delegate the following common tasks, select the Manage Group Policy links check box, and then click Next.
  6. Click Finish.

Notes

  • To complete this procedure, you must be logged on as a member of the Domain Admins group or the Enterprise Admins group.
  • XOX
  • To open Group Policy Object Editor, see Related Topics.

Related Topics


Concepts

This section provides general background information about Group Policy, and about the change and configuration management technologies that use Group Policy.

  • Group Policy overview
  • Group Policy settings overview
  • Understanding Group Policy
  • Using Group Policy
  • Resources


Group Policy overview

To begin using Group Policy immediately, see Ways to open Group Policy Object Editor.

Group Policy settings define the various components of the user's desktop environment that a system administrator needs to manage, for example, the programs that are available to users, the programs that appear on the user's desktop, and options for the Start menu. To create a specific desktop configuration for a particular group of users, use Group Policy Object Editor. Group Policy settings that you specify are contained in a Group Policy object, which is in turn associated with selected Active Directory® objects—sites, domains, or organizational units.

Group Policy applies not only to users and client computers, but also to member servers, domain controllers, and any other Microsoft® Windows® 2000 computers within the scope of management. By default, Group Policy that is applied to a domain (that is, applied at the domain level, just above the root of Active Directory Users and Computers) affects all computers and users in the domain. Active Directory Users and Computers also provides a built-in Domain Controllers organizational unit. If you keep your domain controller accounts there, you can use the Group Policy object Default Domain Controllers Policy to manage domain controllers separately from other computers.

Group Policy includes policy settings for User Configuration, which affect users, and for Computer Configuration, which affect computers. For more information, see User Configuration and Computer Configuration.

With Group Policy you can do the following:

  • Manage registry-based policy with Administrative Templates. Group Policy creates a file that contains registry settings that are written to the User or Local Machine portion of the registry database. User profile settings that are specific to a user who logs on to a given workstation or server are written to the registry under HKEY_CURRENT_USER (HKCU), and computer-specific settings are written under HKEY_LOCAL_MACHINE (HKLM). For procedural information, see Use Administrative Templates. For technical details, see "Implementing Registry-based Policy" at the Microsoft Web site. (http://msdn.microsoft.com/)
  • Assign scripts. This includes such scripts as computer startup, shutdown, logon, and logoff. For more information, see Use startup, shutdown, logon, and logoff scripts.
  • Redirect folders. You can redirect folders, such as My Documents and My Pictures, from the Documents and Settings folder on the local computer to network locations. For more information about Folder Redirection, see Use Folder Redirection.
  • Manage applications. With Group Policy you can assign, publish, update, or repair applications by using Group Policy Software Installation. For more information, see Use Group Policy Software Installation.
  • Specify security options. To learn about setting security options, see Security Settings.

Group Policy objects that exist by default

Each computer that runs Windows 2000, XOX, or Windows Server 2003 operating systems has exactly one Group Policy object stored locally. This local Group Policy object contains a subset of the settings that are available in nonlocal Group Policy objects. For more information, see Local Group Policy.

By default, when Active Directory is set up, two nonlocal Group Policy objects are created:

  • Default Domain Policy is linked to the domain, and it affects all users and computers in the domain (including computers that are domain controllers) through policy inheritance. For more information, see Policy inheritance.
  • Default Domain Controllers Policy is linked to the Domain Controllers organizational unit, and it generally only affects domain controllers, because computer accounts for domain controllers are kept exclusively in the Domain Controllers organizational unit.

Caution

  • If you move a domain controller outside of the Domain Controllers organizational unit, the default Domain Controllers policy is no longer applied. If you need to keep a domain controller in a different organizational unit, link the default Domain Controllers policy to that organization unit.

How and when Group Policy is applied

To view a detailed chronology for the application of policy, see Order of events when starting up and logging on.

User and computer policy

User policy settings are located under User Configuration in Group Policy, and they are obtained when a user logs on. Computer policy settings are located under Computer Configuration, and they are obtained when a computer starts. For more information, see User Configuration and Computer Configuration.

Users and Computers are the only types of Active Directory objects that receive policy. Specifically, policy does not apply to security groups. Instead, for performance reasons, security groups are used to filter the policy by means of an Apply Group Policy access control entry (ACE), which can be set to Allow or Deny or left unconfigured. For more information, see To filter the scope of Group Policy according to security group membership.

Order of application

Policies are applied in this order:

  1. The unique local Group Policy object.
  2. Site Group Policy objects
    3. , in administratively specified order.
  3. Domain Group Policy objects
    4. , in administratively specified order.
  4. Organizational unit Group Policy objects, from largest to smallest organizational unit (parent to child organizational unit) and in administratively specified order at the level of each organizational unit.

For more information, see Order of processing settings.

By default, policies that are applied later overwrite previously applied policies when the policies are inconsistent. If the policies are not inconsistent, however, earlier and later policies both contribute to the effective policy. For more information, see Group Policy precedence.

Filtering policy by security group membership

A security group ACE on a Group Policy object can be set to Not configured (no preference), Allowed, or Denied. Denied takes precedence over Allowed. For more information, see To filter the scope of Group Policy according to security group membership.

Blocking policy inheritance

Policies that would otherwise be inherited from higher sites, domains, or organizational units can be blocked at the site, domain, or organizational unit level. For more information, see To block policy inheritance.

Enforcing policy from above

You can set policies that would otherwise be overwritten by policies in child organizational units to No Override at the Group Policy object level. For more information, see To prevent a Group Policy object from being overridden.

Notes

  • Policies set to No Override cannot be blocked.
  • The No Override and Block options should be used sparingly. Casual use of these advanced features complicates troubleshooting. For tips about using Group Policy, see Troubleshooting and Best practices.


Group Policy settings overview

With Group Policy settings, you can define the configuration of a user's desktop environment. Settings are available for Computer Configuration and User Configuration. In addition to client computers and users, you can apply these settings to member servers and domain controllers within the scope of an Active Directory forest.

Administrative Templates folder

The Administrative Templates folders are available under Computer Configuration and User Configuration in Group Policy Object Editor. These folders contain registry settings. For more information, see Administrative Templates.

The following table contains links to Help for all of the registry settings included in the five default Administrative Templates.

For these settings | Open this Administrative Template | Reference
System settings that control features such as desktop, network connections, shared folders, and Control Panel. | System (System.adm) | Group Policy settings for Windows 2000, XOX, and the Windows Server 2003 family
Internet Explorer settings that control features such as security zones, proxy settings, search, and temporary Internet files. | Internet Explorer (Inetres.adm) | Group Policy settings for Internet Explorer
Windows Media Player settings that control features such as proxy settings, codec, and network buffering. XOX | Windows Media Player (Wmplayer.adm) | Group Policy settings for Windows Media Player
NetMeeting settings to control features such as application sharing, audio, video, and chat. XOX | NetMeeting (Conf.adm) | Group Policy settings for NetMeeting v3.01
Windows Update settings that control features such as automatic software updates through the Internet. | Windows Update (Wuau.adm) | Group Policy settings for Windows Update

Software Settings folder

The Software Settings folders are available under Computer Configuration and the User Configuration in Group Policy Object Editor. The Computer Configuration\Software Settings folder contains software settings that apply to all users who log on to the computer. This folder contains software installation settings, and it might contain other settings that are placed there by independent software vendors. The User Configuration\Software Settings folder contains software settings that apply to users regardless of which computer they log on to. This folder also contains software installation settings, and it might contain other settings that are placed there by independent software vendors. For more information, see Software Settings.

Windows Settings folder

The Windows Settings folders are available under Computer Configuration and User Configuration in Group Policy Object Editor. The Computer Configuration\Windows Settings folder contains Windows settings that apply to all users who log on to the computer. This folder also contains the following items: Security Settings and Scripts. The User Configuration\Windows Settings folder contains Windows settings that apply to users regardless of which computer they log on to. This folder also contains the following items: Folder Redirection, Security Settings, and Scripts. For more information, see Windows Settings.

Security Settings folder

The Security Settings folders are available under Computer Configuration and User Configuration in Group Policy Object Editor. Security settings or security policies are rules that you configure on a computer or multiple computers that protect resources on a computer or network. With security settings you can specify the security policy of an organizational unit, domain, or site. To view a complete list and detailed information about security settings, see Security setting descriptions. To specify security settings on a local computer, see Local Security Policy. For more information, see Security Settings.


Understanding Group Policy

This section covers:

  • New features
  • Group Policy objects
  • Policy inheritance
  • Storage of Group Policy objects
  • User Configuration
  • Computer Configuration
  • Administrative Templates
  • Software Settings
  • Windows Settings
  • Folder Redirection
  • Windows Management Instrumentation (WMI) Filters
  • Startup, shutdown, logon, and logoff scripts
  • Group Policy Software Installation
  • Group Policy precedence


New features

The Windows 2000 change and configuration management technologies have been improved in the Windows Server 2003 family. For information about specific user interface changes in the Windows Server 2003 family, see New ways to do familiar tasks.

Following is a list of the new features included with Group Policy in the Windows Server 2003 family:

  • Administrative Templates

    • There are over 220 new administrative policies than were previously available on Windows 2000. There is a new supported keyword in .adm files that tells you which versions of Windows are supported as clients for the setting. For more information, see "Implementing Registry-based Policy" at the Microsoft Web site. (http://msdn.microsoft.com/) There is also a new Administrative Templates Web view that uses the supported keyword to show you which operating systems are supported clients for individual settings. For information about how to use the Web view, see To use the view provided by Administrative Templates. For more information about Administrative Templates, see Administrative Templates.

    Administrative Templates online Help is now included with Windows. The following table contains links to the .adm Help files.

    .adm file | Policy settings
System.adm | Open Help for System Settings
Wmplayer.adm | Open Help for Windows Media Player settings
Inetres.adm | Open Help for Internet Explorer settings
Conf.adm | Open Help for NetMeeting settings
  • Command-line tools

    • The new gpudate command replaces the Windows 2000 command secedit /refreshpolicy. For more information, see Gpupdate.

    The Windows 2000 Resource Kit command gpresult has been enhanced, and it is now included with XOX, XOX, and the Windows Server 2003 family. For more information, see Gpresult.

  • Folder Redirection

    • It is now easier to use Folder Redirection. It is no longer necessary to type variables such as UserName as part of the redirection path. There is a new option for redirecting My Documents to a user's home directory. This is for use in environments where home directories are already deployed. For more information, see Use Folder Redirection.

  • Group Policy Software Installation

    • Group Policy Software Installation now has an advanced deployment option to enable or disable availability of 32-bit programs to 64-bit computers. With another new advanced option, you can enable or disable (default) publication of OLE class information about a software package. As an administrator, you also have an option that forces assigned applications to be installed at deployment time. For more information, see Edit installation options for applications.

  • Resultant Set of Policy

    • Resultant Set of Policy (RSoP) is a new tool that you can use to plan for and troubleshoot policy. For more information, see Resultant Set of Policy.

  • Support across forests

    • Group Policy features are now supported in multiple forest environments allowing authenticated access to resources in separate, networked environments. You can manage and enforce policy objects for user and computer objects in remote trusted forests and analyze policies using Resultant Set of Policy. For more information, see Group Policy features that are supported across forests and Accessing resources across forests.


Group Policy objects

Policy settings are stored in Group Policy objects. Group Policy Object Editor can be thought of as an application whose document type is the Group Policy object, just as a word processor might use .doc or .txt files.

There are two kinds of Group Policy objects: local and nonlocal. Local Group Policy objects are stored on individual computers. Only one local Group Policy object exists on a computer, and it has a subset of the settings that are available in a nonlocal Group Policy object. Local Group Policy object settings can be overwritten by nonlocal settings if they are in conflict; otherwise, both groups of settings apply. For more information, see Local Group Policy.

Nonlocal Group Policy objects, which are stored on a domain controller, are available only in an Active Directory environment. They apply to users and computers in the site, domain, or organizational unit with which the Group Policy object is associated. For more information, see Storage of Group Policy objects.


Policy inheritance

In general, Group Policy is passed down from parent to child containers within a domain, which you can view by using Active Directory Users and Computers. Group Policy is not inherited from parent to child domains, for example, from wingtiptoys.com to sales.wingtiptoys.com. Active Directory Domains and Trusts, which you can use to manage relationships of this type, is not related to Group Policy.

If you assign a specific Group Policy setting to a high-level parent container, that Group Policy setting applies to all containers beneath the parent container, including the user and computer objects in each container. However, if you explicitly specify a Group Policy setting for a child container, the child container's Group Policy setting overrides the parent container's setting.

If a parent organizational unit has policy settings that are not configured, the child organizational unit does not inherit them. Policy settings that are disabled are inherited as disabled. In addition, if a policy setting is configured (enabled or disabled) for a parent organizational unit and the same policy setting is not configured for a child organizational unit, the child inherits the parent's enabled or disabled policy setting.

If a policy setting that is applied to a parent organizational unit and a policy setting that is applied to a child organizational unit are compatible, the child organizational unit inherits the parent policy setting, and the child's setting is also applied.

If a policy setting that is configured for a parent organizational unit is incompatible with the same policy setting that is configured for a child organizational unit (because the setting is enabled in one case and disabled in the other), the child does not inherit the policy setting from the parent. The policy setting in the child is applied.

Blocking inheritance

You can block policy inheritance at the domain or organizational-unit level by opening the properties dialog box for the domain or organizational unit and selecting the Block Policy inheritance check box. For more information, see To block policy inheritance.

Enforcing inheritance

You can enforce policy inheritance by setting the No Override option on a Group Policy object link.

When you select the No Override check box, you force all child policy containers to inherit the parent's policy, even if that policy conflicts with the child's policy and even if Block Inheritance has been set for the child.

You can set No Override on a Group Policy object link by opening the properties dialog box for the site, domain, or organizational unit and making sure that the No Override check box is selected. For more information, see To prevent a Group Policy object from being overridden.

Notes

  • Policies that are set to No Override cannot be blocked.
  • It is recommended that No Override and Block be used sparingly. Casual use of these advanced features makes troubleshooting more complicated. For more information, see Troubleshooting and Best practices.


Storage of Group Policy objects

Each computer that runs XOX, XOX, or the Windows Server 2003 operating systems, has exactly one local Group Policy object (GPO). It is stored in systemroot\System32\GroupPolicy.

Group Policy objects, other than the local Group Policy object, are virtual objects. The policy setting information of a GPO is actually stored in two locations: the Group Policy container and the Group Policy template. The Group Policy container is an Active Directory container that stores GPO properties, including information on version, GPO status, and a list of components that have settings in the GPO. The Group Policy template is a folder structure within the file system that stores Administrative Template-based policies, security settings, script files, and information regarding applications that are available for Group Policy Software Installation. The Group Policy template is located in the system volume folder (Sysvol) in the \Policies subfolder for its domain. For more information about the local Group Policy object, see Local Group Policy.

Group Policy container

The Group Policy container is a directory service object. It includes subcontainers for computer and user Group Policy information. The Group Policy container contains the following data:

  • Version information—Used to verify that the information is synchronized with Group Policy template information.
  • Status information—Indicates whether the Group Policy object is enabled or disabled for this site, domain, or organizational unit.
  • List of components—Specifies which extensions to Group Policy have settings in the Group Policy object.

The Group Policy container stores information for Group Policy Software Installation and for Folder Redirection, which are extensions of the Group Policy Object Editor. For more information, see Group Policy Software Installation overview and Folder Redirection.

Group Policy template

The Group Policy template is a folder of domain controllers for the storage domain of the Group Policy object. A typical Group Policy template folder might look like the following example:

systemroot\Sysvol\SYSVOL\Streetmarket.com\Policies\
{34975054-fd77-df75-54fe-074936850457}

Subfolders of the Group Policy template

The Group Policy template folder contains subfolders, including, but not limited to, the following:

  • Adm—Contains all the .adm files for this Group Policy template.
  • Scripts—Contains all the scripts and related files for this Group Policy template.
  • User—Includes a Registry.pol file that contains the registry settings that are to be applied to users. When a user logs on to a computer, this Registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the registry. The User folder contains an Applications subfolder.
  • User\Applications—Contains the application advertisement script files (.aas) that are used by the operating system–based installation service. These files are applied to users.
  • Machine—Includes a Registry.pol file that contains the registry settings that are to be applied to computers. When a computer initializes, this Registry.pol file is downloaded and applied to the HKEY_LOCAL_MACHINE portion of the registry. The Machine folder contains an Applications subfolder.
  • Machine\Applications—Contains the .aas files that are used by the operating system–based installation service. These files are applied to computers.


User Configuration

You can use User Configuration in Group Policy to set policies that apply to users, regardless of which computer they log on to.

User Configuration typically contains subitems for Software Settings, Windows Settings, and Administrative Templates, but because you can add or remove extensions from Group Policy Object Editor, the exact set of subitems that you see might be different. For more information about these subitems, see Software Settings, Windows Settings, and Administrative Templates.


Computer Configuration

With Computer Configuration in Group Policy, you can set policies that are applied to computers, regardless of who logs on to the computers.

Computer Configuration typically contains Software Settings, Windows Settings, and Administrative Templates. However, because you can add or remove extensions in Group Policy Object Editor, what you see might be slightly different.

For more information about these subitems, see Software Settings, Windows Settings, and Administrative Templates.


Administrative Templates

Administrative Templates provide policy information for the items that appear under the Administrative Templates folder in the console tree of the Group Policy Object Editor.

Administrative Template .adm files

An .adm file consists of a hierarchy of categories and subcategories that together define how the policy settings appear. It also contains the following information:

  • Registry locations that correspond to each setting.
  • Options or restrictions in values that are associated with each setting.
  • For many settings, a default value.
  • Explanations of what each setting does.
  • The versions of Windows that support each setting.

The Administrative Templates for Group Policy contain all registry-based policy information. User configurations are saved in HKEY_CURRENT_USER (HKCU), and computer configurations are saved in HKEY_LOCAL_MACHINE (HKLM). HKCU and HKLM place registry information that is specific to Group Policy under \Software\Policies or under \Software\Microsoft\Windows\CurrentVersion\Policies. Therefore, there are five areas of the registry that contain Group Policy registry settings.

Administrative Templates offer these new features:

  • A description of each policy setting in Administrative Templates appears in searchable online Help. The following table contains links to these Help topics.
    Administrative Template | Description | Help for Administrative Templates policy settings
    System.adm | System settings | System settings
    Inetres.adm | Internet Explorer settings | Internet Explorer settings
    Wmplayer.adm | Windows Media Player settings. XOX | Windows Media Player settings
    Conf.adm | NetMeeting settings. XOX | NetMeeting settings
    Wuau.adm | Windows Update settings. | Windows Update settings
  • A supported keyword in the .adm files that tells you which versions of Windows are supported as clients for the setting. For information about the supported keyword, see "Implementing Registry-based Policy" at the Microsoft Web site. (http://msdn.microsoft.com/)
  • A Web view that shows the explain text of each setting and the new supported information. For information about how to use the Web view, see To use the view provided by Administrative Templates.
  • The ability to filter settings from the view to reduce screen clutter when you are using Administrative Templates. For information about how to use this new feature, see To filter the view provided by Administrative Templates.

If you plan to create entries for Administrative Templates, populate the namespace by using the following naming convention, which is also used in the registry: \CompanyName\product\version (or \CompanyName\product&version). For example, the operating system settings for Windows are in \Microsoft\Windows.

For information about adding an .adm file, see To add or remove an Administrative Template (.adm file). For more information about Administrative Templates, see Administrative Templates included with this version of Windows and The role of Administrative Templates.

Registry.pol files

The Administrative Templates extension of Group Policy saves information in Registry.pol files. These files contain the customized registry settings that you specify (by using Group Policy) that are to be applied to the computer or user portion of the registry:

  • One of the Registry.pol files contains registry settings that are specific to the HKEY_LOCAL_MACHINE key; it is stored in the GPT\Machine folder.
  • The other Registry.pol file contains registry settings that are specific to the HKEY_CURRENT_USER key; it is stored in the GPT\User subdirectory.


Software Settings

Software Settings are available under both User Configuration and Computer Configuration in the console tree of Group Policy Object Editor.

Computer Configuration\Software Settings is for software settings that apply to all users who log on to the computer. This folder contains the Software installation subitem, and it might contain other subitems that are placed there by independent software vendors.

User Configuration\Software Settings is for software settings that apply to users regardless of which computer they log on to. This folder also contains the Software installation subitem, and it might contain other subitems that are placed there by independent software vendors.

For more information about the Computer Configuration and User Configuration folders, see User Configuration and Computer Configuration. For more information about the Software installation subitem, see Group Policy Software Installation overview.


Windows Settings

Windows Settings are available under both User Configuration and Computer Configuration in the console tree of Group Policy Object Editor.

Computer Configuration\Windows Settings is for windows settings that apply to all users who log on to the computer. It includes two subitems: Security Settings and Scripts.

User Configuration\Windows Settings is for windows settings that apply to users regardless of which computer they log on to. It includes three subitems: Folder Redirection, Security Settings, and Scripts.

For more information about the Computer Configuration and User Configuration folders, see User Configuration and Computer Configuration. For more information about the settings in the Windows Settings subitems, see Security Settings, Scripts, and Folder Redirection.


Folder Redirection

In Group Policy Object Editor, you can use Folder Redirection to redirect certain special folders to network locations. Special folders are those folders, such as My Documents and My Pictures, that are located under Documents and Settings. Folder Redirection is located under User Configuration in the console tree of Group Policy Object Editor.

There are several basic options for Folder Redirection. For each basic option, there is an advanced version of that option. The advanced version provides for finer control by allowing redirection that is based on security group membership. For more information about specific procedures, see Use Folder Redirection. The following table describes the different folder redirection options that are available to you.

Special folder | Notes
Application Data | A Group Policy setting controls the behavior of Application Data when client-side caching is enabled. Look in User Configuration\Administrative Templates\Network\Offline Files in the console tree of Group Policy Object Editor.
Desktop | Desktop can be redirected independently of all the other special folders.
My Documents | For more information, see Advantages of redirecting My Documents.
My Documents\ My Pictures | My Pictures can be redirected independently of My Documents, or it can be made to follow My Documents (to remain its subfolder whenever My Documents is redirected), as it does by default. The default behavior is recommended unless you have a specific reason (such as server scalability) for separating My Pictures from My Documents. If these folders are separated, a shortcut takes the place of the My Pictures folder in My Documents.
Start Menu | When Start Menu is redirected, its subfolders always follow.

Caution

  • When creating a shared folder redirection directory, limit access to only those users that need access. Redirected folders can contain personal information such as confidential documents and EFS certificates, care should be taken to protect access to the shared folder. Restrict access to the shared folder to only those users that need access. You can also create a security group for users that require permissions for a particular shared folder, and limit access to only those users.
  • When creating the shared folder, hide it by putting a $ after the share name. This hides the shared folder from casual browsers, and it will not be visible in My Network Places.

Advantages of redirecting My Documents

Some of the following benefits pertain to redirecting any folder, but redirecting My Documents can be particularly advantageous because this folder tends to become large over time.

  • When roaming user profiles are used, only the network path to the My Documents folder is part of the roaming user profile, not the My Documents folder. Therefore, its contents do not have to be copied back and forth between the client computer and the server each time the user logs on or off, and the process of logging on or off can be much faster than it was in Windows NT 4.0.
  • Even if a user logs on to various computers on the network, his or her documents are always available.
  • Offline File technology gives users access to My Documents even when they are not connected to the network. This is particularly useful for people who use portable computers. For more information, see To make a file or folder available offline.
  • Data that is stored in a shared network folder can be backed up as part of routine system administration. This is safer because it requires no action on the part of the user.
  • As an administrator, you can use Group Policy to set disk quotas, limiting the amount of space that is taken up by users' special folders.
  • Data that is specific to a user can be redirected to a different hard disk on the user's local computer from the hard disk that holds the operating system files. This makes the user's data safer if the operating system is reinstalled.

For tips about using Folder Redirection, see Best practices for Folder Redirection.

Granting exclusive rights to special folders

The Settings tab in each folder's properties dialog box contains a check box labeled Grant the user exclusive rights to My Documents. If you select this check box, the user and the local system have full control over the folder, and no one else, not even the administrator, has any rights to it. If you clear this check box, no changes are made to the permissions on the folder. Whatever permissions are in effect by default remain in effect.

Policy removal considerations with regard to Folder Redirection

The following table summarizes what happens to redirected folders and their contents when the Group Policy object no longer applies.

Move the contents of the special folder to the new location setting Policy Removal option Results when policy is removed
Enabled Redirect the folder back to the user profile location when policy is removed
  • The special folder returns to its user profile location.
  • The contents are copied, not moved, back to the user profile location.
  • The contents are not deleted from the redirected location.
  • The user continues to have access to the contents, but only on the local computer.
Disabled Redirect the folder back to the user profile location when policy is removed
  • The special folder returns to its user profile location.
  • The contents are not copied or moved to the user profile location.

Caution

  • If the contents of a folder are not copied to the user profile location, the user cannot see them.
Either Enabled or Disabled Leave the folder in the new location when policy is removed
  • The special folder remains at its redirected location.
  • The contents remain at the redirected location.
  • The user continues to have access to the contents at the redirected folder.

Folder Redirection and Offline Files

The Offline Files technology applies to any mounted or mapped drive that contains documents or data that a user might want to use offline. Offline Files does not depend on Folder Redirection. It is set up and configured on shared network servers separately from the Folder Redirection snap-in. Offline Files enables the user to do useful work even when the user is not connected to the network, for example, on a portable computer or in the event of router failure. For more information, see Offline Files.

If you use redirected folders of any type, it is recommended that you set up Offline Files as described in the following table.

Special Folder | Offline File configuration
My Documents | Autocaching for documents (or manual caching for documents, if you want users to have to manually make files and folders available for offline use)
My Pictures | Autocaching for documents (or manual caching for documents, if you want users to have to manually make files and folders available for offline use)
Application Data | Autocaching for programs
Desktop | Autocaching for programs if the desktop is Read Only
Start Menu | Autocaching for programs

Folder Redirection permissions

This is an advanced topic. If you let Folder Redirection create folders for you, which is the recommended procedure, correct permissions are set automatically. Usually, knowledge of these permissions is not necessary. However, there are two reasons the permissions might be of interest:

  • Sometimes, even though it is not recommended, administrators create the redirected folders before Folder Redirection creates them. The following table shows what permissions have to be set for Folder Redirection to work.
  • Redirection of My Documents to the home directory provides more relaxed security than standard folder redirection. The following table shows what security is in effect in the standard case.

    • NTFS permissions required for the root folder

    User account | Folder Redirection defaults | Minimum permissions needed
Creator/owner | Full Control, this folder, subfolders, and files | Full Control, this folder, subfolders, and files
Administrators | No permissions | No permissions
Everyone | No permissions | No permissions
Local System | Full Control, this folder, subfolders, and files | Full Control, this folder, subfolders, and files
Security group of users who need to put data on the shared network server | N/A | List Folder/Read Data, Create Folders/Append Data - This folder only

    Share-level (SMB) permissions required for the root folder

    User Account | Folder Redirection defaults | Minimum permissions needed
Everyone | Full Control | No permissions (Use security group)
Security group of users who need to put data on the shared network server | N/A | Full Control

    NTFS permissions required for each user's redirected folder

    User account | Folder Redirection defaults | Minimum permissions needed
UserName | Full Control, owner of folder | Full Control, owner of folder
Local System | Full Control | Full Control
Administrators | No permissions | No permissions
Everyone | No permissions | No permissions


Windows Management Instrumentation (WMI) Filters

Group Policy provides policy setting information to the WMI Common Information Model (CIM)-compliant object repository (CIMON database). With WMI Filters, you can specify a WMI-based query to filter the effect of a Group Policy object in the CIMON database. WMI Filters can be written and customized using the WMI Query Language (WQL).

For more information, see Windows Management Instrumentation Filters and WMI overview.


Startup, shutdown, logon, and logoff scripts

Group Policy Object Editor includes two extensions for script deployment:

  • Scripts (Startup/Shutdown)—You can use this extension, which is located under Computer Configuration\Windows Settings in the console tree of Group Policy Object Editor, to specify scripts that are to run when the computer starts up or shuts down. These scripts run as Local System.
  • Scripts (Logon/Logoff)—You can use this extension, which is located under User Configuration\Windows Settings in the console tree of Group Policy Object Editor, to specify scripts that are to run when the user logs on or logs off the computer. These scripts run as User, not as Administrator.

For more information, see Use startup, shutdown, logon, and logoff scripts.

The Windows Server 2003 family includes Windows Script Host, a language-independent scripting host for 32-bit Windows platforms that includes both Visual Basic Scripting Edition (.vbs) and JScript (.js) scripting engines. You can use Windows Script Host to run .vbs and .js scripts directly on the Windows desktop or in the command console, without the need to embed these scripts in an HTML document.

For more information about Windows Script Host, see Windows Script Host overview. To learn about Windows Script Host and the Object Model and to obtain script samples, see the "Windows Script" at the Microsoft Web site. (http://msdn.microsoft.com/)


Group Policy Software Installation

This section covers:

  • Group Policy Software Installation overview
  • Managing Group Policy Software Installation
  • Add or Remove Programs in Control Panel
  • File types that you use with Group Policy Software Installation


Group Policy Software Installation overview

With Group Policy Software Installation, a software management feature, you can manage software throughout its life cycle within the organization. Group Policy Software Installation works in conjunction with Group Policy and Active Directory. It is one of three Group Policy Software Installation and Maintenance components, which are described in the following table.

Component | Role
Group Policy Software Installation (an extension of Group Policy Object Editor) | Used by administrators to manage software
Windows Installer | Installs software that is packaged in Windows Installer files
Add or Remove Programs in Control Panel | Used by users to manage software on their own computers. For more information, see Add or Remove Programs in Control Panel.

Group Policy Software Installation helps you specify how applications are installed and maintained within your organization. With Group Policy Software Installation, you can manage an application within a Group Policy object, which is in turn associated with a particular Active Directory container—either a site, a domain, or an organizational unit. Applications can be managed in one of two modes: assigned or published.

For tips about using Group Policy Software Installation, see Best practices for Group Policy Software Installation. To begin using Group Policy Software Installation right away, see To open Group Policy Software Installation. For more information, see Group Policy Software Installation.

Assigning to users

When you assign an application to a user, the application is advertised to the user the next time the user logs on to a workstation. The application advertisement follows the user, regardless of which physical computer he or she actually uses. The application is installed the first time that the user activates the application on the computer, either by selecting the application on the Start menu or by activating a document that is associated with the application. For more information, see To assign an application.

You assign an application when you want everyone to have the application on his or her computer. For example, suppose that you want all users in a marketing department to have Microsoft Excel on their computers. A Group Policy object manages every user in marketing. When you assign Excel within the marketing Group Policy object, Excel is advertised on every marketing user's computer. When an assigned application is advertised, it is not actually installed on the computer. In this case, the application advertisement installs only enough information about Excel to make the Excel shortcuts appear on the Start menu and to make the necessary file associations (.xls) appear in the registry.

When these users log on to their computers, Excel appears on their Start menu. When they select Excel on the Start menu for the first time, Excel installs. A user can also install an advertised application by opening a document that is associated with the application, either by file name extension or by COM-based activation. If a user who has not yet activated Excel from the Start menu clicks an Excel spreadsheet to open it, Excel installs and the spreadsheet opens.

A user can delete an assigned application, but the assigned application is advertised again the next time the user logs on. It installs the next time a user selects it on the Start menu.

Assigning to computers

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. For more information, see To assign an application.

Publishing to users

When you publish an application to users, the application does not appear as installed on the users' computers. No shortcuts are visible on the desktop or on the Start menu, and no changes are made to the local registry on the users' computers. Instead, published applications store their advertisement attributes in Active Directory. Information, such as the application's name and file associations, is exposed to the users in the Active Directory container. The application is then available for the user to install by using Add or Remove Programs in Control Panel or by clicking a file that is associated with the application, such as an .xls file for Microsoft Excel. For more information, see To publish an application and Add or Remove Programs in Control Panel.

You publish an application when you want the application to be available to people who are managed by the Group Policy object, in case a user wants the application. With published applications, it is up to each person to decide whether or not to install the published application.

For example, if you publish Microsoft Image Composer to users who are managed by the marketing Group Policy object, and a marketing user wants to install Image Composer, the user can go to Add or Remove Programs in Control Panel and install the application. If users do not install Image Composer by using Add or Remove Programs, and if the .jpg file name extension for the image document is associated with Image Composer, Image Composer can be installed for users when they first open any .jpg document.

Application assignment scripts

Application assignment scripts are one of the file types that are often encountered in Group Policy Software Installation. For every published or assigned application in a particular Group Policy object, an application assignment script (.aas file) is generated and stored in that domain's Group Policy object. These script files contain the advertisement information about the application configuration. For more information, see File types that you use with Group Policy Software Installation.

The user's view of software installation

At the user's computer, system components—including Winlogon, the shell, object linking and embedding (OLE), the Lightweight Directory Access Protocol (LDAP) client, and the local registry—provide the user's view of software installation. Winlogon is the privileged agent that applies software installation policy. The shell and the OLE are enhanced to be Active Directory–aware and to communicate with Windows Installer to perform setup actions. The LDAP client provides the capability to search and query Active Directory.

By using Add or Remove Programs, users can browse for and install software from Active Directory in a managed environment or from local media (in a nonmanaged environment or, if policy permits, from local media in a managed environment).


Managing Group Policy Software Installation

Administrators generally complete the following phases to manage software for their organization: preparation, management, and removal. For tips about using Group Policy Software Installation, see Best practices for Group Policy Software Installation. For more general information, see Group Policy Software Installation overview.

Preparation

Before you can use Group Policy Software Installation, you should have a Windows Installer package (.msi) for the program that you want to install. The package is often supplied with the software. If a program does not have a Windows Installer package, you must generate one. Other utilities are available for repackaging a program that you plan to install. You can then use transforms to further customize a package. Transforms, which have the .mst extension, are sometimes called modifications. For more information, see Add or remove modifications for an application package and File types that you use with Group Policy Software Installation.

The next step is to create a shared network directory, called a software distribution point, that contains the packages (.msi files), any transforms (.mst files), and the program files and components. Administration is simpler if packages and program files are kept together, although this is not absolutely necessary. (Packages and transforms do have to be kept together.) As an administrator, you might also benefit from using distributed file systems to help manage these software distribution points.

Finally, verify that users can read from the software distribution point and write to the target of the installation, particularly if the program is written to a network file server.

Note

  • You can still deploy applications that do not have an .msi file by using a .zap setup file. For more information, see File types that you use with Group Policy Software Installation.

Management

You can use Group Policy Software Installation to manage programs within your organization. You can assign programs to either computers or users, or you can publish programs to users.

Program assignment and publishing to users have the following software life cycle phases:

  • Evaluation phase—For evaluation purposes, you might want to have only a few users try out and evaluate the new program. During this phase, the old version of the program is the default version, and the majority of users are still using it. A new user installs the assigned or published version. This is often called a pilot. The pilot is a good time to experiment with Group Policy Software Installation options, such as assigning an application and publishing an application, which is less forceful. You can also try setting the autoinstall option for an application, so that the software is installed when the user attempts to open a file with an extension that you have associated with the application. You can also try the Basic or Maximum options for the installation user interface, which you can set by using the procedure To set Group Policy Software Installation defaults. These options control the level of visibility of the installation process to the user.

    • For more information, see To assign an application, To publish an application, and To set the autoinstall option for an application.

  • Rollout phase—During rollout, you begin making the new program available to more users. The new version of the program is now the default, and the majority of the users are using the new version. A new user only has the option to install the new program. You can leave certain users unaffected if upgrading them at this time would affect their work.

Removal

As an administrator, you must select one of the following options, which are mutually exclusive, when you remove a program:

  • Immediately uninstall—This option requires that no one currently uses the program. Those users who still have the program on their computers receive an advertisement that removes the program.
  • Just prevent new installations—This option allows users to continue using the software that they already have.
For more information, see To remove a managed application.

Deletion from the server

When you are sure that an old version of a program is no longer needed by the organization, you can delete the Windows Installer package and the program files and components. You might want to archive the package and the program files and components and then delete the files from the software distribution point.


Add or Remove Programs in Control Panel

By using Add or Remove Programs in Control Panel, you can perform a number of tasks—primarily, the task of installing an application from local media, such as a CD-ROM or floppy disk; a defined Active Directory location, for an assigned and published application on a corporate network; or the Internet. You can also use Add or Remove Programs to remove or modify an existing application or to repair a damaged application.

Add or Remove Programs also offers the following features:

  • Provides users with a single user interface for managing and maintaining their programs.
  • Supports the installation of programs when a user has the program package (on local media), as well as installation from either a corporate or an Internet environment.
  • Exposes the Windows Installer component while maintaining support for other installation technologies.

For more information, see Using Add or Remove Programs.


File types that you use with Group Policy Software Installation

In addition to executable files such as Setup.exe and Install.exe, you can also use the files listed in the following table with Group Policy Software Installation.

For more information about specific Group Policy Software Installation procedures, see Use Group Policy Software Installation. For general information about Group Policy Software Installation, see Group Policy Software Installation.

File type | File name extension | Description
Windows Installer packages | .msi | Your software vendor typically provides these files to facilitate installation of a specific application. Keep these files with any other necessary files at the software distribution point for the software that you are managing.
Transforms | .mst | Also called modifications, these files customize the installation of a Windows Installer package at the time of assignment or publication. For example, they might specify a subset of a suite of applications.
Patches .msp Bug fixes, service packs, and similar files can be distributed in this form.

Patches should not be used for major changes, and their effects are limited in the following ways:

  • They cannot remove components or features.
  • They cannot change product codes.
  • They cannot remove or change the names of shortcuts, files, or registry keys.
.zap files .zap These files are created with a text editor, such as Notepad. They can only be published (not assigned), and they specify a Setup executable program that appears in Add or Remove Programs in Control Panel for users with administrative rights on the local computer.

Note

  • Correct use of quotes in .zap file syntax can be difficult. The following rules apply:
    • The path and name of the Setup executable program must always be wrapped in quotation marks.
    • If there are no command-line arguments, they must be wrapped in two sets of quotation marks.

    Example syntax using an absolute path:
    SetupCommand=""\\ServerName\ShareName\FolderName\setup.exe""
    SetupCommand="\\ServerName\ShareName\FolderName\setup.exe" /argument

    Example syntax using a relative path:
    SetupCommand=""setup.exe""
    SetupCommand="setup.exe" /argument
Application assignment scripts | .aas | These files contain instructions that are associated with the assignment or publication of a package.


Group Policy precedence

You can apply Active Directory–based Group Policy by linking Group Policy objects to Active Directory objects (sites, domains, or organizational units). Group Policy settings under User Configuration apply to users, and Group Policy settings under Computer Configuration apply to computers. The locations of the user and computer accounts in Active Directory determine what Group Policy objects are used to supply policy. Note that although some settings are user interface settings—for example, the background bitmap or the ability to use the Run command on the Start menu—they can also be applied to computers.

Group Policy is cumulative. Child directory service containers inherit policy from parent containers, and Group Policy processing occurs in the following order: local, site, domain, and then successive organizational units, from highest organizational unit (farthest from the user or computer account) to lowest organizational unit (actually containing the user or computer account). This means that if you link a Group Policy object to a high-level parent container (domain or organizational unit), this Group Policy object applies to all containers beneath the parent container, that is, to the user and computer objects in each container. However, if you explicitly enable or disable some Group Policy settings in another Group Policy object that is linked to a child container, the child container's Group Policy object settings override the parent container's Group Policy object settings.

You can enforce Group Policy on child directory containers by setting the No Override option on a Group Policy object link. You can also prevent inheritance of Group Policy from parent directory containers by using the Block Policy inheritance option on a domain or organizational unit.

Important

  • No Override and Block Policy inheritance are advanced options, and they are not recommended for casual use, because they change the default behavior of policy inheritance, as described in the previous paragraph, and this can complicate troubleshooting.

Note

  • In the event of a conflict, Group Policy settings take precedence over user profile settings.

This section covers:

  • Order of events when starting up and logging on
  • Order of processing settings
  • The role of applications in Group Policy precedence


Order of events when starting up and logging on

The following sequence shows the order in which computer policy and user policy are applied when a computer starts and a user logs on:

  1. Network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start.
  2. An ordered list of Group Policy objects is obtained for the computer. The list might depend on these factors:
    • Whether the computer is part of a domain and therefore subject to Group Policy through Active Directory.
    • The location of the computer in Active Directory.
    • Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done. You can use a policy setting to change this behavior.
  3. Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.

    For details about the order in which settings are processed when user or computer policy is applied, see Order of processing settings.

  4. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
  5. The user presses CTRL-ALT-DEL to log on.
  6. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.
  7. An ordered list of Group Policy objects is obtained for the user. The list might depend on these factors:
    • Whether the user is part of a domain and 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.
    • Whether the list of Group Policy objects has changed. If the list of Group Policy objects has not changed, no processing is done. You can use a policy setting to change this behavior.
  8. User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.

    For details about the order in which settings are processed when user or computer policy is applied, see Order of processing settings.

  9. Logon scripts run. Unlike Windows NT 4.0 scripts, Group Policy–based logon scripts are hidden and asynchronous by default. The user object script runs last in a normal window.
  10. The operating system user interface that is prescribed by Group Policy appears.

Important

  • Three special cases deserve consideration during migration:
    • If the computer account object is in a Windows NT 4.0 domain and the user account object is in Active Directory, only computer (not user) System Policy is processed when the user logs on. Then, user (not computer) Group Policy is processed.
    • If the computer account object is in Active Directory and the user account object is in a Windows NT 4.0 domain, computer (not user) Group Policy is processed during computer startup. When the user logs on, user (not computer) System Policy is processed.
    • If the computer and user accounts of the computer running XOX or a Windows Server 2003 operating system are members of a Windows NT 4.0 domain, only System Policy (not Group Policy) for the computer and user is applied when the user logs on.

Notes

  • Several of these events can be modified. You can set policies to:
    • Reverse the synchronized or asynchronized defaults for running scripts and applying policy.
    • Specify when scripts time out. By default, scripts time out after 600 seconds.
    • Change whether scripts are run hidden, minimized, or in a normal window.


Order of processing settings

This section provides details about the order in which Group Policy settings for users and computers are processed. For information about where the processing of policy settings fits into the framework of computer startup and user logon, see steps 3 and 8 in Order of events when starting up and logging on.

Group Policy settings are processed in the following order:

  1. Local Group Policy object—Each computer has exactly one Group Policy object that is stored locally.
  2. Site—Any Group Policy objects that have been linked to the site are processed next. Processing is synchronous and in an order that is specified by the administrator.
  3. Domain—Processing of multiple domain-linked Group Policy objects is synchronous and in an order specified by the administrator.
  4. Organizational units—Group Policy objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy objects that are linked to its child organizational unit, and so on. Finally, the Group Policy objects that are linked to the organizational unit that contains the user or computer are processed.

    At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy objects can be linked. If several Group Policy objects are linked to an organizational unit, their processing is synchronous and in an order that is specified by the administrator.

This order means that the local Group Policy object is processed first, and Group Policy objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy objects.

Exceptions to the default order

The default order for processing settings is subject to the following exceptions:

  • Any Group Policy object that is linked to a site, domain, or organizational unit (not a local Group Policy object) can be set to No Override with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. When more than one Group Policy object has been set to No Override, the one that is highest in the Active Directory hierarchy (or higher in the hierarchy that is specified by the administrator at each fixed level in Active Directory) takes precedence.

    Note that No Override and Disabled are settings on Group Policy objects links, not on the Group Policy objects. A Group Policy object can be linked several times to the same organizational unit, and No Override and Disabled can be configured independently on each of the links. (Although multiple links from one Group Policy object to a single organizational unit are seldom useful, this capability illustrates the flexibility of the Group Policy infrastructure.)

    For information about how to set links as No Override and Disabled, see To prevent a Group Policy object from being overridden and To disable a Group Policy object link.

  • At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as Block Policy inheritance. Group Policy object links that are set to No Override are always applied, however, and they cannot be blocked.

    The Block Policy inheritance setting is applied directly to the site, domain, or organizational unit. It is not applied to Group Policy objects, nor is it applied to Group Policy object links. Block Policy inheritance deflects all Group Policy settings that would reach the site, domain, or organizational unit from above (by way of links to parents in the Active Directory hierarchy), no matter what Group Policy objects those settings originate from. However, Block Policy inheritance does not deflect Group Policy settings from Group Policy objects that are linked directly to the site, domain, or organizational unit that has Block Policy inheritance enabled.

  • A computer that is a member of a workgroup processes only the local Group Policy object.
  • 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. For a description of loopback, click the Explain tab after you double-click User Group Policy loopback processing mode in the details pane of the Microsoft Management Console (MMC), which is located under Computer Configuration\Administrative Templates\System\Group Policy.

    Loopback provides alternatives to the default method of obtaining the ordered list of Group Policy objects whose User Configuration settings affect a user. By default, a user's settings come from a Group Policy object list that depends on the user's location in Active Directory. The ordered list goes from site-linked to domain-linked to organizational unit–linked Group Policy objects, with inheritance determined by the location of the user in Active Directory and in an order that is specified by the administrator at each level.

    Loopback can be set to Not Configured, Enabled, or Disabled, as can any other Group Policy setting. In the Enabled state, loopback can be set to Merge or Replace.

    • Loopback with Replace—In the case of Loopback with Replace, the Group Policy object list for the user is replaced in its entirety by the Group Policy object list that is already obtained for the computer at computer startup (during step 2 in Order of events when starting up and logging on). The User Configuration settings from this list are applied to the user.
    • Loopback with Merge—In the case of Loopback with Merge, the Group Policy object list is a concatenation. The default step 2 list for computers in Order of events when starting up and logging on is appended to the default step 7 list for users, and the user gets the User Configuration settings in the concatenated list. Note that the Group Policy object list that is obtained for the computer is applied later, and therefore it has precedence if it conflicts with settings in the user's list.


The role of applications in Group Policy precedence

The Group Policy infrastructure cannot force applications to use Group Policy. For example, applications that have always looked for registry entries in a particular place that is outside the approved registry trees that are reserved for Group Policy will continue to look there. Group Policy does not copy registry settings from the Group Policy areas to the Windows NT 4.0 System Policy areas, nor does it copy Windows NT 4.0 System Policy settings into the reserved Group Policy areas. For more information, see Windows NT 4.0 system policies and Migration issues.

Guidelines for writing applications that take advantage of Group Policy are available in the Group Policy Platform SDK that is used by developers. For more information, see "Group Policy" at the Microsoft Web site. (http://msdn.microsoft.com/) Administrators, who need to anticipate the behavior of applications that they do not author, should be aware of the steps taken by properly written applications to obtain the registry data that the applications need.

Initial state of the registry

After the computer starts and the user logs on, the Group Policy registry areas are rewritten to hold the cumulative Group Policy settings that are in effect from the local Group Policy object and from Active Directory. If Windows NT 4.0 System Policy is enabled (which is not recommended for client computers running XOX, XOX, and Windows Server 2003 operating systems, or Windows 2000 clients), other registry areas might also change when the user logs on.

Order of events

  1. The user starts the application.
  2. A typical user-oriented application looks for registry data in the Group Policy reserved area HKEY_LOCAL_MACHINE\Software\Policies. If the application finds what it needs, it looks no further.

    However, an application that changes or replaces features at the level of the operating system (such as the Run command), and which therefore affects the behavior of applications other than itself, might look in the following Group Policy reserved area: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies. If the application finds what it needs, it looks no further.

  3. The application looks for HKEY_LOCAL_MACHINE registry data outside the Group Policy reserved area, and if it finds what it needs, it looks no further.
  4. The application looks for HKEY_CURRENT_USER registry data outside the Group Policy reserved area, and if it finds what it needs, it looks no further.
  5. The application uses .ini files (not recommended) or default settings.

Newly authored, native XOX applications might perform only the first three steps. Applications that use Group Policy under XOX, but which remain compatible with earlier versions of Windows, continue to step 4 when they run on older operating systems. Applications that predate Windows 2000 never perform steps 2 and 3. Instead, they go directly to step 4.

The order of this sequence of events implies the following:

  • For properly written applications that run on client computers running XOX, XOX, and Windows Server 2003 operating systems, Group Policy takes precedence over Windows NT 4.0 System Policy. For more information, see Policy inheritance, Order of events when starting up and logging on, and Order of processing settings.
  • Older versions of applications, which are not aware of Active Directory and Group Policy, continue to function in XOX, XOX, and the Windows Server 2003 family as they did under Windows NT 4.0.
  • HKEY_LOCAL_MACHINE settings take precedence over HKEY_CURRENT_USER settings, as they did under Windows NT 4.0.


Using Group Policy

This section covers:

  • Ways to open Group Policy Object Editor
  • Local Group Policy
  • Administrative Templates included with this version of Windows
  • Advanced methods of extending Group Policy
  • Group Policy permissions
  • Group Policy and network infrastructure
  • Migration issues
  • Managing Group Policy from the command line


Ways to open Group Policy Object Editor

You can open Group Policy Object Editor in several ways, depending on the action that you want to perform and the object to which you want to apply Group Policy. The following table lists the ways in which you can open Group Policy Object Editor.

To apply Group Policy to | Do this
Local computer | In Group Policy Object Editor, edit the local Group Policy object, as described in To edit the local Group Policy object.
Another computer | Open the local Group Policy object that is stored on the network computer, as described in To open Group Policy Object Editor as an MMC snap-in, and then browse to the network computer. You must have administrative rights on the network computer.
Site | Open Group Policy Object Editor, as described in To open Group Policy Object Editor from Active Directory Sites and Services, and then link a Group Policy object to the intended site.
Domain | Open Group Policy Object Editor as described in To open Group Policy Object Editor from Active Directory Users and Computers, and then link a Group Policy object to the intended domain.
Organizational unit | Open Group Policy Object Editor as described in To open Group Policy Object Editor from Active Directory Users and Computers, and then link a Group Policy object to the intended organizational unit. You can also link a Group Policy object to an organizational unit that is higher in the Active Directory hierarchy, so that the organizational unit can inherit Group Policy settings.
Existing Group Policy object or set of Group Policy objects | Create and save your own custom Microsoft Management Console (MMC). For more information, see Microsoft Management Console.

You can also open Group Policy Object Editor by clicking Start, clicking Run, and then typing a command. Or, you can open Group Policy Object Editor at the command prompt in an MS-DOS window. The following table contains some examples of how you might open Group Policy Object Editor from the command line in different situations.

To edit | At a command line, use this command-line syntax
The local Group Policy object on ThisComputerName | gpedit.msc /gpcomputer:"ThisComputerName"
The local Group Policy object on ThisComputerName (specified in the DNS style) | gpedit.msc /gpcomputer:"ThisComputerName.domain.com"
Group Policy objects stored in Active Directory gpedit.msc /gpobject:"LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=WingTipToys,DC=com"

Note

  • The GUID for the Group Policy object above is a fictitious example.

For information about other Group Policy command-line tools, see Managing Group Policy from the command line.


Local Group Policy

Each computer running Windows 2000, XOX, XOX, or a Windows Server 2003 operating system has exactly one local Group Policy object. In these objects, Group Policy settings are stored on individual computers, whether or not they are part of an Active Directory environment or a networked environment. For more information, see Security settings, Folder Redirection, and Group Policy Software Installation overview.

Local Group Policy objects contain fewer settings than nonlocal Group Policy objects, particularly under Security Settings. Local Group Policy objects do not support Folder Redirection or Group Policy Software Installation.

Because its settings can be overwritten by Group Policy objects that are associated with sites, domains, and organizational units, the local Group Policy object is the least influential object in an Active Directory environment. In a non-networked environment (or in a networked environment that does not have a domain controller), the local Group Policy object's settings are more important, because they are not overwritten by other Group Policy objects.

To edit the local Group Policy object that is stored on your local computer, use the Group Policy Object Editor snap-in. For more information, see To edit the local Group Policy object.

If you want to edit the local Group Policy object that is stored on another computer on the network, open Group Policy as a stand-alone Microsoft Management Console (MMC) snap-in and browse to the Group Policy object that you want. For more information, see To open Group Policy Object Editor as an MMC snap-in.

The local Group Policy object resides in systemroot\System32\GroupPolicy.

Computers that run Windows NT 4.0 or earlier do not have a local Group Policy object, and they do not recognize nonlocal Group Policy. For more information, see Migration issues.


Administrative Templates included with this version of Windows

Five Administrative Templates (.adm) files are included with this version of Windows. The following table contains a brief description of each of the .adm files. For more information about .adm files, see Administrative Templates.

Administrative Template | Description | Help for Administrative Templates policy settings
System.adm | System settings | System settings
Inetres.adm | Internet Explorer settings | Internet Explorer settings
Wmplayer.adm | Windows Media Player settings. XOX | Windows Media Player settings
Conf.adm | NetMeeting settings. XOX | NetMeeting settings
Wuau.adm | Windows Update settings. | Windows Update settings

When you add an .adm file to Group Policy, as described in To add or remove an Administrative Template (.adm file), 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.

If you want to change this default behavior and make not only Group Policy settings but also the older System Policy settings visible, see To filter the view provided by Administrative Templates. Clear the Only show policy settings that can be fully managed check box, as described in that procedure. Your ability to clear this check box in the Filtering dialog box is subject to the Enforce Show Policies Only Group Policy setting.

When you make preference settings appear in Group Policy Object Editor, the icons for these settings are colored red. The icons for true Group Policy settings are colored blue.

Important

  • It is highly recommended that you do not use System Policy–type .adm files when you manage client computers running Windows 2000 Professional, XOX, XOX, or Windows Server 2003 operating systems because this can lead to undesirably persistent registry settings. For more information, see Migration issues.


Advanced methods of extending Group Policy

The following table lists advanced methods that you can use to extend Group Policy functionality.

Method Advantages Disadvantages
For administrators only: Write an .adm file
  • Easier than writing an extension to Group Policy.
  • Everything you need is included in the Windows Server 2003 family.
  • The .adm files are text files, which you can edit in Notepad.
  • You can write from scratch or modify existing templates to suit your purpose.
  • This option is only suitable for registry-based policies.
  • The user interface is limited. Finding where to set individual policies might be difficult.
For software developers only: Write an extension to Group Policy
  • Richer user interface.
  • The full Group Policy application programming interface (API) is available to the developer.
  • Not limited to registry-based policies.
  • Because writing an extension takes considerable development time, this option is not worthwhile unless it will be used widely or often.
  • Requires software development kit (SDK) material that is not included with the Windows Server 2003 family.

Creating custom .adm files

You can consider creating custom .adm files if the supplied template, System.adm, is inadequate. However, it is recommended that you use the supplied template.

Administrative Templates propagate registry settings to a large number of computers without requiring you to have detailed knowledge of the registry. In the Windows Server 2003 family, Group Policy is used to set registry-based policies. In Windows NT 4.0, the System Policy Editor (Poledit.exe) was used to set System Policy.

For more information, see "Implementing Registry-based Policy" at the Microsoft Web site. (http://msdn.microsoft.com/)

Creating Microsoft Management Console extensions

Developers can create extensions to Microsoft Management Console (MMC) snap-ins to provide program-specific user interfaces for setting Group Policy. For more information, see "Group Policy" at the Microsoft Web site (http://msdn.microsoft.com/) and "MSDN Library" at the Microsoft Web site. (http://msdn.microsoft.com/)


Group Policy permissions

If you want to delegate policy-related tasks to other people, including nonadministrators, see Delegate control of Group Policy.

This section covers:

  • Default permissions
  • Policy for Microsoft Management Console


Default permissions

The following table describes the default permissions on Group Policy objects.

Security group | Default settings
Authenticated users | Read, Apply Group Policy (AGP)
Local system | Full Control (includes AGP)
Domain administrators | Read, Write, Create Child, Delete Child, AGP
Administrators | Read, Write, Create Child, AGP
Group Policy Creator Owners | Read, Write, AGP

By default, the Group Policy object Default Domain Policy cannot be deleted by any administrator. The purpose of this restriction is to prevent the accidental deletion of this Group Policy object, which contains important and required settings for the domain. If Default Domain Policy must be deleted for some reason, the Delete permission must be given explicitly to the intended group. This is an advanced access control entry (ACE) on the Group Policy object. For more information, see To set permissions for Group Policy Software Installation.


Policy for Microsoft Management Console

There are several Group Policy settings in one of the default Administrative Templates files, System.adm, that govern the use of the Microsoft Management Console (MMC). You can delegate administrative rights by saving previously configured consoles. For more information, see Delegate control of Group Policy. You can find MMC policy settings in Group Policy Object Editor. You can then double-click each item for which you want to set an administrative Group Policy setting that governs the use of that item in MMC.

For more information, see Microsoft Management Console, Group Policy permissions, and Configure Group Policy.


Group Policy and network infrastructure

This section covers:

  • Group Policy features that are supported across forests
  • Group Policy in multiplatform networks
  • Group Policy in replicated environments
  • Group Policy over slow links
  • Group Policy on sites


Group Policy features that are supported across forests

The Windows Server 2003 family introduces a powerful set of new features that enable you to authenticate and authorize access to resources from separate, networked forests. With full trusts established between forests, you can manage Group Policy throughout Active Directory regardless of the forest, which provides greater flexibility especially in large organizations. For more information about accessing resources across forests in Active Directory, see Accessing resources across forests. For more information on forest trusts, see Forest trusts.

Following is a list of the Group Policy features that are supported across forests:

  • Interactive logon

    The following table lists the interactive logon tasks that are supported across forests.

    Task | Support across the domain? | Support across domains in the same forest? | Support interactive logon across forests?
    Apply policy to a user object | Yes | Yes | Yes
    Apply policy to a computer object | Yes | Yes | Yes
    Support Group Policy loopback processing | Yes | Yes | Yes

    For example, User1 is located in forestA and computer1 is located in forestB. User1 goes to forestB and logs into computer1. In this scenario, computer policy is applied to computer1 from forestB, user policy is applied to user1 on computer1 from forestA. Site policy might be applied depending on the subnet to which computer1 belongs.

    For interactive logon across forests with loopback processing, Group Policy objects with loopback enabled for merge or replace are applied across forests under the same logon model as specified for interactive logon. For more information about loopback, see Order of processing settings.

  • Network logon

    The following Group Policy extensions are supported for network logon across forests:

    • Software distribution points located in another forest
    • Logon scripts on a shared network directory in another forest.
    • Roaming user profiles stored on a shared network directory in another forest. For more information, see Using roaming user profiles.
    • Redirected folders stored on a file share in another forest. For more information, see Folder Redirection.
  • Delegation

    Delegation across forests is supported for managing Group Policy links. Other tasks such as creating, deleting, or modifying Group Policy objects across forests is not supported.


Group Policy in multiplatform networks

Many networks include computers with different operating systems and versions. To allow administrators the greatest control, Group Policy and its extensions can be applied to computers running Windows 2000 Professional, Windows 2000 Server, XOX, XOX, and Windows Server 2003 operating systems.

For client computers running XOX, XOX, and Windows Server 2003 operating systems that are operating in networks with Windows 2000 Active Directory, the following features and limitations apply:

  • Fast Logon Optimization

    The Windows Server 2003 family provides a Fast Logon Optimization feature. This results in the asynchronous application of policy when the computer starts up and when the user logs on. This feature is supported for client computers running XOX, XOX, and Windows Server 2003 operating systems that are operating in any environment. This feature is not available to Windows 2000 clients. For more information, see Logon Optimization with Group Policy.

  • Administrative Templates

    The Windows Server 2003 family supports all registry policy settings available in Windows 2000. In addition, the Windows Server 2003 family has 212 new registry settings. These new policy settings only apply to client computers running XOX, XOX, and Windows Server 2003 operating systems. If specified for Windows 2000 clients, the settings are ignored. You can deploy new .adm files provided with XOX and Windows Server 2003 operating systems from Windows 2000 Active Directory. For more information, see Administrative Templates.

  • Folder Redirection

    The Windows Server 2003 family contains a new Folder Redirection with a simplified user interface. You can configure folder redirection for client computers running Windows 2000, XOX, XOX, and Windows Server 2003 operating systems. With client computers running XOX, XOX, and Windows Server 2003 operating systems, you can redirect folders to a HomeDir or redirect a folder back to a local profile. These options cannot be applied to Windows 2000 clients. For more information, see Folder Redirection.

  • Roaming User Profiles

    This feature contains new registry policy settings to prevent Roaming User Profile changes from propagating to the server, allow only local user profiles, and add Administrators security group to Roaming User Profiles. These features can only be applied to client computers running XOX, XOX, and Windows Server 2003 operating systems. Users can roam between client computers running XOX, XOX, and Windows Server 2003 operating systems and Windows 2000 clients, however, only policies that can be applied to each platform will be used. For more information, see Using roaming user profiles.

  • Security

    With a software restriction policy, you can identify software on client computers and prevent it from running. Software can be identified by file name, path, URL, and MD5 Hash. This policy must be configured in a Group Policy object from the security settings snap-in from a client computer running XOX, XOX, or Windows Server 2003 operating systems. This feature is not supported for Windows 2000 clients. For more information, see Security Settings.

  • Group Policy Software Installation

    The Windows Server 2003 family contains numerous enhancements to the Group Policy Software Installation user interface. In addition, this version of Windows also support the deployment of 32-bit MSI applications to client computers running XOX, 64-bit version of XOX, and 64-bit version of XOX. You cannot install 64-bit applications on 32-bit clients. There is no support for .zap files on client computers running XOX, XOX, and 64-bit version of XOX. Although Group Policy provides a robust solution for software installation and distribution, Microsoft Systems Management Server is the preferred solution for enterprise software planning, distribution, and management. For more information, see Group Policy Software Installation.

  • WMI filtering

    With WMI Filters, you can specify a WMI-based query to filter the application of a Group Policy object. WMI Filters are written using WMI query language (WQL). WMI Filters only apply to client computers running XOX, XOX, and Windows Server 2003 operating systems. WMI Filters associated with a Group Policy object will be ignored by Windows 2000 clients. For more information, see WMI Filters overview.


Group Policy in replicated environments

In a domain that contains more than one domain controller, Active Directory information takes time to propagate from one domain controller to another. This topic describes the replication mechanism as it relates to Group Policy.

By default, Group Policy objects are created or edited only on the domain controller that is holding the primary domain controller (PDC) emulator operations master token. This token moves from one domain controller to another over time, as Active Directory information is replicated to keep the domain controllers synchronized.

An organizational unit must be replicated to the domain controller that is holding the token before the Group Policy object that is created there can be linked to it, which allows the Group Policy settings to be applied. If you use Active Directory Users and Computers, you can create an organizational unit on any domain controller. These considerations are more significant if the intradomain links are slow. For more information, see Group Policy over slow links and Group Policy on sites.

Options governing selection of a domain controller

When you click the name of the Group Policy object in the console tree of Group Policy Object Editor, the View menu contains a command called DC Options. This command opens the Options for domain controller selection dialog box, where you can specify a domain controller to use for editing Group Policy. The options in this dialog box are as follows:

  • The one with the Operations Master token for the PDC emulator—This is the default and preferred option, and it is the best option from the standpoint of data safety.
  • The one used by the Active Directory snap-ins—This option uses the same domain controller as the utility from which the Group Policy Object Editor was invoked, if Group Policy was started this way.
  • Use any available domain controller—This option allows Group Policy Object Editor to choose any available domain controller. This is the least safe option, because different administrators could theoretically edit a Group Policy object simultaneously, with an indeterminate outcome. On the other hand, when you use this option, it is likely that a domain controller in the local site will be selected. If only one administrator can administer Group Policy on a large domain with several sites, the performance gain might be worthwhile.

Domain controller selection set through Group Policy

In addition to the DC Options command, there is also a Group Policy setting for domain controller selection. This is part of the System.adm Administrative Template that is loaded into Group Policy Object Editor by default. You can find this Group Policy setting in Group Policy Object Editor under User Configuration\Administrative Templates\System\Group Policy. You can double-click Group Policy domain controller selection in the details pane, and then click the appropriate setting in the list.


Group Policy over slow links

If the computer is a member of the domain that the Routing and Remote Access server belongs to or is trusted to, you can apply Group Policy remotely. This is true whether you are logging on through Routing and Remote Access or logging on with cached credentials, and then establishing a Routing and Remote Access connection.

Group Policy is not applied to computers that are members of a workgroup or of a foreign domain (a domain that does not contain the computer and that is not in a trust relationship with the computer's domain). Although the connection may still be made, access to domain resources may be adversely affected because of mismatched Internet Protocol security (IPSec).

By default, registry-based policies are always applied, and they cannot be turned off. Security settings are also applied by default, but all other settings are not applied. For all but the registry settings, the default behavior can be switched to apply or not apply.

A remote access connection is not necessarily a slow link, nor is a local area network (LAN) necessarily a fast link. By default, the fast or slow status of a link is based on a test ping to the server. If it takes less than 2000 milliseconds (two seconds), it is considered a fast link. If it takes more time, it is considered a slow link. You can set this value by using the Group Policy setting Slow network connection time-out for user profiles, which is located under Computer Configuration\Administrative Templates\System\User Profiles.

Several other Group Policy settings that are related to slow links appear in this folder as well. Also, check the Group Policy setting Group Policy slow link detection, which is located under Computer Configuration\Administrative Templates\System\Group Policy.

For more information, see Group Policy in replicated environments and Group Policy on sites. For a more information about slow link detection, see "Group Policy" at the Microsoft Web site. (http://www.microsoft.com/)


Group Policy on sites

Group Policy objects that are applied to Active Directory site objects affect all computers in the site. Directory information is replicated and available among all the domain controllers in the site and to any domain controllers in sites for which a site link has been established. Therefore, any Group Policy object that is linked to a site is applied to all computers in that site, without regard to which domain (in the forest) contains the computers.

This allows multiple domains within a forest to receive the same Group Policy object (and included policies), although the Group Policy object exists only as a stored entity on a single domain and it must be read from that domain when the affected clients read their site-linked Group Policy.

If child domains are set up across wide area network (WAN) boundaries, the site setup should take this into account. If it does not, the computers in a child domain access a site-linked Group Policy object across a WAN link. This increases the processing time for Group Policy.

For more information, see Group Policy in replicated environments and Group Policy over slow links.

Note

  • Group Policy is not usually applied to sites. It is usually applied to domains and organizational units. For more information, see Ways to open Group Policy Object Editor.


Migration issues

This section covers:

  • Client operating systems
  • The role of Administrative Templates
  • The role of System Policy Editor
  • Windows NT 4.0 system policies


Client operating systems

This section describes several operating system issues regarding clients for policy.

  • Windows Server 2003 family

    • Group Policy fully supports client computers that run Windows Server 2003 operating systems. These servers can either be ordinary member servers of Active Directory or domain controllers. Group Policy fully supports both types of computers.

  • Windows 2000 Server

    • Computers that run Windows 2000 Server can either be ordinary member servers of Active Directory or domain controllers. Group Policy fully supports both types of computers.

  • XOX and Windows 2000 Professional

    • Group Policy fully supports client computers that run XOX, XOX and Windows 2000 Professional.

  • Windows 95, Windows 98, and Windows Millennium Edition

    • It is recommended that Windows 95, Windows 98 and Windows Millennium Edition clients run System Policy Editor (Poledit.exe) on the local computer. This ensures that the Config.pol file that is created is compatible with those operating systems. Copy the resultant Config.pol file to the SysVol folder of the domain controller. Group Policy does not apply.

  • Windows NT 4.0 Workstation and Windows NT 4.0 Server

    • These clients continue to be fully supported by Windows NT 4.0 System Policy. You can use System Policy Editor (Poledit.exe) to write Windows NT 4.0 .adm files. System Policy Editor can be obtained from a Windows NT 4.0 CD. Windows NT 4.0 does not use Active Directory. Because computers that run Windows NT 4.0 do not have local Group Policy objects, Group Policy does not apply. For more information, see Local Group Policy.

  • XOX, Windows NT 3.51, Windows 3.1, and MS-DOS

    • Group Policy does not apply to these operating systems.


The role of Administrative Templates

In the Windows Server 2003 family, Administrative Templates use the .adm file name extension, as they did in Windows NT 4.0. However, their role is slightly different.

Role in earlier versions of Windows

In earlier versions of Windows, Administrative Templates were ANSI-encoded text files. They created a namespace within System Policy Editor for convenient editing of the registry. Administrative Templates provided a friendlier user interface than the Registry Editor (Regedit.exe). They also added a degree of safety by exposing only the registry keys that are explicitly mentioned in the .adm file.

Role in the Windows Server 2003 family

The Windows Server 2003 family of products include several .adm files, which are listed in Administrative Templates included with this version of Windows. You can also write additional .adm files. The new version of the .adm language is a superset of the previous version—older templates can create a user interface in Group Policy, but new templates cannot create a user interface in System Policy Editor. For more information on the new .adm language, see "Implementing Registry-based Policy" at the Microsoft Web site. (http://msdn.microsoft.com/)

The Windows Server 2003 family supports Unicode-based .adm files.

For information about using Windows NT 4.0 .adm files in a Windows 2000, XOX, XOX, or Windows Server 2003 family environment, see Windows NT 4.0 system policies.


The role of System Policy Editor

Although System Policy Editor (Poledit.exe) is mostly replaced by Group Policy, it is still useful under some circumstances. If you are upgrading from earlier versions of Windows, see Migration issues.

  • Management of computers that run Windows 95 or Windows 98—System Policy Editor must be run locally on computers that run Windows 98 or Windows 95 to create Config.pol files that are compatible with the local operating system.
  • Management of computers that run Windows NT 4.0 Workstation and Windows NT 4.0 Server—These computers also need their own .pol file: NTconfig.pol.
  • Management of stand-alone computers—A Windows 2000 computer that is not joined to any domain is not subject to nonlocal Group Policy through Active Directory. The only Group Policy that applies to such a computer is local Group Policy, which contains settings for all users of that computer. For more information on local Group Policy, see Local Group Policy. To provide settings for multiple users, use System Policy Editor to write a Registry.pol file. Only the Windows 2000 version of System Policy Editor is compatible with Windows 2000.

Although earlier versions of System Policy Editor worked only with ASCII-encoded .adm files, the Windows 2000 version also supports Unicode-encoded .adm files.

For client computers running Windows 2000, XOX, XOX, and Windows Server 2003 operating systems, use Group Policy instead. For tips about using Group Policy, see Best practices.


Windows NT 4.0 system policies

If a Windows NT 4.0 client computer is upgraded to XOX, XOX, or a Windows Server 2003 operating system, the computer receives only Computer Configuration Group Policy, not Windows NT 4.0 computer System Policy. The policy that is received by the user who logs on is User Configuration Group Policy, if the user account is in Active Directory. If the user account is managed by a Windows NT 4.0 domain controller, the user receives Windows NT 4.0 user System Policy. For more information, see Computer Configuration and User Configuration.

Policies that are included with Windows 2000, XOX, XOX, and the Windows Server 2003 family set registry keys and values only in one of these four reserved trees:

  • HKEY_LOCAL_MACHINE\Software\Policies
  • HKEY_CURRENT_USER\Software\Policies
  • HKEY_LOCAL_MACHINE\Software\Microsoft\
    Windows\CurrentVersion\Policies
  • HKEY_CURRENT_USER\Software\Microsoft\
    Windows\CurrentVersion\Policies

The first two trees are preferred. All four trees are secure, and they cannot be modified by a user who is not an administrator. When Group Policy changes for any reason, these trees are wiped clean and the new policies are rewritten. Windows NT 4.0 policies do not respect these special trees, and they can write to any part of the registry. After such a policy is applied, it persists until the value is intentionally reversed, either by a counteracting Windows NT 4.0 policy or by editing the registry.

Caution

  • It is possible, using the procedure to add or remove an Administrative Template (.adm file), for Administrative Templates to be added to Group Policy that set registry values outside the approved Group Policy trees, although the Windows Server 2003 family does not include any such .adm file. Choosing to install Windows NT 4.0 .adm files can lead to undesirable persistent registry settings. For more information, see Administrative Templates and To add or remove an Administrative Template (.adm file).

    • If you must use the procedure in this manner, see the information about the Only show policy settings that can be fully managed check box in To filter the view provided by Administrative Templates and the information about the Enforce Show Policies Only Group Policy setting in To add or remove an Administrative Template (.adm file).


Managing Group Policy from the command line

In addition to using Group Policy Object Editor, you can use command-line tools to manage Group Policy. For example, you can use gpresult to see what policy is in effect and to troubleshoot problems. You can use gpupdate to refresh policy immediately and to specify certain options at the command line.

For more information about Group Policy command-line tools, see the following:

  • Gpresult
  • Gpupdate

Notes

  • Gpupdate replaces the Windows 2000 command secedit /refreshpolicy.
  • To start Group Policy Object Editor from the command line, see Ways to open Group Policy Object Editor.


Resources

Important

  • XOX

The following links are useful sources for planning, deploying, and managing Group Policy, Group Policy Software Installation, and Folder Redirection:

Microsoft Resource Kit Web site links to technical documentation

Change and Configuration Management (http://www.microsoft.com/)

Group Policy Overview (http://www.microsoft.com/)

Advanced Group Policy (http://www.microsoft.com/)

Group Policy-Based Software Deployment (http://www.microsoft.com/)

Extending and Troubleshooting Group Policy (http://www.microsoft.com/)

Microsoft Web site links to technical documentation

Group Policy (http://www.microsoft.com/)

Implementing Common Desktop Management Scenarios (http://www.microsoft.com/)

Implementing Registry-based Policy (http://msdn.microsoft.com/)

IntelliMirror Resource Guide (http://www.microsoft.com/)

Operations (http://www.microsoft.com/)

Planning and Deployment (http://www.microsoft.com/)

Step-by-Step Guides home page (http://www.microsoft.com/)

Systems Migration & Interoperability (http://www.microsoft.com/)

Technologies Index (http://www.microsoft.com/)

Troubleshooting Group Policy (http://www.microsoft.com/)

Related Windows tools and online Help topics

You can use the following tools with Group Policy:

  • IntelliMirror—IntelliMirror is a set of powerful features for change and configuration management. IntelliMirror ensures that users' data, software, and personal settings are available when they move from one computer to another, and persist when their computers are connected to the network. IntelliMirror features are a subset of Group Policy, which in turn requires the Active Directory directory service. Not all of the tools associated with IntelliMirror technologies are available on all versions of Windows. Of those tools that are available on computers running Windows Server 2003 operating systems, not all of them are appropriate for managing Windows computers. For more information, see IntelliMirror and Help for specific tools.
  • Resultant Set of Policy (RSoP)—Resultant Set of Policy (RSoP) is an addition to Group Policy that makes it easier to implement and troubleshoot policy. RSoP is a query engine that polls existing policies—and also planned policies—and then reports the results of those queries. It polls existing policies based on site, domain, domain controller, and organizational unit. RSoP gathers this information from the CIMOM database (commonly referred to as "WMI"). For more information, see Resultant Set of Policy.
  • User profiles—On computers running Windows Server 2003 operating systems, user profiles automatically create and maintain the desktop settings for each user's work environment on the local computer. A user profile is created for each individual user when logging on to a computer for the first time. You set a profile path from the Profile tab of a User object in Active Directory. For more information, see User profiles.
  • Windows Installer—Windows Installer is an integral part of IntelliMirror, and a core component of the Windows Group Policy-based change and configuration management technology. By using the IntelliMirror technologies, Group Policy, and change and configuration management, you can approve certain applications, specifying that all configuration operations on those applications (installation, removal, and repair) run as the local system account. For more information, see Windows Installer.


Troubleshooting

An important part of troubleshooting Group Policy problems is to consider dependencies between components. For example, Group Policy Software Installation relies on Group Policy, and Group Policy relies on Active Directory. Active Directory relies on proper configuration of network services. When trying to fix problems that appear in one component, it is generally helpful to check whether components, services, and resources on which the component relies are working correctly. Event logs are useful for tracking problems that are caused by this type of hierarchical dependency.

What problem are you having?

I need to know what policy settings are in effect.

Solution: To see what policy is in effect, use Resultant Set of Policy (RSoP) or gpresult.

You can also get a report on policy from Help and Support Center by following these steps:

  1. Click the Start button, and then click Help and Support.
  2. Click Support.
  3. Under See Also, click Advanced System Information.
  4. Under Advanced System Information, click View Group Policy settings applied.

The report includes the following:

  • User name and domain
  • Computer name and domain
  • When User Settings and Computer Settings were last applied
  • Folder redirection details
  • Logon, logoff, startup and shutdown scripts
  • Installed software
  • Administrative Templates
  • Security Settings
  • Connection and proxy settings for IE Maintenance

See also: RSoP; Gpresult

I want to refresh policy.

Solution: Use gpupdate to refresh policy immediately. With Gpupdate you can specify certain options at the command line. Gpupdate replaces and improves on the Windows 2000 command secedit /refreshpolicy. Some policy items, such as computer-assigned software, require a reboot to take effect, however. User-assigned software requires the user to log on and log off.

See also: Gpupdate; To refresh Group Policy immediately

I want to check basic network connectivity.

Solution: Try to ping a domain controller.

Verify that DNS is working properly.

See also: Ping; DNS; About Network Connections; To configure a connection to a remote network; Using local area connections; To test a TCP/IP configuration by using the ping command

I want to enable logging.

Solution: Set a registry key that causes Group Policy diagnostic logging to be written to a file named Userenv.log on the client computer.

You can also set a registry key that enables verbose logging to the event log so that you can see it with Event Viewer.

See also: Registry Editor; Event Viewer; "Monitoring Group Policy with Log Files" and "Verbose Logging to Event Log" sections in "Troubleshooting Group Policy" at the Microsoft Web site (http://www.microsoft.com/)

I need help with the individual Group Policy settings that are included in Administrative Templates.

Solution: This information is included in Help.

See also: Administrative Templates included with this version of Windows

I cannot open a Group Policy object in Group Policy Object Editor even though I have Read access to it.

Cause: As an administrator, you must have Full Control of the Group Policy object to open it in Group Policy Object Editor.

Solution: Verify that you are a member of a security group with Full Control on the Group Policy object. For example, a domain administrator can manage Active Directory–based Group Policy. An administrator on a computer can edit the local Group Policy object on that computer.

When I try to edit a Group Policy object, I get the "Failed to open the Group Policy object" error.

Cause: This usually is due to a networking problem, specifically, a problem with the domain name system (DNS) configuration.

Solution: Verify that DNS is working properly.

See also: DNS

When I try to edit a Group Policy object, I get the "Missing Active Directory Container" error.

Cause: This is caused by Group Policy attempting to link a Group Policy object to an organizational unit that it cannot find. The organizational unit might be deleted, or it might be created on another domain controller but not replicated to the domain controller that you are using.

Solution: Limit the number of administrators who can make structural changes to Active Directory, or who can edit a Group Policy object, at any one time. Allow changes to replicate before making changes that affect the same organizational unit or Group Policy object.

When I try to edit a Group Policy object, I get the "Snap-in failed to initialize" error.

Cause: This may be happen if Group Policy cannot find framedyn.dll.

Solution: If you use installation scripts, verify that your scripts place the systemroot\system32\wbem directory in the system path. By default, systemroot\system32\wbem is in the system path already; therefore, you are not likely to encounter this issue if you do not use installation scripts.

Group Policy is not being applied to users and computers in a security group that contains those users and computers, even though a Group Policy object is linked to an organizational unit that contains that security group.

Cause: This is correct behavior. Group Policy affects only the users and computers that are contained in sites, domains, and organizational units. Group Policy objects are not applied to security groups.

Solution: Link Group Policy objects to sites, domains, and organizational units only. The location of a security group in Active Directory is unrelated to whether Group Policy applies to the users and computers in that security group.

See also: To filter the scope of Group Policy according to security group membership

Group Policy is not affecting users and computers in a site, domain, or organizational unit.

Cause: Group Policy settings can be prevented, intentionally or inadvertently, from affecting users and computers in several ways. A Group Policy object can be disabled so that it does not affect users, computers, or both. It also must be linked directly to an organizational unit that contains the users and computers, or it must be linked to a parent domain or organizational unit, so that the Group Policy settings apply through inheritance.

When multiple Group Policy objects apply, they are processed in this order: local, site, domain, organizational unit. By default, settings that are applied later have precedence. In addition, Group Policy can be blocked at the level of any organizational unit, or it can be enforced through a setting of No Override that is applied to a particular Group Policy object link.

Finally, the user or computer must belong to one or more security groups that have the appropriate permissions set.

Solution: Do the following:

  • Verify that the intended policy is not being blocked.
  • Verify that no overriding policy that is set at a higher level of Active Directory has been set to No Override.
  • If Block and No Override are both used, No Override takes precedence.
  • Verify that the user or computer is not a member of any security group for which the Apply Group Policy access control entry (ACE) is set to Deny.
  • Verify that the user or computer is a member of at least one security group for which the Apply Group Policy access control entry (ACE) is set to Allow.
  • Verify that the user or computer is a member of at least one security group for which the Read access control entry (ACE) is set to Allow.

See also: Policy inheritance; To filter the scope of Group Policy according to security group membership

Group Policy is not affecting users and computers in an Active Directory container.

Cause: Group Policy objects cannot be linked to Active Directory containers other than sites, domains, and organizational units.

Solution: Link a Group Policy object to an organizational unit that is a parent to the Active Directory container. Then, by default, those settings are applied to the users and computers in the container through inheritance.

See also: To filter the scope of Group Policy according to security group membership

Group Policy is not taking effect on the local computer.

Cause: Local policies are the weakest. Any Active Directory–based policy can overwrite them.

Solution: Check to see what Group Policy objects are being applied through Active Directory and if those Group Policy objects have settings that are in conflict with the local settings.

Software that you assigned to a computer is not available on the computer.

Cause: The client computer has not been restarted.

Solution: Restart the client computer.

Software that you assigned or published to a user is not available on the user's computer.

Cause: The user has not logged off and then logged on.

Solution: Have the user log off and then log on.

Published applications do not appear in Add or Remove Programs in Control Panel.

Cause: Several causes are possible:

  • Group Policy is not applied.
  • Active Directory cannot be accessed.
  • Users do not have any published applications in the Group Policy objects that apply to them.
  • The client is running Terminal Server.

Solution: Investigate each possibility in turn. Note that Group Policy Software Installation is not supported for Terminal Server clients.

Document activation of a published application does not cause the application to install.

Cause: As an administrator, you did not set autoinstall.

Solution: Set autoinstall.

See also: To set the autoinstall option for an application

The user receives an error message such as "The feature you are trying to install cannot be found in the source directory."

Cause: This could be caused by network or permissions problems.

Solution: Verify that the network is working correctly.

See also: To set permissions for Group Policy Software Installation

The user receives an error message such as "This product is not installed" or "Feature ID not registered."

Cause: This could be caused by a user with a roaming user profile logging on to two computers simultaneously, which is an unsupported use of roaming user profiles.

Solution: Have the user log off one computer before logging on to another. That way, the application shortcuts will be updated and valid on the second computer, and they will not give error messages.

After removal of an application, the shortcuts for the application continue to appear on the user's desktop.

Cause: The user has created shortcuts, and Windows Installer does not recognize them.

Solution: The user must remove the shortcuts manually.

A user receives an error message such as "Another installation is already in progress."

Cause: An uninstallation might be taking place in the background, with no user interface presented to the user, or perhaps the user has inadvertently triggered two installations simultaneously, which is not supported.

Solution: The user can try again later.

The user opens an already installed application, and Windows Installer starts.

Cause: An application might be undergoing automatic repair, or a user-required feature is being added.

Solution: No action is required.

A user receives error messages such as "Active Directory will not allow the package to be deployed" or "Cannot prepare package for deployment."

Cause: The package might be corrupted, or there might be a networking problem.

Solution: Use an uncorrupted package. Investigate the possibility of network problems and take appropriate action.

When I click one of the Group Policy Software Installation icons in the console tree of Group Policy Object Editor, I get the error message "Snap-in failed to initialize."

Cause: This may be happen if Group Policy Software Installation cannot find framedyn.dll.

Solution: If you use installation scripts, verify that your scripts place the systemroot\system32\wbem directory in the system path. By default, systemroot\system32\wbem is in the system path already; therefore, you are not likely to encounter this issue if you do not use installation scripts.

I accidentally deleted default Group Policy objects.

Cause: This can happen when you delete Group Policy objects from Active Directory Users and Computers.

Solution: Use dcgpofix to restore default Group Policy objects to their original state.

See also: Dcgpofix

I accidentally deleted the domain controllers Sysvol directory or parts of the Sysvol directory that contain default Group Policy objects.

Cause: This can happen when you delete directories from the system root.

Solution: Restore the Sysvol directory. Use the Dcgpofix command-line tool to restore default Group Policy objects to their original state. It is very important to backup the Sysvol directory with a regularly scheduled backup procedure.

See also: Dcgpofix

I configured policies and I am now being denied access.

Cause: This can happen in default Group Policy objects when setting File system security policy on the Sysvol directory or setting excessive security for domain administrator policies.

Solution: Logon as Administrator and use the Dcgpofix command-line tool to restore default domain and domain controller Group Policy objects to their original state.

See also: Dcgpofix


Fast Logon Optimization

The Fast Logon Optimization feature is set by default for both domain and workgroup members. This results in the asynchronous application of policy when the computer starts up and when the user logs on. This application of policy is similar to a background refresh. It can reduce the length of time it takes for the logon dialog box to appear and the length of time it takes for the desktop to become available to the user.

You can change the default setting by using the Group Policy MMC snap-in. This feature is enabled by default, but you can disable it by using the following policy: Administrative Templates\System\Logon\Always wait for the network at computer startup and logon.

Policies are processed according to the criteria listed in the following table.

Default policy process for clients | At startup | At logon | At policy refresh
Windows 2000 | Sync | Sync | Async
Windows Server 2003 family | Sync | Sync | Async
XOX and XOX | Async | Async | Async

Notes

  • Logon Optimization will not be enabled and policies will be processed synchronously when a user is logging on for the first time, the user has a roaming profile, the user has a HomeDir, and the user has a logon script specified in the User object. Folder Redirection and Group Policy Software Installation require a synchronous application of policy. Under these conditions, computer startup can still be asynchronous. However, since logon is synchronous, logon does not exhibit optimization.
  • Client computers running XOX, XOX, and Windows Server 2003 operating systems support Fast Logon Optimization in any domain environment.