Group Policy

You use Group Policy to define settings that are applied to computers or users as they are initialized.

  • Before using Group Policy, see Checklists
    • .
  • To find features that have been moved in Windows 2000, see New ways to do familiar tasks
    • .
  • For tips on 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
    • .


Checklists

This section covers:

  • Checklist: Implementing Group Policy in Active Directory
  • Checklist: Implementing local Group Policy
  • Checklist: Opening the Software Installation snap-in


Checklist: Implementing Group Policy through Active Directory

Step References
Review key concepts about Active Directory and Group Policy.
Group Policy overview;
Active Directory Users and Computers
Install Windows 2000 on the client computers.
Remote Installation Services
Install a Windows 2000 Server domain controller.
To install a domain controller
Determine the Active Directory structure that you want to use.
Best Practices;
Planning site structure;
Planning your domain structure;
Planning your DNS structure
Open Group Policy.
Open the Group Policy snap-in;
Ways to open the Group Policy snap-in


Checklist: Implementing local Group Policy

Step | Reference
Review key concepts about local Group Policy. | Group Policy objects; Local Group Policy
Install Windows 2000 Server or Windows 2000 Professional on the local computer. | Getting Started
Open Group Policy to edit the local Group Policy snap-in. | Open the Group Policy snap-in; Ways to open the Group Policy snap-in


Checklist: Opening the Software Installation snap-in

Step | References
Review key concepts about Software Installation, Group Policy, and Active Directory. | Active Directory Users and Computers; Group Policy overview; Software Installation
Set up Group Policy in your organization. | Checklist: Implementing Group Policy in Active Directory
Open Group Policy to apply to the site, domain, or organizational unit containing the users and computers that should receive the software. | Open Group Policy; Ways to open the Group Policy snap-in
Obtain Windows Installer (.msi) packages for your software. | Contact the software vendor
Open the Software Installation snap-in. | To open the Software Installation snap-in


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 work environment and actions, and to enforce system configuration settings for all computers running Windows NT 4.0. Policies define the various components of the desktop environment, including the applications available to users, the applications that appear on users' desktops, and the options displayed on the Start menu.

Users upgrading from Windows NT 4.0 will find that Group Policy and its extensions provide a unified replacement for many of the tools they are familiar with.

If you want to | In Windows NT 4.0 use | In Windows 2000 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
Use security groups to filter the scope of policy | Not applicable | Edit the permission entry for Apply Group Policy on the security tab of the Group Policy object's properties sheet.
Manage software For an administrator, Systems Management Server. For a user, Add/Remove Programs in Control Panel. Systems Management Server and the three Software Installation and Maintenance tools:
  • Software Installation, an extension to the Group Policy snap-in
  • Windows Installer
  • Add/Remove Programs in Control Panel
Create a safe user interface for editing the registry Windows NT 4.0–style Administrative Templates for System Policy Editor Windows 2000–style Administrative Templates for Group Policy

See The role of Administrative Templates concerning how the use of .adm files has changed in Windows 2000.
Perform general administrative tasks Administrative wizards, User Manager, and Server Manager Microsoft Management Console (MMC) snap-ins, particularly
Active Directory Users and Computers,
Active Directory Sites and Services,
and Group Policy and its extensions.


Best practices

Group Policy

  • Disabling unused parts of a Group Policy object
    If a Group Policy object has, under the User Configuration or Computer Configuration node of the console, only settings that are Not Configured, then you can avoid processing those settings by disabling the node. This expedites startup and logon for those users and computers subject to the Group Policy object. For more information, see To disable the User Configuration settings in a Group Policy object and To disable the Computer Configuration settings in a Group Policy object.
  • Using the Block Policy Inheritance and No Override features sparingly
    Routine use of these feature makes it difficult to troubleshoot policy.
  • Minimizing the number of Group Policy objects associated with users in domains or organizational units
    The more Group Policy objects are applied to a user, the longer it takes to log on.

  • Filtering 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 will not be processed for those users.

    Filtering can only be done using membership in security groups.

    The ACEs appear on the Security tab on the Properties page of a Group Policy object.

  • Overriding user-based Group Policy with computer-based Group Policy only when necessary
    Do this only if you need the desktop configuration to be the same regardless of who logs on.
  • Avoiding cross-domain Group Policy object assignments
    The processing of Group Policy objects will slow logon and startup if Group Policy is obtained from another domain.

Software Installation and management

  • Specifying application categories for your organization
    Using categories makes it easier for users to find an application in Add/Remove Programs in Control Panel. For example, you could define categories such as Sales Applications, Accounting Applications, and so on. For more information, see To specify categories for applications.
  • Making sure Windows Installer packages are correctly transformed before they are published or assigned
    Remember that transforms are applied to packages at the time of assignment or publication. Transforms, or .mst files, are customizations 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 make sure the Modifications tab of the package properties dialog box is set up as you intend before you click OK. If you neglect to do this, and assign or publish a transformed package before you have completely configured it, then you can either remove the software and republish or reassign it or upgrade the software with a completely transformed version. For procedures on how to do this, see To remove a managed application and To upgrade a managed application.
  • Assigning or publishing just once per Group Policy object
    A Windows Installer package should be assigned or published no more than once in the same Group Policy object. For example, if you assign Microsoft Office to the computers affected by a Group Policy object, then do not assign or publish it to users affected by the Group Policy object.
  • Taking advantage of authoring tools
    Developers familiar with the files, registry entries, and other requirements for an application to work properly can author native Windows Installer packages using tools available from various software vendors.
  • Repackaging existing software
    You can use commercially available tools to create Windows Installer packages for software that does not include natively authored .msi files. These work by comparing a computer's state before and after installation. For best results, install onto a computer free of other application software (clean install).
  • Using SMS and Dfs
    Microsoft Systems Management Server (SMS) and the Windows 2000 Distributed File System (Dfs) are helpful in managing the software distribution points (the network shares from which users install their managed software).
  • Assigning or publishing 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 by linking a Group Policy object to a parent organizational unit or domain. Use security descriptors (access control entries or ACEs) on the Group Policy object for finer control over who receives the software. For more information, see Using security groups to filter Group Policy.

    Notes

    • Authenticated Users need the Read and Apply Group Policy ACEs to be able to install from the software distribution point.
    • Administrators need Full Control to manage software.
  • Using Software Installation properties for widely scoped control
    In the Group Policy console, right-click Software Installation and on the context menu click Properties.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
    • This spares administrative keystrokes when assigning or publishing a large number of packages with similar properties in a single Group Policy object—for example, when all the software is published and it all comes from the same software distribution point.
  • Using Windows Installer package properties for fine control
    Proceed to the Software Installation node as described previously, but right-click the package in the details pane and click Properties. Use this for assigning or publishing a single package.

Folder Redirection

  • Enabling client-side caching
    This is especially important for users with laptops.
  • Incorporating %username% into fully qualified universal naming convention (UNC) paths
    This allows users to have their own folders. For example, \\server\share\%username%\My Documents
  • Having My Pictures follow My Documents
    This is advisable unless there is a compelling reason not to, such as file share scalability.
  • Policy removal considerations
    Keep in mind the behavior your Folder Redirection policies will have upon policy removal, as described in Caution.
  • Accepting defaults
    In general, accept the default Folder Redirection settings.


How to...

  • Open the Group Policy snap-in
  • Use Administrative Templates
  • Use scripts
  • Use the Software Installation snap-in
  • Use the Folder Redirection snap-in
  • Configure Group Policy


Open the Group Policy snap-in

  • Open Group Policy from Active Directory Users and Computers
  • Open Group Policy from Active Directory Site and Services
  • Open Group Policy as a stand-alone MMC snap-in

If you're not sure which way you should open Group Policy, see Ways to open the Group Policy snap-in.


Open Group Policy from Active Directory Users and Computers

To open Group Policy 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 you want to set Group Policy for.

    Where?

    • Active Directory Users and Computers [domain_controller_name.domain_name]
    • domain
    • organizational_unit
    • child_organizational_unit...
  3. Click Properties, and then click the Group Policy tab.
  4. Click Edit to open the Group Policy object you want to edit. (Or, click New to create a new Group Policy object, and then click Edit.)

Note

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.


Open Group Policy from Active Directory Sites and Services

To open Group Policy from Active Directory Sites and Services

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

    Where?

    • Active Directory Sites and Services [domain_controller_name.domain_name]
    • Sites folder
    • Site
  3. Click Properties and then click the Group Policy tab.
  4. Click an entry in the Group Policy object links list to select an existing Group Policy object, and then click Edit.

    Or, you can click New to create a new Group Policy object, and then click Edit.

Note

  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.


Open Group Policy as a stand-alone MMC snap-in

To open Group Policy as a stand-alone MMC snap-in

  1. Open Microsoft Management Console.
  2. On the MMC console's menu bar, click Console, and then click Add/Remove Snap-in.
  3. On the Standalone tab, click Add.
  4. In the Add Standalone Snap-in dialog box, click Group Policy, and then click Add.
  5. In the Select Group Policy object dialog box, click Local Computer to edit the local Group Policy object, or browse to find the Group Policy object you want.
  6. Click Finish, and then click OK. The Group Policy snap-in now opens the specified Group Policy object for editing.

Note

  • To open an MMC console, click Start, click Run, type mmc, and then press ENTER.


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
  • Disable a Group Policy object for a site, domain, or organizational unit
  • Prevent a Group Policy object from being overridden


Edit a Group Policy object

To edit a Group Policy object

  1. Open the Group Policy object you want to edit.
  2. Double-click items in the details pane to change their settings.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • You need Read and Write permissions on 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 on disabling a Group Policy object, see Related Topics.

Related Topics


Edit the local Group Policy object

To edit the local Group Policy object

  1. Open Group Policy.
  2. Make whatever policy setting you want in the Group Policy console.

Notes

  • To open Group Policy to edit the local Group Policy object, click Start, click Run, type gpedit.msc, and then press ENTER.
  • See Related Topics for information about local Group Policy.

Related Topics


Create a new Group Policy object

To create a new Group Policy object

  1. Open Active Directory Users and Computers to create a Group Policy object linked to a domain or an organizational unit.

    or

    Open Active Directory Sites and Services to create a Group Policy object linked to a site.

  2. In the console, right-click the site, domain, or organizational unit to which the newly created Group Policy object will be linked. (It will be stored in the current domain.)
  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

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • The newly created Group Policy object is linked by default to the site, domain, or organizational unit that was selected in the Microsoft Management Console when it was created. Therefore its settings apply to that site, domain, or organizational unit. You might want to unlink the Group Policy object from the site, domain, or organizational unit, so that its settings do not apply. For more information, see Related Topics.

Related Topics


Delete a Group Policy object

To delete a Group Policy object

  1. Open Active Directory Users and Computers.

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

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • 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 an organizational unit

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

  1. Open Active Directory Users and Computers to link to a domain or an organizational unit, or Active Directory Sites and Services to link to a site.
  2. In the console, right-click the site, domain, or organizational unit to which the Group Policy object should 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. The Add a Group Policy object Link dialog box appears.
  5. Click the All tab, click the Group Policy object you want, and then click OK.
  6. In the Properties dialog box for the site, domain, or organizational unit, click OK.

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • You link a Group Policy object to specify that its settings should be applied to users and computers in the site, domain, or organizational unit, and to users and computers in Active Directory containers that inherit from the site, domain, or organizational unit.


Block policy inheritance

To block policy inheritance

  1. To block policy inheritance in a site, open Active Directory Sites and Services.

    To block policy inheritance in a domain or organizational unit, open Active Directory Users and Computers.

  2. In the console, 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, make sure the Block Policy inheritance check box is selected, and then click OK.

Notes

  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The Block Policy inheritance setting 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 setting is set only on sites, domains, and organizational units, not on individual Group Policy objects.

Related Topics


Disable a Group Policy object for a site, domain, or organizational unit

To disable a Group Policy object for a site, domain, or organizational unit

  1. Open Active Directory Users and Computers to disable a Group Policy object for a domain or organizational unit.

    or

    Open Active Directory Sites and Services to disable a Group Policy object for a site.
  2. In the console, right-click the site, domain, or organizational unit from which to unlink the Group Policy object (which disables it for that site, domain, or organizational unit).
  3. Click Properties, and then click the Group Policy tab.
  4. Select the Group Policy object you want to disable, and then click Delete. The Delete dialog box appears.
  5. Make sure Remove the link from the list is selected, click OK on the Delete dialog box.

Important

  • If you select Remove the link and delete the Group Policy object permanently, then 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.

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.


Prevent a Group Policy object from being overridden

To prevent a Group Policy object from being overridden

  1. Open Active Directory Users and Computers for a Group Policy object linked to a domain or organizational unit, or open Active Directory Sites and Services for a Group Policy object linked to a site.

  2. In the console, 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. Right-click the Group Policy object link you want to enforce, click No Override on the context menu, and then click OK. (This toggles the No Override state to Active, and a check appears in the No Override column.)

Notes

  • To open Active Directory Users and Computers, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To open Active Directory Sites and Services, click Start, point to Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • Setting No Override on a Group Policy object link results in the enforcement of those Group Policy settings 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 enforced by way of 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


Filter the scope of Group Policy according to security group membership

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

  1. Open the Group Policy object whose scope is to be filtered.
  2. Right-click the root node of the console, which shows a Group Policy icon followed by a label that appears as follows:
    Group_Policy_object_name [domain_controller_name.domain_name] Policy
  3. Click Properties, click the Security tab, and then click the security group through which to filter this Group Policy object.

    If you need to change the list of security groups through which to filter this Group Policy object, you can add or remove security groups using Add and Remove.

  4. Set the permissions as shown in the following table, and then on the property sheet for the Group Policy object, click OK.
Your intention | Set these permissions | Result
Members of this security group should 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 those 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

  • To open the Group Policy snap-in, see Related Topics.
  • Group Policy objects are applied only to sites, domains, and organizational units. Group Policy settings affect only the users and computers they contain. In particular, Group Policy objects are not applied 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, then 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 Software Installation and Folder Redirection extensions use security groups to refine control beyond the Group Policy object level. Except for Folder Redirection and 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

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

  1. Open Group Policy with the Group Policy object of interest at the root node of the console.
  2. Right-click the root node of the console, 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 field.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • If the Group Policy object is linked to more than one domain, then you can limit your search for organizational units to one domain at a time using the Domain drop-down menu.

Related Topics


Disable the User Configuration settings in a Group Policy object

To disable the User Configuration settings in a Group Policy object

  1. Open the Group Policy object you want to edit.
  2. Right-click the console root, which appears as follows:
    Group_Policy_object_name [domain_name] Policy
  3. Click Properties, make sure Disable User Configuration settings is selected, and then click OK.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • The User Configuration settings in this Group Policy object will 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

To disable the Computer Configuration settings in a Group Policy object

  1. Open the Group Policy object you want to edit.
  2. Right-click the console root, which appears as follows:
    Group_Policy_object_name [domain_name] Policy
  3. Click Properties.
  4. Make sure Disable Computer Configuration settings is selected, and then click OK.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • After 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


Add or remove an Administrative Template (.adm file)

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

  1. Open the Group Policy object you want to edit, and then right-click Administrative Templates.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Administrative Templates
  2. Click Add/Remove Templates, and then in the Add/Remove Templates dialog box, click Add.
  3. If you want to remove a template, click it, and then click Remove.

    If you want to add a template, click Add. Click the template you want to add in the Add/Remove Templates dialog box and then click Open.

  4. In the Add/Remove Templates dialog box, click Close.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Because the role of Administrative Templates has changed from Windows NT 4.0 to Windows 2000, it is not recommended to use Windows NT 4.0–style .adm files on Windows 2000 clients.

    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 as follows: in the console tree click the Administrative Templates node, on the console menu bar click View, and then click Show Policies Only to select or clear that menu item. You can also use the Group Policy setting Enforce Show Policies Only to do this:

    Where?

    • Group_Policy_object_name
    • User Configuration
    • Administrative Templates
    • System
    • Group Policy
  • It is also recommended that you use the Disable System Policy (use Group Policy only) setting, which prevents System Policy settings from ever applying to Windows 2000 clients.

    Where?

    • Group_Policy_object_name
    • Computer Configuration
    • Administrative Templates
    • System
    • Group Policy

Related Topics


Use the view provided by Administrative Templates

To use the view provided by Administrative Templates

  1. Open Group Policy and click the folder under Administrative Templates containing the policies you want, such that Policies and Settings for those policies appear in the details pane.

    2. Where?

    • policy_name Policy
    • Computer Configuration (or User Configuration)
    • Administrative Templates
    • policy_folder
  2. Double-click a policy, or right-click and choose Properties, to bring up the property sheet for the policy.
  3. Click the Explain tab to see a description of the policy, if the author of the .adm file has included one.
  4. Click the Policy tab and set the policy using the button shown 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.
  5. Set any additional parameters on the Policy tab and then click Apply.
  6. Use Previous Policy and Next Policy to access other policies in the current folder, and set them in the same way. Click OK when you are finished.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Group Policy can have two Administrative Templates nodes. Settings for HKEY_LOCAL_MACHINE are under Computer Configuration, and settings for HKEY_CURRENT_USER are under User Configuration.
  • If computer policies conflict with user policies, computer policies take precedence in Windows 2000, as they did under Windows NT 4.0 System Policy.

Related Topics


Use 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

To set up scripts on the domain controller

  • Copy the script and dependent files to the Netlogon share, or other share, of the domain controller from which you want the script to run.


Assign computer startup scripts

To assign computer startup scripts

  1. Open the Group Policy snap-in.
  2. In the console tree, click the Scripts node.

    Where?

    • policy_name Policy
    • Computer Configuration
    • Windows Settings
    • Scripts (Startup/Shutdown)
  3. In the details pane, double-click the Startup icon.
  4. In the Startup properties page, click Add.
  5. In the Add a Script dialog box, set the options you want to use, and then click OK:

    Script Name: Type the path to the script, or click Browse to search for the script file in the Netlogon share of the domain controller.

    Script Parameters: Type any parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), you would type the following:
    //logo //I

  6. In the Startup properties page, specify any options you want to use:

    7. Startup Scripts for: Lists all scripts currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed according to the order you specify. To move a script up in the list, click it and then click Up; to move it down, 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: Select to view the script files stored in the selected Group Policy object.

Note

  • To open the Group Policy snap-in, see Related Topics.
  • Startup scripts are run as Local System.

Related Topics


Assign computer shutdown scripts

To assign computer shutdown scripts

  1. Open the Group Policy snap-in.
  2. In the console tree, click the Scripts node.

    Where?

    • policy_name Policy
    • Computer Configuration
    • Windows Settings
    • Scripts (Startup/Shutdown)
  3. In the details pane, double-click the Shutdown icon.
  4. In the Shutdown properties page, click Add.
  5. In the Add a Script dialog box, set the options you want to use, and then click OK:

    Script Name: Type the path to the script, or click Browse to search for the script file in the Netlogon share of the domain controller.

    Script Parameters: Type any parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), you would type the following:
    //logo //I

  6. In the Shutdown properties page, specify any options you want to use:

    Shutdown Scripts for: Lists all scripts currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed according to the order you specify. To move a script up in the list, click it and then click Up; to move it down, 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: Select to view the script files stored in the selected Group Policy object.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Shutdown scripts are run as Local System.

Related Topics


Assign user logon scripts

To assign user logon scripts

  1. Open the Group Policy snap-in.
  2. In the console tree, click the Scripts node.

    Where?

    • policy_name Policy
    • User Configuration
    • Windows Settings
    • Scripts (Logon/Logoff)
  3. In the details pane, double-click the Logon icon.
  4. In the Logon properties page, click Add.
  5. In the Add a Script dialog box, set the options you want to use, and then click OK:

    Script Name: Type the path to the script, or click Browse to search for the script file in the Netlogon share of the domain controller.

    Script Parameters: Type any parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), you would type the following:
    //logo //I

  6. In the Logon properties page, specify any options you want to use:

    7. Logon Scripts for: Lists all scripts currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed according to the order you specify. To move a script up in the list, click it and then click Up; to move it down, 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: Select to view the script files stored in the selected Group Policy object.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Logon scripts are run as User, not Administrator.

Related Topics


Assign user logoff scripts

To assign user logoff scripts

  1. Open the Group Policy snap-in.
  2. In the console tree, click the Scripts node.

    Where?

    • policy_name Policy
    • User Configuration
    • Windows Settings
    • Scripts (Logon/Logoff)
  3. In the details pane, double-click the Logoff icon.
  4. In the Logoff dialog box, click Add.
  5. In the Add a Script dialog box, set the options you want to use, and then click OK:

    Script Name: Type the path to the script, or click Browse to search for the script file in the Netlogon share of the domain controller.

    Script Parameters: Type any parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), you would type the following:
    //logo //I

  6. In the Logoff properties page, specify any options you want to use and then click OK:

    7. Logoff Scripts for: Lists all scripts currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed according to the order you specify. To move a script up in the list, click it and then click Up; to move it down, 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: Select to view the script files stored in the selected Group Policy object.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Logoff scripts are run as User, not Administrator.

Related Topics


Use the Software Installation snap-in

  • Open the Software Installation snap-in
  • Set options for Software Installation
  • Work with applications
  • Set application properties
  • Work with package modifications


Open the Software Installation snap-in

To open the Software Installation snap-in

  1. Open Group Policy from Active Directory Users and Computers, from Active Directory Sites and Services, or as a stand-alone Microsoft Management Console snap-in.
  2. To assign software to computers, double-click Computer Configuration. To assign or publish software to users, double-click User Configuration.
  3. Double-click Software Settings.
  4. In the console tree, click Software Installation.

    Where?

    • policy_name Policy
    • [Computer | User] Configuration
    • Software Settings
    • Software Installation

Note

  • To open the Group Policy snap-in, see Related Topics.

Related Topics


Set options for Software Installation

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


Set Software Installation defaults

To set Software Installation defaults

  1. Open the Software Installation snap-in.
  2. Right-click the Software Installation node, and then click Properties.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  3. Click the General tab and then select the settings you want:

    Default Package Location: Specify the default software distribution point.

    New packages. Packages can either be published or assigned by default (to computers, only assigned). If you want to make these decisions for each package, select Display the Deploy Software dialog box. For finer control on a per-package basis, select Advanced assign or publish.

    Installation user interface options: Click Basic or Maximum, depending on how apparent you want the installation process to be to the users.

    Uninstall the applications when this Group Policy object no longer applies to Users or Computers: Use this option if you want software to be removed at logon (for users) or startup (for computers) if the user or computer moves to a site, domain, or organizational unit for which the software is not managed.

Note

  • To open the Software Installation snap-in, see Related Topics.

Related Topics


Specify automatic installation options based on file name extension

To specify automatic installation options based on file name extension

  1. Open the Software Installation snap-in, and then in the console right-click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. Click Properties, and then click the File Extensions tab.
  3. On the File Extensions property sheet, specify the options you want to use, and then click OK:

    4. 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 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 97, Microsoft Internet Explorer 5, Netscape Communicator 5.0, and so on.

    Application precedence: Lists all the applications associated with the selected extension. The application with the highest precedence by default is listed at the top of the list.

    Up: Moves the selected application higher in the priority 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. This option is unavailable when the selected application is at the top of the list.

    Down: Moves the selected application lower in the priority list. This option is unavailable when the selected application is at the bottom of the list.

Notes

  • To open the Software Installation snap-in, see Related Topics.
  • When you upgrade an application, make sure to turn off the autoinstall option for the older version.

Related Topics


Specify categories for applications to be managed

To specify categories for applications to be managed

  1. Open the Software Installation snap-in.
  2. Right-click the Software Installation node, and then click Properties.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  3. Click the Categories tab.
  4. Create or change the list of categories under which programs appear in Add/Remove Programs in Control Panel, using the available buttons:

    5. Add: Opens a dialog box where you can type text to define the new category. The option is unavailable if you do not have permission to add categories.

    Modify: Opens a dialog box where you can change the text of the selected category. The option is unavailable if you do not have permission to edit categories.

    Remove: Removes the selected category from the Categories list.

Notes

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

Related Topics


Work with applications

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


Assign an application

To assign an application

  1. Open the Software Installation snap-in, and in the console click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. Right-click the details pane, click New, and then click Package.
  3. In the Open dialog box, click the Windows Installer package to be assigned, and then click Open. (The Open dialog box shows those packages located at the software distribution point 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 network share, click Browse to find the software distribution point for the package.

  4. In the Deploy Software dialog box, click Assigned, and then click OK.

Related Topics


Publish an application

To publish an application

  1. Open the Software Installation snap-in, and in the console click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • User Configuration
    • Software Settings
    • Software Installation
  2. Right-click the details pane, click New, and then click Package.
  3. In the Open dialog box, click the Windows Installer package to be published, and then click Open. (The Open dialog box shows those packages located at a software distribution point 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 network share, click Browse to find the software distribution point for this package.

  4. In the Deploy Software dialog box, click Published, and then click OK.

    The application is available for users to install either by using Add/Remove Programs in Control Panel, or by opening a file with a file name extension that you have associated with the application. For information on how to associate an extension with an application, see Related Topics.

Notes

  • To open the Software Installation snap-in, see Related Topics.
  • Packages can be published only to users, not to computers.

Related Topics


Upgrade applications

To upgrade applications

  1. Open the Software Installation snap-in and click the Software Installation node.

    Where?

    • group_policy_object name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. In the details pane, right-click the Windows Installer package that will function as the upgrade (not the package to be upgraded). You will have previously assigned or published this package.
  3. Click Properties and then click the Upgrades tab.
  4. Click Add to create or add to the list of packages that are to be upgraded by the current package.
  5. In the Add Upgrade Package dialog box, specify either Current Group Policy object or A specific GPO as the source of the package to be upgraded. In the latter case, click Browse, click the Group Policy object you want, and then, in the Browse for a Group Policy object dialog box, click OK.

    A list of all the other packages assigned or published within the selected Group Policy object appears under the heading Package to upgrade. Depending on the Group Policy object, this list may have zero or more entries.

  6. Click the package to upgrade.
  7. Click either Uninstall the existing package, then install the upgrade package or Package can upgrade over the existing package. Typically the uninstall option is for replacing an application with a completely different one (perhaps from a different vendor). The upgrade option is for installing a newer version of the same product while retaining the user's application preferences, document type associations, and so on.
  8. Enable the check box for Required upgrade for existing packages if you want the upgrade to be mandatory, and then click OK.

    If this is an upgrade under the Computer Configuration node of the Group Policy console, the check box appears dimmed and selected, because packages can only be assigned to computers, not published.

Note

  • To open the Software Installation snap-in, see Related Topics.

Related Topics


Remove a managed application

To remove a managed application

  1. Open the Software Installation snap-in, and in the console click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. In the details pane, right-click the application you want to remove.
  3. Click All Tasks, and then click Remove.
  4. In the Remove Software dialog box, select one of the following removal options, and then click OK:

    Immediately uninstall software from users and computers: Select this option to specify that the application is removed the next time a user logs on or restarts the computer.

    Allow users to continue to use the software but prevent new installations: Select this option to specify that users can continue to use the application if they have already installed it. If they remove the application or have never installed it, they will not be able to install it.

Note

  • To open the Software Installation snap-in, see Related Topics.

Related Topics


Set application properties

  • View properties for managed applications
  • Edit Software Installation options for applications
  • Specify categories for Add/Remove Programs in Control Panel
  • Set autoinstall for an application
  • Set permissions for installing software


View properties for managed applications

To view properties for managed applications

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

Note

  • To open the Software Installation snap-in, see Related Topics.

Related Topics


Edit installation options for applications

To edit installation options for applications

  1. Open the Software Installation snap-in, and in the console click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. In the details pane, right-click the application for which you want to set installation options, and then click Properties.
  3. On the application's Properties sheet, click Deployment.
  4. On the Deployment property sheet, click one of the following deployment types in the Deployment type box:

    Published: Users in the selected site, domain, or organizational unit can install the application using either Add/Remove Programs in Control Panel, or by file activation.

    Assigned: Users in the selected site, domain, or organizational unit receive this application the next time they log on (for assignment to users) or when the computer restarts (for assignment to computers).

  5. In the Deployment options frame, select among these options:

    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 determined on the File Extensions tab of the Software Installation Properties dialog box.

    If the software is not already installed, selecting this option causes it to be installed when the user opens a file with this file association; for example, by double-clicking it.

    Uninstall this application when this Group Policy object no longer applies to users or computers: Select this option if you want the application to be removed at logon (for users) or startup (for computers) if they move to a site, domain, or organizational unit for which the application is not deployed.

    Do not display this package in Add/Remove Programs in Control Panel: This option removes the most obvious way for users to uninstall the program. This may be useful from time to time during the software life cycle.

  6. In Installation user interface options, click one of the following options:

    Basic: Only progress bars and errors are displayed.

    Maximum: The entire user interface supported by the package is displayed.

  7. If you want to set advanced options, click Advanced:

    Ignore language when deploying this package: Use this option if you are installing an application whose locale differs from that of the operating system.

    Remove previous installs of this product from computers, if the product was not installed by Group Policy–based Software Installation: This may be useful if, for example, company policy is to not allow users to install from their own compact discs.

Notes

  • To open the Software Installation snap-in, see Related Topics.
  • The Advanced Deployment Options form that appears when you click Advanced provides the following advanced diagnostic information, which can be useful for troubleshooting.
    Field | Data
    Product code | Globally unique identifier (GUID) representing the product
    Deployment count | 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/Remove Programs in Control Panel

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

  1. Open the Software Installation snap-in.
  2. In the details pane, double-click the managed application you want to set categories for, and then, on the application's property sheet, click Categories.
  3. On the Categories property sheet, set the following options you want to use, and then click OK:

    4. Available categories: Lists the application categories that have been defined for your organization.

    Select: Associates the selected application category with the application. To use this option, select a category from the Available categories list and then click Select.

    Remove: Removes a category from the Selected categories list. To use this option, select a category from the Selected categories list, and then click Remove.

    Selected categories: Displays the categories that are associated with this application.

Notes

  • To open the Software Installation snap-in, see Related Topics.
  • The categories you set in this dialog box generally pertain to published applications only, because assigned applications do not appear in Add/Remove Programs in Control Panel. The application appears in the selected categories in Add/Remove Programs, which the user can use to install the application.
  • This procedure is not used to create or destroy 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

To set the autoinstall option for an application

  1. Open the Software Installation snap-in and then, in the console, click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • User Configuration
    • Software Settings
    • Software Installation
  2. In the details pane, right-click the application you want to be installed automatically.
  3. Click Properties, and then click the Deployment tab.
  4. Under Deployment options, make sure Auto-install this application by file extension activation is selected, and then click OK.

Notes

  • To open the Software Installation snap-in, see Related Topics.
  • When you upgrade an application, make sure to turn off the autoinstall option for the older version.

Related Topics


Set permissions for software installation

To set permissions for software installation

  1. Open the Group Policy object you want to edit.
  2. Right-click the console root, where you see a name that appears as follows:
    Group_Policy_object_name [domain_name] Policy
  3. Click Properties, and then click the Security tab.
  4. Click the security group on which to set permissions.

    You can add or remove security groups using the buttons provided if you need to change the set of security groups with permissions on this Group Policy object.

  5. If the security group represents administrators (who manage software for users and computers in the organization), set Full Control to Allow.

    If the security group represents users (who use software assigned or published by an administrator), set both Apply Group Policy and Read to Allow.

  6. On the Group Policy object property sheet, click OK.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • The permissions that are 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 instructions on setting permissions on a shared folder, see Related Topics.

Related Topics


Work with package modifications

Modifications (.mst files) are applied to Windows Installer packages (which have the .msi extension) in an order specified by the administrator. This order must be determined before the application is assigned or published.

Modifications are also called transforms.

For information on working with package modifications, see To add or remove modifications for an application package.


Add or remove modifications for an application package

To add or remove modifications for an application package

  1. Open the Software Installation snap-in, and in the console, click the Software Installation node.

    Where?

    • Group_Policy_object_name
    • Computer Configuration (or User Configuration)
    • Software Settings
    • Software Installation
  2. In the details pane, right-click, click New, and then click Package.
  3. In the Open dialog box, click the Windows Installer package, and then click Open.
  4. In the Deploy Software dialog box, click Advanced assign or publish, and then click OK.
  5. In the package's property sheet, click Modifications.
  6. If you want to add modifications, in the Modifications dialog box, click Add. In the Open dialog box, browse to the transform file (.mst), and then click Open.
  7. If you want to remove modifications, in the Modifications dialog box, click the modification you want to remove, and then click Remove. Repeat until each unwanted modification has been removed.
  8. Make sure the modifications are configured exactly the way you want them, and then click OK.

Warning

  • 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

  • To open the Software Installation snap-in, see Related Topics.
  • You can add multiple modifications (transforms). The transforms are applied according to the order you specify in the Modifications list, from top to bottom. To rearrange the list, select a transform from the list and then click Move Up or Move Down.

Related Topics


Use the Folder Redirection snap-in

  • Redirect to one location for everyone in the site, domain, or organizational unit
  • Redirect to different locations according to security group membership


Redirect special folders to one location for everyone in the site, domain, or organizational unit

To redirect special folders to one location for everyone in the site, domain, or organizational unit

  1. Open a Group Policy object linked to the site, domain, or organizational unit containing the users whose special folders you want to redirect to a network location.
  2. In the console tree, double-click the Folder Redirection node to show the special folder you want to redirect.

    Where?

    • policy_name Policy
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the special folder you want (such as Desktop, My Documents, and so on), and on the context menu click Properties.
  4. On the Setting drop-down menu, click Basic, click Browse, and then browse to the location you want.

    If you enter a drive letter, such as D:\, then this must represent a valid path on the user's local computer. It is recommended that you enter a full universal naming convention (UNC) path.

    If you want each user in the site, domain, or organizational unit to have his or her own subfolder at this location, then you can incorporate %username% into the UNC path, such as \\Win2000profiles\docs\%username%. Including %username% in the path is recommended.

  5. In the Browse for Folder dialog box, click OK.
  6. Click the Settings tab, and then set each of the following options. The defaults are recommended:

    Grant the user exclusive rights to the special folder: Enabled by default. The user and the local system have full rights to the folder, and no one else, not even administrators, has any rights. If this setting is disabled, no changes are made to the permissions on the folder. The permissions that apply by default remain in effect.

    Move the contents of the user's current special folder to the new location: Enabled by default.

  7. Choose one of the following two options for policy removal. The default setting is recommended:

    Leave the files in the new location when policy is removed.

    Redirect the folder back to the local user profile location when the policy is removed.

  8. On the special folder Properties dialog box, click OK.

    9. Caution

    • If the redirection policy specifies that the folder be redirected back to the local user profile location upon policy removal, but does not specify that the contents be moved during redirection, then the contents of the special folder that were visible to the user while the policy was in effect are no longer visible to the user upon policy removal. The user's files remain at the location that was specified when the policy was in effect. See Policy removal considerations for details.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Special folders are those located in Documents and Settings under the root directory.
  • The My Pictures special folder offers one further option. The default behavior, which is recommended, is for My Pictures to follow My Documents automatically. This can be changed by clicking the Setting drop-down list on My Pictures Properties, or the Settings tab of My Documents Properties.

Related Topics


Redirect special folders to different locations according to security group membership

To redirect special folders to different locations according to security group membership

  1. Open a Group Policy object linked to the site, domain, or organizational unit containing the users whose special folders you want to redirect to a network location.
  2. In the console tree, double-click the Folder Redirection node to show the folder you want to redirect.

    Where?

    • policy_name Policy
    • User Configuration
    • Windows Settings
    • Folder Redirection
  3. Right-click the folder you want (such as Desktop, My Documents, and so on) and on the context menu click Properties.
  4. On the Setting drop-down menu, click Advanced, and then click Add.
  5. In the Specify Group and Location dialog box, under Security Group Membership click Browse.
  6. In the Select Group dialog box, click the security group you want and then click OK.
  7. In the Specify Group and Location dialog box, under Target Folder Location, click Browse.
  8. On the Browse for Folder dialog box, select the redirect location you want for this security group.

    If you enter a drive letter, such as D:\, then this must represent a valid path on the user's local computer. It is recommended that you enter a full universal naming convention (UNC) path.

    If you want each user in the site, domain, or organizational unit to have his or her own subfolder at this location, then you can incorporate %username% into the UNC path, such as \\Win2000profiles\docs\%username%. Including %username% in the path is recommended.

  9. In the Specify Group and Location dialog box, click OK.
  10. If you want to redirect folders for members of other security groups, repeat steps 2 through 9 until all the groups have been entered.
  11. Click the Settings tab, and then set each of the following options. The defaults are recommended:

    Grant the user exclusive rights to the special folder: Enabled by default. The user and the local system have full rights to the folder, and no one else, not even administrators, has any rights. If this setting is disabled, no changes are made to the permissions on the folder. The permissions that apply by default remain in effect.

    Move the contents of the user's current special folder to the new location: Enabled by default.

  12. Choose one of the following two options for policy removal. The default setting is recommended:

    Leave the files in the new location when policy is removed.

    Redirect the folder back to the local user profile location when the policy is removed.

  13. On the special folder Properties dialog box, click OK.

    14. Caution

    • If the redirection policy specifies that the folder be redirected back to the local user profile location upon policy removal, but does not specify that the contents be moved during redirection, then the contents of the special folder that were visible to the user while the policy was in effect are no longer be visible to the user upon policy removal. The user's files remain at the location that was specified when the policy was in effect. See Policy removal considerations for details.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Special folders are those located in Documents and Settings under the root directory.
  • The My Pictures folder offers one further option. The default behavior, which is recommended, is for My Pictures to follow My Documents automatically. This can be changed by clicking the Setting drop-down list on My Pictures Properties, or the Settings tab of My Documents Properties.

Related Topics


Configure Group Policy

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


Extend the functionality of Group Policy

To extend the functionality of Group Policy

  1. Open Group Policy as a stand-alone MMC snap-in.
  2. On the Console menu, click Add/Remove snap-in.
  3. Click the Extensions tab, select the snap-in extensions you want, and then click OK.

Note

  • To open the Group Policy snap-in, see Related Topics.

Related Topics


Refresh Group Policy immediately

To refresh Group Policy immediately

  1. Click Start and then click Run to open the Run dialog box.

  2. To refresh policies under the Computer Configuration node, type the following and then click OK:
    secedit /refreshpolicy MACHINE_POLICY

    To refresh policies under the User Configuration node, type the following and then click OK:
    secedit /refreshpolicy USER_POLICY


Set permissions for managing Group Policy

To set permissions for managing Group Policy

  1. Open Group Policy.
  2. In the Group Policy console root, right-click the Group Policy object for which you want to set permissions, click Properties, and then click Security.
  3. In the Properties dialog box, set the options you want to use, and then click OK:

    4. Add: Opens the Add Users and Groups dialog box, where you can specify the users and groups for whom to assign permissions.

    Remove: Removes users or groups and their associated permissions from this object.

    Permissions: 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.

    Allow inheritable permissions from parent to propagate to this object: Specifies whether or not security permissions for this object are affected by inheritance.

Note

  • To open the Group Policy snap-in, see Related Topics.

Related Topics


Set Group Policy refresh rate for computers

To set Group Policy refresh rate for computers

  1. Open Group Policy with System.adm installed under Computer Configuration\Administrative Templates. (Because System.adm is installed by default, you should not need to take any action.)
  2. Open the Computer Configuration\Administrative Templates\System\Group Policy folder to reveal several policies, including Group Policy refresh interval for computers.

    Where?

    • policy_name policy
    • Computer Configuration
    • Administrative Templates
    • System
    • Group Policy
  3. In the details pane, double-click the Group Policy refresh interval for computers icon.
  4. Click the Policy tab and make sure the check box is selected and does not appear dimmed.
  5. Use the drop-down lists to select the refresh interval and random offset, and then click OK.
  6. Double-click the icon for Disable background refresh of Group Policy. Make sure that policy is Disabled by clearing the check box, and then click OK.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Client computers request policy from a domain controller when any of these events occur:
    • Computer startup
    • User logon
    • An application requests a refresh by way of the RefreshPolicy() API.
    • The user requests an immediate refresh.
    • One of the Group Policy refresh interval policies is enabled, and the interval has transpired, as described previously.

    Policy is not imposed by the domain controller; it is requested by the client computer.

  • The minimum setting of Group Policy Refresh Interval (zero minutes) actually takes about seven seconds between requests for a refresh. Very short settings should not be used in a production environment, except only briefly for testing.
    The Software Installation and Folder Redirection extensions to Group Policy ignore policy refreshes.

Related Topics


Set other policies for Group Policy

  1. Open Group Policy with System.adm installed. (Because System.adm is installed by default, you generally do not need to take any action.)
  2. If you want to edit a user policy, in the console tree, click the Group Policy node for user policies.

    3. Where?

    • policy_name Policy
    • User Configuration
    • Administrative Templates
    • System
    • Group Policy
  3. If you want to edit a computer policy, in the console tree, click the Group Policy node for computer policies.

    4. Where?

    • policy_name Policy
    • Computer Configuration
    • Administrative Templates
    • System
    • Group Policy
  4. Double-click the icon for the policy you want to set.
  5. On the Policy tab, make the setting you want, and then click OK.

Notes

  • To open the Group Policy snap-in, see Related Topics.
  • Descriptions of the policies for Group Policy are provided on the Explain tab if the author of the .adm file has included them. Also, see Related Topics for descriptions of the policies.

Related Topics


Concepts

This section consists of general background information about Group Policy.

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


Group Policy overview

To begin using Group Policy immediately, see Ways to open the Group Policy snap-in.

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 Start menu options. To create a specific desktop configuration for a particular group of users, you use the Group Policy snap-in. Group Policy settings 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 includes settings for User Configuration, which affect users, and Computer Configuration, which affect computers.

Using Group Policy and its extensions, you can:

  • Manage registry-based policy through 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).
  • Assign scripts (such as computer startup and shutdown, and logon and logoff).
  • Redirect folders from the Documents and Settings folder on the local computer to network locations.
  • Manage applications (assign, publish, update, or repair). To do this, you use the Software Installation extension.
  • Specify security options. To learn about setting security options, see the Security Settings online Help.

How and when Group Policy is applied

User and computer policy

User policy (settings located under the User Configuration node in Group Policy) is obtained when a user logs on.

Computer policy settings are located under Computer Configuration, and are obtained when a computer boots.

Users and Computers are the only types of Active Directory objects that receive policy. Specifically, security groups do not have policy applied to them. Instead, for performance reasons, security groups are used to filter the policy by way of an Apply Group Policy access control entry (ACE), which can be set to Allow or Deny, or left unconfigured.

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.

By default, policies applied later overwrite previously applied policies when the policies are inconsistent. If the settings are not inconsistent, however, earlier and later policies both contribute to the effective policy.

Policy can be filtered 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.

Blocking policy inheritance

Policies that would otherwise be inherited from higher site, domain, or organizational units can be blocked at the site, domain, or organizational unit level.

Enforcing policy from above

Policies that would otherwise be overwritten by policies in child organizational units can be set to No Override at the Group Policy object level.

Note

  • Policies set to No Override cannot be blocked.

This section covers:

  • User Configuration
  • Computer Configuration
  • Security Settings
  • Administrative Templates
  • Software Settings
  • Windows Settings
  • Software Installation
  • Folder Redirection


User Configuration

You use the User Configuration node in Group Policy to set policies applying to users, regardless of which computer they log on to.

User Configuration typically contains subnodes for Software Settings, Windows Settings, and Administrative Templates, but because Group Policy can have snap-in extensions added to or removed from it, the exact set of subnodes you see may be different.

See also:

  • Computer Configuration
  • Administrative Templates
  • Software Settings
  • Windows Settings
  • Assign user logon scripts
  • Assign user logoff scripts
  • Disable the User Configuration Settings in a Group Policy object


Computer Configuration

Administrators use the Computer Configuration node in Group Policy to set policies that are applied to computers, regardless of who logs onto them.

Computer Configuration typically contains the subnodes Software Settings, Windows Settings, and Administrative Templates. However, because Group Policy can have extensions added to or removed from it, the exact set of subnodes you see may be different.

See also:

  • User Configuration
  • Administrative Templates
  • Software Settings
  • Windows Settings
  • Disable the Computer Configuration Settings in a Group Policy object
  • Assign computer startup scripts
  • Assign computer shutdown scripts


Security settings

Group Policy has two Security Settings nodes. \Computer Configuration\Windows Settings\Security Settings is for security settings applying to all users who log on to the computer. This node has two subnodes: IP Security Policies on Active Directory, and Public Key Policies.

\User Configuration\Windows Settings\Security Settings is for security settings applying to users regardless of which computer they log on to. This node has a Public Key Policies subnode.

For more information on using these nodes, see Security settings.


Administrative Templates

The Group Policy Administrative Templates node contains all registry-based policy information. User configurations are saved in HKEY_CURRENT_USER (HKCU), and computer configurations are saved in HKEY_LOCAL_MACHINE (HKLM). The software policy settings include Group Policy for programs as well as for the Windows 2000 operating system and its components.

The namespace under the Administrative Templates node is populated by using .adm files or by an extension to Group Policy. When you use this node for the first time, the .adm files are automatically installed.

If you plan to create entries for the Administrative Templates node, you should populate the namespace 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 2000 are in \Microsoft\Windows 2000.

The user interface that is displayed under the Administrative Templates nodes is populated by using .adm files. For this purpose, Windows 2000 is shipped with several .adm files. For a description of these files, see .adm files included with Windows 2000.

For information on adding an .adm file, see To add or remove an Administrative Template (.adm file).

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) to be applied to the computer or user portion of the registry. One of the Registry.pol files contains the registry settings to be applied to the HKEY_LOCAL_MACHINE registry key; it is stored in the GPT\Machine folder. The other Registry.pol file contains registry settings specific to the HKEY_CURRENT_USER key; it is stored in the GPT\User subdirectory.

See also:

  • Use the view provided by Administrative Templates
  • The role of Administrative Templates
  • Advanced topic: Creating custom .adm files


Software settings

Group Policy has two Software Settings nodes.

\Computer Configuration\Software Settings\ is for software settings applying to all users who log on to the computer. This node has a Software Installation subnode, and possibly other subnodes placed there by Independent Software Vendors.

\User Configuration\Software Settings is for software settings that applying to users regardless of which computer they log on to. This node has a Software Installation subnode, and possibly other subnodes placed there by Independent Software Vendors.

See also:

  • Software Installation
  • User Configuration
  • Computer Configuration


Windows settings

Group Policy has two Windows Settings nodes.

\Computer Configuration\Windows Settings is for windows settings that apply to all users who log on to the computer. This node has two subnodes: Security Settings and Scripts.

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

See also:

  • User Configuration
  • Computer Configuration
  • Security Settings
  • Scripts
  • Folder Redirection


Software Installation

Software Installation helps you specify how applications are installed and maintained within your organization.

You manage an application within a Group Policy object, which is in turn associated with a particular Active Directory container—either a site, domain, or organizational unit. Applications can be managed in one of two modes: assigned or published.

You assign an application when you want everyone to have the application on his or her computer. For example, suppose 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 Microsoft Excel within the marketing Group Policy object, Microsoft 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 Microsoft Excel to make the Microsoft Excel shortcuts appear on the Start menu and the necessary file associations (.xls) appear in the registry.

When these users log on to their computers, Microsoft Excel appears on their Start menu. When they select Microsoft Excel from the Start menu for the first time, Microsoft Excel is installed. A user can also install an advertised application by opening a document associated with the application (either by file name extension or by COM-based activation). If a user who has not yet activated Microsoft Excel from the Start menu clicks a Microsoft Excel spreadsheet to open it, then Microsoft Excel is installed 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 will be installed the next time a user selects it from the Start menu.

You publish an application when you want the application to be available to people managed by the Group Policy object, should a user want 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 managed by the marketing Group Policy object and a marketing user wants to install Image Composer, the user can use Add/Remove Programs in Control Panel, click Image Composer from the list of published applications, and then install it. If users do not install Image Composer using Add/Remove Programs in Control Panel, and if the .jpg file name extension for the image document is associated with Image Composer, then Image Composer can be installed for users when they first open any .jpg document.

See also:

  • Use the Software Installation Snap-in
  • Understanding Software Installation


Folder Redirection

You use the Folder Redirection extension to Group Policy to redirect certain Windows 2000 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 Group Policy console.

Where?

  • policy_name Policy
  • User Configuration
  • Windows Settings
  • Folder Redirection

To individualize a user's redirected folder, it is recommended to incorporate %username% into the path; for example,
\\server\share\%username%\My Documents

In addition, you can either redirect a special folder to the same network share for everyone (as described in To redirect special folders to one location for everyone in the site, domain, or organizational unit) or you can refine the redirection beyond the Group Policy object level. For example, members of the Users security group could have My Documents redirected to
\\server1\share\%username%\My Documents, while members of the Guests security group could have My Documents redirected to
\\server2\share\%username%\My Documents. For more information, see To redirect special folders to different locations according to security group membership.

Windows 2000 allows the following folders to be redirected:

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 Group Policy console.
Desktop |
My Documents | See Advantages of redirecting My Documents for details.
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 file share scalability) for separating My Pictures from My Documents. If they 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.

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.

  • 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. For more information, see To make a file or folder available offline. This is particularly useful for those who use laptop computers.
  • 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 itself. 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.
  • Data stored on a shared network server can be backed up as part of routine system administration. This is safer, because it requires no action on the part of the user.
  • The system administrator can use Group Policy to set disk quotas, limiting the amount of space taken up by users' special folders.
  • Data specific to a user can be redirected to a different hard disk on the user's local computer from the hard disk holding the operating system files. This makes the user's data safer if the operating system needs to be reinstalled.

For more information, see Best practices for Folder Redirection.

Default folder locations

The default locations for special folders that have not been redirected depend on the operating system that was in place previously:

Operating system | Location of special folders
Windows 2000 new installation (no previous operating system) | %systemdrive%\Documents and Settings; for example, C:\Documents and Settings
Windows 2000 upgrade of Windows NT 4.0 or Windows NT 3.51 | %systemroot%\Profiles; for example, C:\WinNT\Profiles
Windows 2000 upgrade of Windows 95 or Windows 98 with user profiles disabled | %systemdrive%\Documents and Settings; for example, C:\Documents and Settings
Windows 2000 upgrade of Windows 95 or Windows 98 with user profiles enabled | %systemroot%\Profiles; for example, C:\Windows\System\Profiles

For more information on user profiles, see User profiles.

Policy removal considerations

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

Move the contents of 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 can no longer 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.


Understanding Group Policy

This section covers:

  • Group Policy objects
  • Policy inheritance
  • Storage of Group Policy objects
  • Group Policy precedence
  • Understanding Software Installation


Group Policy objects

Policy settings are stored in Group Policy objects. The Group Policy snap-in 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.

Local and nonlocal Group Policy objects

There are two kinds of Group Policy objects. 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.

Local Group Policy objects are stored on each computer running Windows 2000. Only one local Group Policy object exists on a computer, and it has a subset of the settings 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 apply.


Policy inheritance

In general, Group Policy is passed down from parent to child containers. If you have assigned a specific Group Policy to a high-level parent container, that Group Policy 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 organization unit doesn't inherit them. Policy settings that are disabled are inherited as disabled. Also, if a policy is configured for a parent organizational unit, and the same policy is not configured for a child organizational unit, the child inherits the parent's policy setting.

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

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

Blocking inheritance

You can block inheritance of policies at the site, domain, or organizational unit level using the Block Inheritance check box. If this option is selected for a child-level Group Policy object, the child does not inherit any policy from a parent-level Group Policy object.

Enforcing inheritance

The No Override check box forces all child policy containers to inherit the parent's policy even if those policies conflict with the child's policies, and even if Block Inheritance has been set for the child.


Storage of Group Policy objects

Each computer running Windows 2000 has exactly one local Group Policy object. It is stored in %systemroot%System32\GroupPolicy.

Group Policy objects other than the local Group Policy object consist of two parts, stored separately: the Group Policy container and the Group Policy template. Information that is small and infrequently changed resides in the Group Policy template, while information that is large or frequently changed is kept in the Group Policy container. The Group Policy user interface does not expose them separately.

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. This is used to make sure the information is synchronized with Group Policy template information.
  • Status information. This indicates whether the Group Policy object is enabled or disabled for this site, domain, or organizational unit.
  • List of components. This specifies which extensions to Group Policy have settings in the Group Policy object.

The Group Policy container stores information for the Software Installation snap-in and the Folder Redirection snap-in, two extensions of Group Policy.

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 this 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 of 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 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 the following subfolders:
  • User\Applications. Contains the .aas files (application advertisement scripts) used by the operating system–based installation service. These are applied to users.
  • Machine. Includes a Registry.pol file that contains the registry settings 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 the following subfolders:
  • Machine\Applications. Contains the .aas files used by the operating system–based installation service. These are applied to computers.


Group Policy precedence

In Windows 2000, Group Policy is applied to Group Policy objects that are in turn associated with Active Directory objects (sites, domains, or organizational units). Group Policy can be applied to either users or computers. It is important to 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 be applied to computers.

Group Policy is applied hierarchically from the least restrictive group (site) to the most restrictive group (organizational unit). Group Policy is also cumulative. Child directory service containers inherit Group Policy from parent containers, and Group Policy processing occurs in the following order: site, domain, and organizational unit. This means that if you have assigned a specific Group Policy to a high-level parent container, that Group Policy 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 for a child container, the child container's Group Policy overrides the parent container's Group Policy.

Optionally, you can enforce Group Policy on child directory containers by setting No Override on the Group Policy object. You can also prevent inheritance of Group Policy from parent directory containers.

Group Policies take precedence over profile settings in the event of a conflict.

This section covers:

  • Order of events in startup and logon
  • Order of processing settings
  • The role of applications in Group Policy precedence


Order of events in startup and logon

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) are started.
  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 Windows 2000 domain, and is therefore subject to Group Policy through Active Directory.
    • The location of the computer in Active Directory.
    • If the list of Group Policy objects has not changed, then 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 occurs synchronously by default, and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface is displayed while computer policies are being processed.

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

  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 timeout 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 is loaded, governed by the policy settings 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 Windows 2000 domain, and is therefore subject to Group Policy through Active Directory.
    • Whether loopback is enabled, and the state (Merge or Replace) of the loopback policy setting.
    • The location of the user in Active Directory.
    • If the list of Group Policy objects to be applied has not changed, then 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 occurs synchronously by default, and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface is displayed while user policies are being processed.

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

  9. Logon scripts run. Unlike Windows NT 4.0 scripts, Group Policy-based logon scripts are run hidden and asynchronously by default. The user object script (which, as in Windows NT 4.0, is run in a normal window) runs last.
  10. Operating system user interface prescribed by Group Policy appears.

Important

  • Three special cases deserve consideration during migration:
    • If the machine account object is in a Windows NT 4.0 domain and the user account object is in Active Directory, then only computer (not user) System Policy is processed when the user logs on. Then, user (not computer) Group Policy is processed.
    • If the machine account object is in Active Directory and the user account object is in a Windows NT 4.0 domain, then computer (not user) Group Policy is processed during computer startup. When the user logs on, user (not computer) System Policy is processed.
    • If the Windows 2000 computer and user accounts are members of a Windows NT 4.0 domain, then only System Policy (not Group Policy) for the computer and user is applied at user logon.

Notes

  • Several of these events can be modified. You can set policies to:
    • Reverse the synchronize or asynchronize defaults of 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 gives details about the order in which Group Policy settings for users and computers are processed in Windows 2000. See steps 3 and 8 in Order of events in startup and logon to see where the processing of policy settings fits into the framework of computer startup and user logon.

Group Policy settings are processed in the following order:

  1. Local Group Policy object. Each Windows 2000 computer has exactly one Group Policy object 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 specified by the administrator.
  3. Domain. Multiple domain-linked Group Policy objects are processed synchronously, in an order specified by the administrator.
  4. Organizational units. Group Policy objects linked to the organizational unit highest in the Active Directory hierarchy are processed first, then Group Policy objects linked to its child organizational unit, and so on. Finally, the Group Policy objects 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 are linked to an organizational unit, then they are processed synchronously, and in an order specified by the administrator.

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

Exceptions to the default order

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

  • Any Group Policy object linked to a site, domain, or organizational unit (not 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 overwritten. When more than one Group Policy object has been set to No Override, the one highest in the Active Directory hierarchy (or higher in the hierarchy specified by the administrator at each fixed level in Active Directory) takes precedence.

    Notice that No Override and Disabled are settings on Group Policy objects links, not the Group Policy objects. A Group Policy object can even 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 would seldom be useful, this capability illustrates the flexibility of the Group Policy infrastructure.)

    For information on 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 for a site, domain, or organizational unit.

  • At any site, domain, or organizational unit, Group Policy inheritance can be selectively marked as Block Policy inheritance. Group Policy object links set to No Override are always applied, however, and 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. Thus Block Policy inheritance deflects all Group Policy settings that would reach the site, domain, or organizational unit from above (by way of linkage 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 have been directly linked to the site, domain, or organizational unit that has had Block Policy inheritance enabled.

  • 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, see the Explain tab on the User Group Policy loopback processing mode properties sheet.

    Where?

    • Group_Policy_object_name
    • 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 specified by the administrator at each level.

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

    Loopback with Replace. In this case, the Group Policy object list for the user is replaced in its entirety by the Group Policy object list already obtained for the computer at computer startup (during step 2 in Order of events in startup and logon). The User Configuration settings from this list are applied to the user.

    Loopback with Merge. In this case, the Group Policy object list is a concatenation. The default step 2 list for computers is appended to the default step 7 list for users, and the user gets the user configuration settings in the concatenated list. Notice that the Group Policy object list obtained for the computer is applied later and therefore has precedence if it conflicts with settings in the user's list.

  • A computer that is a member of a workgroup processes only the local Group Policy object.


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 outside the approved registry trees 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.

Guidelines for writing applications that take advantage of Group Policy are available in the software development kit documentation used by developers. 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 they 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 Active Directory. If Windows NT 4.0 System Policy is enabled (not recommended for Windows 2000 clients), then other registry areas might also have changed during logon.

Sequence of events

  1. The user launches the application.
  2. A typical user-oriented application looks for registry data in the Group Policy reserved area HKEY_LOCAL_MACHINE\Software\Policies. If it 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 key:
    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies.
    If it 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 Windows 2000 applications might perform only the first three steps. Applications that use Group Policy under Windows 2000, but which remain compatible with earlier versions of Windows, continue on to step four when they run on the older operating systems. Applications that predate Windows 2000 never see steps two and three, and instead jump to step four.

The order of the sequence of events implies that:

  • For properly written applications running on Windows 2000 clients, Group Policy takes precedence over Windows NT 4.0 System Policy.
  • Older versions of applications (which are not aware of Active Directory and Group Policy) continue to function on Windows 2000 computers 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.


Understanding Software Installation

The Software Installation snap-in, a software management feature of Windows 2000, is the administrator's primary tool for managing software throughout its life cycle within the organization.

Software Installation works in conjunction with Group Policy and Active Directory. It is one of the three Software Installation and Maintainance tools provided with Windows 2000 Server. These are described in the following table.

Component | Role
The Software Installation extension of the Group Policy snap-in | Used by administrators to manage software.
Windows Installer | Installs software packaged in Windows Installer files.
Add/Remove Programs in Control Panel | Used by users to manage software on their own computers.

Assigning to users

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

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.

Publishing to users

When you publish the application to users, the application does not appear installed on the users' computers. No shortcuts are visible on the desktop or 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. Then, 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 using Add/Remove Programs in Control Panel or by clicking a file associated with the application (such as an .xls file for Microsoft Excel).

Application assignment scripts

For every published or assigned application in a particular Group Policy object, an application assignment script (.aas file) is generated and is stored in that domain's Group Policy object. These script files contain the advertisement information about the application configuration.

Active Directory

Windows 2000 Active Directory consists of a hierarchical collection of containers and an extendable schema. The Active Directory containers include sites, domains, organizational units, users, computers, and printers. Because the schema defines the properties of Active Directory objects and can be extended to define new Active Directory objects, you can use it to store any arbitrary object.

Software management provides schema-extended objects in Active Directory. These objects store the information required to map various class settings to the application packages that support these class settings.

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

Using Add/Remove Programs, users can browse for and install software from Active Directory in a managed environment, or from local media (in a non-managed environment, or if policy permits, installation from local media in a managed environment).

This section covers:

  • The administrator's view of software installation
  • Add/Remove Programs in Control Panel
  • File types often encountered in Software Installation


The administrator's view of software installation

Administrators must complete the following phases to manage software for their organization: preparation, management, and removal.

Preparation

Before you can use Software Installation, you need a Windows Installer package for the program you want to install. The package is often supplied with the software. If a program does not have a Windows Installer package, you need to generate one. Third-party utilities are available for repackaging a program you plan to install. You can then use transforms to further customize a package.

The next step is creating a network share, called a software distribution point, that contains the packages, any transforms, and the program files and components. Administration is simpler if packages and program files are kept together, although they don't have to be. (Packages and transforms do have to be kept together.) Administrators might also benefit from using distributed file systems to help manage these software distribution points.

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

Management

To manage programs within your organization, you use Software Installation. You can assign a program to either computers or users, or 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 would install the assigned or published version. This is often called a pilot. The pilot is a good time to experiment with Software Installation options such as Assign/Publish, Auto Install/Not Auto Install, and Visible Installation/Hidden Installation.
  • 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 would only have the option to install the new program. You can leave certain users unaffected if upgrading them at this time would impact their work.

Program removal phase

When administrators remove a program, they must select one of the following alternatives (the choices are mutually exclusive):

  • 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 they already have.

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/Remove Programs in Control Panel

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

Add/Remove Programs also offers the following features:

  • Provides users with a single user interface to use for managing and maintaining their programs.
  • Provides an interface that is useful for users with both advanced and novice knowledge about Microsoft Windows.
  • Supports 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.


File types often encountered in Software Installation

Besides executables such as Setup.exe and Install.exe, administrators typically work with the following types of files.

File type | File name extension | Description
Windows Installer packages | .msi | These files are typically provided by the software vendor to facilitate installation of a specific application. You need to keep these files with any other necessary files at the software distribution point for the software being managed.
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:

  • Cannot remove components or features
  • Cannot change product codes
  • Cannot remove or change names of shortcuts, files, or registry keys
.zap files | .zap | These files, which are similar to .ini files, are created with a text editor such as Notepad. They can only be published (not assigned), and they specify an executable setup program (such as \\server\share\Excel\Setup.exe) that appears in Add/Remove Programs in Control Panel for the user. The user has administrative rights on the local computer.
Application assignment scripts | .aas | These files contain instructions associated with the assignment or publication of a package.


Using Group Policy

This section covers:

  • Ways to open the Group Policy snap-in
  • Scripts
  • Local Group Policy
  • Advanced methods of extending Group Policy
  • Administering Group Policy
  • Group Policy and network infrastructure
  • Policy for the Group Policy snap-in
  • Migration issues
  • Administrative Templates


Ways to open the Group Policy snap-in

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

To apply Group Policy to | Do this
The local computer | In the Group Policy console, 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 Windows 2000 network computer, as described in To open Group Policy as a stand-alone MMC snap-in, and then browse to the network computer. You must be an administrator of the network computer.
A site | Open Group Policy as described in To open Group Policy from Active Directory Sites and Services, and then link a Group Policy object to the intended site.
A domain | Open Group Policy as described in To open Group Policy from Active Directory Users and Computers, and then link a Group Policy object to the intended domain.
An organizational unit | Open Group Policy as described in To open Group Policy 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 higher in the Active Directory hierarchy, so that the organizational unit can inherit Group Policy settings.
Any existing Group Policy object or set of Group Policy objects | Create and save your own custom MMC console. For more information, see Microsoft Management Console.


Scripts

Group Policy includes two extensions for script deployment:

  • Scripts – Startup/Shutdown. You use this extension, located under the Computer Configuration node, to specify scripts that are to run at computer startup or shutdown. These scripts run as Local System.
  • Scripts – Logon/Logoff. You use this extension, located under the User Configuration node, to specify scripts that are to run when the user logs on or off the computer. These scripts are run as User, not Administrator.

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

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

Related Topics


Local Group Policy

Each computer running Windows 2000 has exactly one local Group Policy object. Using these objects, Group Policy settings can be stored on individual computers whether or not they are part of an Active Directory environment or a networked environment.

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

You can open the Group Policy snap-in to edit the local Group Policy object stored on your local computer. For information on how to do this, see To open the local Group Policy object.

If you want to edit the local Group Policy object 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 you want. For information on how to do this, see To open Group Policy as a stand-alone MMC snap-in.

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

Computers running Windows NT 4.0 or earlier do not have a local Group Policy object.


Advanced methods of extending Group Policy

You can use the following advanced methods to extend Group Policy functionality.

Method Advantages Disadvantages
An advanced option for administrators: write an .adm file.
  • Easier option.
  • Everything you need is included in Windows 2000.
  • The .adm files are ASCII files and can be edited in Notepad.
  • You can write from scratch or modify existing templates to suit your purpose.
  • Only suitable for registry-based policies.
  • The user interface is limited. Finding where to set individual policies might be difficult.
An option for software developers only: write an extension to Group Policy.
  • Richer user interface.
  • The full Group Policy 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 material not included with Windows 2000.

Creating custom .adm files

Administrators can consider creating custom .adm files if the supplied template, System.adm, is inadequate. However, you should try to use the supplied template if possible.

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

For more information, see Creating custom .adm files.

Creating Microsoft Management Console (MMC) snap-in extensions

This is a task for software developers, not administrators.

Developers can create MMC snap-in extensions to provide program-specific user interfaces for setting Group Policy.

For information about Microsoft Management Console (MMC), see the Microsoft Platform SDK documentation (http://msdn.microsoft.com) for components for setup and Systems Management Services developers.


Administering Group Policy

This section covers:

  • Default permissions
  • Delegating control of Group Policy
  • Policy for Microsoft Management Console
  • Using security groups to filter Group Policy


Default permissions

The default permissions on Group Policy objects are as follows:

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

The Default Domain Policy Group Policy object cannot be deleted by any administrator, by default. This is to prevent the accidental deletion of this Group Policy object, which contains important and required settings for the domain. If it truly needs to be deleted—for example, because the policies have been set in other Group Policy objects—then the Delete access control entry (ACE) must be given back to the appropriate group.


Delegating control of Group Policy

To delegate control of Group Policy, you first create and save Group Policy Microsoft Management Consoles (.msc files). Next, you need to determine which users and groups have access permissions to the Group Policy object and the site, domain, and organizational unit.

Setting read and write permissions for Group Policy

The security access control list (ACL) editor tab for a Group Policy object is hosted in the Properties form of that Group Policy object. To access the ACL editor, right-click the root node of Group Policy, click Properties, and then click Security. You use the Security property page to set permissions on a selected Group Policy object. These permissions allow or deny access to the Group Policy object by specified groups.

Your organization's top network administrators (members of the Domain Administrators group) can also use the ACL editor to determine which administrator groups can modify policies in Group Policy objects. To do this, the network administrator can define groups of administrators (for example, Accounting Administrators), and then provide them Read/Write access to selected Group Policy objects. In this way, the network administrator can delegate control of the Group Policy object policies.

Note

A user or administrator who does not have Write access (but does have Read access) to a Group Policy object cannot use the Group Policy snap-in to see the settings that it contains. Every extension to Group Policy assumes that it has Write access to the Group Policy object storage locations. Therefore Group Policy does not open a Group Policy object when the current user does not have Write access to it.


Policy for Microsoft Management Console

Several Group Policy settings provided in System.adm governing use of Microsoft Management Console (MMC). This is significant, because saving previously configured consoles is a way to delegate administrative rights.

In the console tree, click Group Policy.

Where?

  • Group_Policy_object_name
  • User Configuration
  • Administrative Templates
  • Windows Components
  • Microsoft Management Console
  • Restricted/Permitted snap-ins
  • Group Policy

Double-click each extension to Group Policy for which you want to set an administrative Group Policy setting that governs use of the extension in MMC consoles.

For more information, see Delegating control of Group Policy and Microsoft Management Console.


Using security groups to filter Group Policy

Because Group Policy can apply settings from more than one Group Policy object to a site, domain, or organizational unit, you can add Group Policy objects that are associated with other directory objects. You can also prioritize how these Group Policy objects affect the directory object to which they are applied.

In Windows 2000, computers can belong to security groups. Administrators can use security groups to further refine which computers and users a Group Policy object influences. For any Group Policy object, administrators can filter the Group Policy object's effect on computers that are members of specified security groups. This filtering occurs using the standard access control list (ACL) editor. To use the ACL editor, click a Group Policy object's property sheet, and then click Security. The ACL editor can also be used by administrators to delegate who can modify the Group Policy object.


Group Policy and network infrastructure

This section covers:

  • Group Policy in replicated environments
  • Group Policy over slow links
  • Group Policy on sites


Group Policy in replicated environments

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

An administrator using Active Directory Users and Computers can create an organizational unit on any domain controller.

By default, Group Policy objects are created or edited only on the domain controller that is holding the primary domain controller 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 holding the token before the Group Policy object created there can be linked to it, allowing the Group Policy settings to be applied.

These considerations are more significant if the intra-domain links are slow.

Options governing selection of a domain controller

The Group Policy View menu contains an entry called DC Options, which opens the Options for domain controller selection dialog box, where you can specify a domain controller to use for editing Group Policy. The available options for the Options for domain controller selection dialog box are:

  • The one with the Operations Master token for the PDC emulator. This is the default and preferred option, and is safest from the standpoint of data safety.
  • The one used by the Active Directory snap-ins. Uses the domain controller that the utility from which the Group Policy console was invoked is currently using, if Group Policy was started in this way.
  • Use any available domain controller. Allows the Group Policy snap-in to choose any available domain controller. This is the least safe option, because different administrators could theoretically edit a Group Policy object simultaneously, with indeterminate outcome. On the other hand, when this option is used 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, then the performance gain might be worthwhile.

Domain controller selection set through Group Policy

In addition to the View menu option described previously, there is also a Group Policy setting for domain controller selection. This is part of the System.adm Administrative Template that is loaded into the Group Policy console by default.

To access this setting, in the console tree, click the Group Policy node.

Where?

  • Group_Policy_object_name
  • User Configuration
  • Administrative Templates
  • System
  • Group Policy
In the details pane, double-click the Group Policy domain controller selection icon, and then select the appropriate setting from the drop-down list.


Group Policy over slow links

Group Policy is applied remotely, provided the computer is a member of the domain that the Routing and Remote Access server belongs to or is trusted to. This is true whether logging on by way of 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 foreign domain (a domain not containing the computer, and not in a trust relationship with the computer's domain), or a workgroup. Although the connection may still be made, access to domain resources may be adversely affected because of mismatched IPSEC security.

By default, registry-based polices are always applied, and cannot be turned off. Security Settings are also applied by default, but all others are not applied. For all but the registry settings, the default behavior can be toggled to apply or not.

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), then it's considered a fast link; more and it's considered a slow link. You can set this value using the Group Policy setting Slow network connection timeout for user profiles Properties.

Where?

  • group_policy_object_name
  • Computer Configuration
  • Administrative Templates
  • System
  • Logon

Several other Group Policy settings related to slow links appear there as well. Also, see the Group Policy setting Group Policy slow link detection.

Where?

  • group_policy_object_name
  • Computer Configuration
  • Administrative Templates
  • System
  • Group Policy


Group Policy on sites

Group Policy objects applied to Active Directory site objects affect all computers in the site. Directory information is replicated among and available between 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 linked to a site is applied to all computers in that site regardless of which domain (in the forest) contains the computers.

This allows for multiple domains within a forest to get the same Group Policy object (and included policies), although the Group Policy object exists only as a stored entity on a single domain and 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 not, the computers in a child domain will be accessing a site-linked Group Policy object across a WAN link. This will increase the processing time for Group Policy.


Policy for the Group Policy snap-in

This section covers:

  • Policy for Group Policy: Computer Configuration
  • Policy for Group Policy: User Configuration


Policy for Group Policy: Computer configuration

This topic describes policies concerned with managing computers through Group Policy. Because these policies are included in System.adm, they should be present by default. To configure these policies, see Open the Group Policy snap-in. In the console tree, click the Group Policy node.

Where?

  • policy_name Policy
  • Computer Configuration
  • Administrative Templates
  • System
  • Group Policy

Disable background refresh of Group Policy

Prevents Group Policy from being updated while the computer is in use. This policy applies to Group Policy settings for computers, users, and domain controllers. If you enable this policy, the system waits until the current user logs off the system before updating the computer and user policies.

If you disable this policy, updates can be applied while users are working. The frequency of updates is determined by the Group Policy refresh interval for computers and Group Policy refresh interval for users policies.

Apply Group Policy for computers synchronously during startup

Directs the system to wait for updates to Group Policy to be completed before it displays the logon prompt. This policy applies only to Group Policy settings in the Computer Configuration folder.

If you enable this policy, users cannot log on until Group Policy for computers has been updated.

If you disable this policy, the system does not wait for Group Policy updates to complete before inviting the user to log on. As a result, the logon dialog box might appear sooner, but the Windows interface can appear to be ready before all Group Policy settings have been applied.

To determine whether the system synchronizes user Group Policy settings and Windows Explorer, see the Apply Group Policy for user synchronously during startup policy.

Apply Group Policy for users synchronously during startup

Directs the system to wait for updates to Group Policy to finish before it displays the logon prompt. This policy applies only to Group Policy settings that appear in the User Configuration folder. If you enable this policy, users cannot log on until user Group Policy settings have been updated.

If you disable this policy, the system does not wait for policy updates to complete before inviting users to log on. As a result, the Log on to Windows dialog box might appear sooner, but the Windows interface can appear to be ready before all policies have been applied. To determine whether the system synchronizes computer policies and Windows Explorer, see the Apply Group Policy for computers synchronously during startup policy.

Group Policy refresh interval for computers

Specifies how often Group Policy for computers is updated while the computer is in use (in the background). This policy specifies a background update rate only for Group Policy settings in the Computer Configuration folder.

In addition to background updates, Group Policy for the computer is always updated when the system starts.

If you disable this policy, Group Policy is updated every 90 minutes (the default), with a random offset of 0 to 30 minutes. You can specify an update rate from 0 to 64,800 minutes (45 days). If you select 0 minutes, the computer tries to update Group Policy every 7 seconds. However, because updates might interfere with users' work and increase network traffic, very short update intervals are not appropriate for most installations.

To specify that Group Policy should never be updated while the computer is in use, select the Disable background refresh of Group Policy policy.

You can also use the Group Policy refresh interval for computers policy to specify how much the actual update interval varies. To prevent clients with the same update interval from requesting updates simultaneously, the system varies the update interval for each client by a random number of minutes. The number you type in the random time box sets the upper limit for the range of variance. For example, if you type 30 minutes, the system selects a variance of 0 to 30 minutes. Typing a large number establishes a broad range and makes it less likely that client requests overlap. However, updates might be delayed significantly.

This policy establishes the update rate for computer Group Policy. To set an update rate for user policies, use the Group Policy refresh interval for users policy (located in User Configuration\Administrative Templates\System\Group Policy).

This policy is used only when the Disable background refresh of Group Policy policy is not enabled.

Note

  • Consider notifying users that their policy is updated periodically so that they recognize the signs of a policy update. When Group Policy is updated, the Windows desktop is refreshed; it flickers briefly and closes open menus. Also, restrictions imposed by Group Policy settings, such as those that limit the programs users can run, might interfere with tasks in progress.

Group Policy refresh interval for domain controllers

Specifies how often Group Policy is updated on domain controllers while they are running (in the background). The updates specified by this policy occur in addition to updates performed when the system starts.

By default, Group Policy on the domain controllers is updated every five minutes.

You can specify an update rate from 0 to 64,800 minutes (45 days). If you select 0 minutes, the domain controller tries to update Group Policy every 7 seconds. However, because updates might interfere with users' work and increase network traffic, very short update intervals are not appropriate for most installations.

If you disable this policy, the domain controller updates Group Policy every five minutes (the default). To specify that Group Policy settings for users should never be updated while the computer is in use, select the Disable background refresh of Group Policy policy.

You can also use this policy to specify how much the actual update interval varies. To prevent domain controllers with the same update interval from requesting updates simultaneously, the system varies the update interval for each controller by a random number of minutes. The number you type in the random time box sets the upper limit for the range of variance. For example, if you type 30 minutes, the system selects a variance of 0 to 30 minutes. Typing a large number establishes a broad range and makes it less likely that update requests overlap. However, updates might be delayed significantly.

Note

  • This policy is used only when you are establishing policy for a domain, site, organizational unit, or customized group. If you are establishing policy for a local computer only, the system ignores this policy.

User Group Policy loopback processing mode

Applies alternate user policy settings when a user logs on to a computer affected by this policy setting. The possible settings are Normal, Merge, and Replace.

This policy directs the system to apply the set of Group Policy objects for the computer to any user who logs on to a computer affected by this policy setting. It is intended for special-use computers, such as those in public places, laboratories, and classrooms, where you must modify the user policy setting based on the computer that is being used.

By default, the user's Group Policy objects determine which user policy settings apply. If this policy is enabled, then, when a user logs on to this computer, the computer's Group Policy objects determine which set of Group Policy objects applies.

To use this policy, select one of the following policy modes from the Mode box:

Replace indicates that the user policy settings defined in this computer's Group Policy objects replace the user policy settings normally applied to the user.

Merge indicates that the user policy setting defined in this computer's Group Policy objects and the user policy settings normally applied to the user are combined. If the policy settings conflict, the user settings in this computer's Group Policy objects take precedence over the user's normal policy settings.

If you disable this policy or do not configure it, the user's Group Policy objects determine which user policy settings apply.

Group Policy slow link detection

Defines a slow connection for purposes of applying and updating Group Policy settings.

If the rate at which data is transferred from the domain controller providing a policy update to the computers in this group is slower than the rate specified by this policy, the system considers the connection to be slow.

The system's response to a slow policy connection varies among policies. The program implementing the policy can specify the response to a slow link. Also, you can use the policy-processing policies in this folder to override the programs's specified responses to slow links.

To use this policy, in the Connection speed box, type a decimal number between 0 and 4,294,967,200 (0xFFFFFFA0), indicating a transfer rate in kilobits per second. Any connection slower than this rate is considered to be slow. If you type 0, all connections are considered to be fast.

If you disable this policy or do not configure it, the system uses the default value of 500 kilobits per second.

This policy appears in the Computer Configuration and User Configuration folders. The policy in Computer Configuration defines a slow link for policies in the Computer Configuration folder. The policy in User Configuration defines a slow link for policies in the User Configuration folder.

Registry policy processing

If this policy is configured, the choices are Do not apply during periodic background processing and Process even if the Group Policy objects have not changed. These are independent of each other.

This policy determines when registry policies are updated, and it affects all policies in the Administrative Templates folder and any other policies that store values in the registry. It overrides customized settings that the program implementing a registry policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Folder Redirection policy processing

If this policy is configured, the choices are Do not apply across a slow network connections and Process even if the Group Policy objects have not changed. These are independent of each other.

This policy determines when folder redirection policies are updated, and it affects all policies that use the Folder Redirection component of Group Policy, such as those in Windows Settings\Folder Redirection. You can set folder redirection policy only for Group Policy objects stored in Active Directory, not for Group Policy objects on the local computer.

This policy overrides customized settings that the program implementing the folder redirection policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update is being transmitted across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Disk Quota policy processing

If this policy is configured, the independent choices are Allow processing across a slow network connection, Do not apply during periodic background processing, and Process even if the Group Policy objects have not changed.

This policy determines when disk quota policies are updated, and it affects all policies that use the disk quota component of Group Policy, such as those in Computer Configuration\Administrative Templates\System\File System\Disk Quotas. It also overrides customized settings that the program implementing the disk quota policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system

The Allow processing across a slow network connection option updates the policies even when the update transmits across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Scripts policy processing

If this policy is configured, the independent choices are Allow processing across a slow network connection, Do not apply during periodic background processing, and Process even if the Group Policy objects have not changed.

This policy determines when policies that assign shared scripts are updated, and it affects all policies that use the Scripts component of Group Policy, such as those in WindowsSettings\Scripts. It also overrides customized settings that the program implementing the scripts policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update is being transmitted across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Security policy processing

If this policy is configured, the independent choices are Do not apply during periodic background processing and Process even if the Group Policy objects have not changed.

This policy determines when security policies are updated, and it affects all policies that use the security component of Group Policy, such as those in Windows Settings\Security Settings. It also overrides customized settings that the program implementing the security policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update transmits across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

EFS recovery policy processing

If this policy is configured, the independent choices are Allow processing across a slow network connection, Do not apply during periodic background processing, and Process even if the Group Policy objects have not changed.

This policy determines when encryption polices are updated, and it affects all policies that use the encryption component of Group Policy, such as policies related to encryption in Windows Settings\Security Settings. It also overrides customized settings that the program implementing the encryption policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update transmits across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Software Installation policy processing

If this policy is configured, the independent choices are Allow processing across a slow network connection and Process even if the Group Policy objects have not changed.

This policy determines when software installation polices are updated, and it affects all policies that use the Software Installation component of Group Policy, such as policies in Software Settings\Software Installation. You can set software installation policy only for Group Policy objects stored in Active Directory, not for those on the local computer.

This policy overrides customized settings that the program implementing the software installation policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update transmits across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

IP security policy processing

If this policy is configured, the independent choices are Allow processing across a slow network connection, Do not apply during periodic background processing, and Process even if the Group Policy objects have not changed.

This policy determines when IP security polices are updated, and it affects all policies that use the IP security component of Group Policy, such as policies in Computer Configuration\Windows Settings\Security Settings\IP Security Policies on Local Machine. It also overrides customized settings that the program implementing the IP security policy set when it was installed.

If you enable this policy, you can use the check boxes provided to change the options. If you disable this policy or do not configure it, it has no effect on the system.

The Allow processing across a slow network connection option updates the policies even when the update transmits across a slow network connection, such as a telephone line. Updates across slow connections can cause significant delays.

The Do not apply during periodic background processing option prevents the system from updating affected policies in the background while the computer is in use. Background updates can disrupt the user, cause a program to stop or operate abnormally, and, in rare cases, damage data.

The Process even if the Group Policy objects have not changed option updates and reapplies the policies even if the policies have not changed. Many policy implementations specify that they are updated only when changed. However, you might want to update unchanged policies, such as reapplying a setting if a user changes it.

Download missing COM components

Directs the system to search Active Directory for missing Component Object Model (COM) components that a program requires.

Many Windows programs, such as the Microsoft Management Console snap-ins, use the interfaces provided by the COM. These programs cannot perform all of their functions unless Windows 2000 has internally registered the required components.

If you enable this policy and a component registration is missing, the system searches for it in Active Directory and, if it is found, downloads it. The resulting searches might make some programs start or run slowly.

If you disable this policy or do not configure it, the program continues without the registration. As a result, the program might not perform all of its functions, or it might stop.

This policy applies to computers. To set this policy for users, use the Download missing COM components policy in UserConfiguration\AdministrativeTemplates\System\Group Policy.


Policy for Group Policy: User configuration

This topic describes policies you use to manage users through Group Policy. Because these policies are included in System.adm, they should be present in the console by default. To configure these policies, open Group Policy as described in To open the Group Policy snap-in. In the console tree, click the Group Policy node.

Where?

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

Group Policy refresh interval for users

Specifies how often Group Policy for users is updated while the computer is in use (in the background). This setting specifies a background update rate only for the Group Policy settings in the User Configuration folder.

In addition to background updates, Group Policy for users is always updated when users log on.

By default, user Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes.

You can specify an update rate from 0 to 64,800 minutes (45 days). If you select 0 minutes, the computer tries to update user Group Policy every 7 seconds. However, because updates might interfere with work and increase network traffic, very short update intervals are not appropriate for most installations.

If you disable this setting, user Group Policy is updated every 90 minutes (the default). To specify that Group Policy for users should never be updated while the computer is in use, select the Disable background refresh of Group Policy setting.

You can also use this setting to specify how much the actual update interval varies. To prevent clients with the same update interval from requesting updates simultaneously, the system varies the update interval for each client by a random number of minutes. The number you type in the random time box sets the upper limit for the range of variance. For example, if you type 30 minutes, the system selects a variance of 0 to 30 minutes. Typing a large number establishes a broad range and makes it less likely that client requests overlap. However, updates might be delayed significantly.

This setting establishes the update rate for user Group Policies. To set an update rate for computer Group Policies, use the Group Policy refresh interval for computers setting (located in Computer Configuration\Administrative Templates\System\Group Policy).

This setting is used only when the Disable background refresh of Group Policy setting is not selected.

Note

  • Consider notifying users that their Group Policy is updated periodically so that they recognize the signs of a policy update. When Group Policy is updated, the Windows desktop is refreshed; it flickers briefly and closes open menus. Also, restrictions imposed by Group Policies, such as those that limit the programs a user can run, might interfere with tasks in progress.

Group Policy slow link detection

Defines a slow connection for purposes of applying and updating Group Policy.

If the rate at which data is transferred from the domain controller providing a policy update to the computers in this group is slower than the rate specified by this setting, the system considers the connection to be slow.

The system's response to a slow policy connection varies among policies. The program implementing the policy can specify the response to a slow link. Also, the policy processing policies in this folder let you override the program's specified responses to slow links.

To use this policy, in the Connection speed box, type a decimal number between 0 and 4,294,967,200 (0xFFFFFFA0), indicating a transfer rate in kilobits per second. Any connection slower than this rate is considered to be slow. If you type 0, all connections are considered to be fast.

If you disable this policy or do not configure it, the system uses the default value of 500 kilobits per second.

This policy appears in the Computer Configuration and User Configuration folders. The policy in Computer Configuration defines a slow link for policies in the Computer Configuration folder. The policy in User Configuration defines a slow link for policies in that folder.

Group Policy domain controller selection

Determines which domain controller the system uses when applying Group Policy to users.

Use the Primary Domain Controller indicates that policy is applied by the primary domain controller in the domain in which the user is logged on.

Inherit from the Active Directory Snap-ins indicates that policy is applied by the domain controller hosting the Group Policy snap-in.

Use any available domain controller indicates that the system can use the first domain controller it finds available in the domain.

If you disable this policy or do not configure it, the primary domain controller applies Group Policy.

Create new Group Policy object links disabled by default

If you enable this policy, the New Group Policy Object check box on the Active Directory Users and Computers and the Active Directory Sites and Services snap-ins is cleared (not selected) by default. Administrators can still select the check box to select the option.

If you disable this policy or do not configure it, the New Group Policy Object option is selected by default and administrators must click to clear it.

Enforce Show Policies Only

This policy affects the Show Policies Only view menu option in the Administrative Templates node of the Group Policy.

Enabling this policy prevents the user from clearing the Show Policies Only menu item. Disabling this policy prevents the user from selecting this menu item.

In this context, policies refers to Windows 2000 Group Policy, not Windows NT 4.0–style system policies. See Windows NT 4.0 System Policies for an explanation of why this distinction is significant.

Disable automatic update of .adm files

Prevents the system from updating the Administrative Templates source files automatically when you open Group Policy.

By default, when you start Group Policy, the system loads the most recently revised copies of the Administrative Templates source files (.adm) in the %systemroot%\inf folder. The .adm files create the list of policies that appear under Administrative Templates in Group Policy.

If you enable this policy, the system loads the .adm files you used the last time you ran Group Policy. After this, you must update the .adm files manually.

Notes

  • Upgrading your .adm files does not overwrite your policy configuration settings. The settings are stored in Active Directory, not in the .adm files.
  • To upgrade your .adm files manually, in Group Policy, right-click Administrative Templates (either instance), and then click Add/Remove Templates.

Download missing COM components

Tells the system to search Active Directory for missing Component Object Model (COM) components that a program requires.

Many Windows programs, such as the MMC snap-ins, use the interfaces provided by the Component Object Model. These programs cannot perform all of their functions unless Windows 2000 internally registers the required components.

If you enable this policy and a component registration is missing, the system searches for it in Active Directory and, if it is found, downloads it. The resulting searches might make some programs start or run slowly.

If you disable this policy or do not configure it, the program continues without the registration. As a result, the program might not perform all of its functions, or it might stop.

This policy applies to users. To set this policy for computers, use the Download missing COM components policy in ComputerConfiguration\AdministrativeTemplates\System\Group Policy.


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 2000 Server

Computers running Windows 2000 Server can either be ordinary member servers of Active Directory or domain controllers. Group Policy fully supports both.

Windows 2000 Professional

Group Policy fully supports client computers running Windows 2000 Professional.

Windows NT 4.0 Workstation and Server

These clients continue to be fully supported by Windows NT 4.0 System Policy, for which the System Policy Editor (Poledit.exe) is provided. The administrator uses Poledit.exe to write Windows NT 4.0–style .adm files.

Windows NT 4.0 does not use Active Directory. Because computers running Windows NT 4.0 do not have local Group Policy objects, Group Policy does not apply.

Windows 95 and Windows 98

Windows 95 and Windows 98 clients should run System Policy Editor (Poledit.exe) on the local computer. This ensures that the Config.pol file created will be compatible with those operating systems. Copy the resultant Config.pol file to the SysVol folder of the Windows 2000 Server domain controller.

Group Policy does not apply.

Windows NT 3.51, Windows 3.1, and MS-DOS

Group Policy does not apply.

Note

  • Exactly one local Group Policy object exists on each computer running Windows 2000, and the User Configuration settings it contains are the same for each user of that computer. To handle multiple user configurations using policy on a computer running Windows 2000 that is subject to only a single Group Policy object because it is not part of a Windows 2000 domain (for example, a stand-alone computer), the administrator uses System Policy through System Policy Editor (Poledit.exe). Poledit.exe is run on the local computer to create a correctly formatted .pol file. User profiles provide individually configured desktops for individual users if neither System Policy nor Group Policy is used.


The role of Administrative Templates

In Windows 2000, Administrative Templates have the .adm file name extension, as they did in Windows NT 4.0. However, their roles are slightly different.

Role in earlier versions of Windows

In previous 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 explicitly mentioned in the .adm file.

Role in Windows 2000

Windows 2000 includes several .adm files, which are listed in .adm files included with Windows 2000. 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 ones cannot in System Policy Editor. For more information on the new .adm language, see Creating custom .adm files.

Windows 2000 supports Unicode-based .adm files.

For cautionary information on using Windows NT 4.0–style .adm files in a Windows 2000 environment, see Windows NT 4.0 system policies.


The role of System Policy Editor

Although System Policy Editor (Poledit.exe) is largely replaced by Group Policy, it is still useful under some circumstances.

  • Management of computers running Windows 95 or Windows 98. The Windows 2000 version of the System Policy Editor must be run locally on computers running Windows 98 or Windows 95 to create Config.pol files compatible with the local operating system.
  • Management of computers running Windows NT 4.0 Workstation and Windows NT 4.0 Server. These computers also need their own style of .pol file: NTConfig.pol.
  • Management of stand-alone computers running Windows 2000. A Windows 2000 computer that is not joined to any domain is therefore not subject to nonlocal Group Policy by way of Active Directory. The only Group Policy that applies to such a computer is local Group Policy, which contains settings for only one user. (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.


Windows NT 4.0 system policies

If a Windows NT 4.0 client computer managed by a Windows 2000 server is upgraded to Windows 2000, then afterward the computer receives only Computer Configuration Group Policy, and not Windows NT 4.0 machine System Policy. The policy received by the user who logs on will be 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, then the user gets Windows NT 4.0 user System Policy.

Policies included with Windows 2000 only set registry keys and values 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 are preferred. All four trees are secure, and 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 then rewritten.

Windows NT 4.0 policies do not respect these special trees, and 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–style policy, or by editing the registry.

Caution

  • It is possible for an Administrative Template (.adm file) to be added to Group Policy that sets registry values outside of the approved Windows 2000 Group Policy trees, although Windows 2000 does not include any such .adm file. The administrator who chooses to install Windows NT 4.0–style .adm files should be aware that this can lead to undesirably persistent registry settings.


Administrative Templates

Group Policy requires a source from which to generate the user interface settings an administrator can set. For this purpose, Group Policy can use either a Microsoft Management Console extension snap-in to Group Policy, or an ASCII file referred to as an Administrative Template (.adm file).

The .adm file consists of a hierarchy of categories and subcategories that together define how the options are displayed through Group Policy. This file also indicates the registry settings that can be modified through Group Policy in addition to:

  • Registry locations where changes should be made if a particular selection is made.
  • Options or restrictions (in values) that are associated with the selection.
  • In some cases, a default value to use if a selection is activated.

This section covers:

  • .adm files included with Windows 2000
  • Advanced topic: Creating custom .adm files


.adm files included with Windows 2000

Five Administrative Templates are included with Windows 2000.

Administrative template | Description
System.adm | Installed in Group Policy by default. For Windows 2000 clients.
Inetres.adm | Installed in Group Policy by default. Internet Explorer policies for Windows 2000 clients.
Winnt.adm | User interface options specific to Windows NT 4.0. For use with System Policy Editor (Poledit.exe).
Windows.adm | User interface options specific to Windows 95 and Windows 98. For use with System Policy Editor (Poledit.exe).
Common.adm | User interface options common to Windows NT 4.0 and Windows 95 and 98. For use with System Policy Editor (Poledit.exe).

System.adm and Inetres.adm use the four reserved Group Policy registry areas. For the locations of those areas, see Windows NT 4.0 system policies. Although the last three .adm files can be loaded into Group Policy, you should limit their use to the administration of earlier versions of Windows through System Policy Editor.

Visibility of System Policy settings in the Group Policy console

When an .adm file is added to Group Policy as described in To add or remove an Administrative Template (.adm file), by default only the settings contained in the genuine Group Policy trees are visible in the console. To change this default user preference, on the View menu of the Group Policy console, clear the Show Policies Only check box. (For Show Policies Only to appear on the View menu, you need to select one of the Administrative Templates nodes.)

The ability to clear the Show Policies Only setting on the View menu is subject to a Group Policy setting called Enforce Show Policies Only.

Where?

  • Group_Policy_object_name [domain_controller_name.domain_name] Policy
  • User Configuration
  • Administrative Templates
  • System
  • Group Policy

When System Policy settings are allowed to be visible in a Group Policy console, the icons for those settings appear red. The icons for true Group Policy settings appear blue.

Caution

  • It is highly recommended that you do not use System Policy–type .adm files when you manage Windows 2000 clients because this leads to undesirably persistent registry settings.


Advanced topic: Creating custom .adm files

An .adm file defines how registry-related Group Policy settings are displayed under the Administrative Templates nodes in the Group Policy user interface. In addition, the .adm file:

  • Specifies the registry locations where changes should be made if an administrator makes a particular selection. (These registry locations are not shown in the Group Policy user interface, because an administrator generally doesn't need to work with them directly.)
  • Specifies any options or restrictions (in values) that are associated with the selection.
  • Can specify a default value to use if a selection is activated.

The following sections describe the components of an .adm file.

  • STRING
  • CLASS
  • CATEGORY
  • POLICY
  • EXPLAIN
  • PART
  • PartTypes
  • NUMERIC


String variables

You use string variables in an .adm file if you want to use variables to define text strings for the user interface. This is useful if the strings are lengthy and are used in several locations throughout the .adm file. This method also allows easier conversion to other languages (localization).

You can use string variables for CATEGORY, POLICY, PART, and DEFAULT. Assign the variable name to the component by preceding it with two exclamation points (!!). Then, in the [strings] section of the file, link the variable with the actual string to be used in the user interface. The string must be enclosed in quotation marks.

component !!variable

where component is CATEGORY, POLICY, PART, or DEFAULT, and variable is the variable you want to use for a given string.

Optionally, you can enclose a variable name in double quotation marks ("). Names with spaces must be enclosed by double quotation marks.

In the [strings] section of the file, you define the variable as follows:

variable = "string"

String variable example

Suppose you want to use the following category name several places throughout your user interface:

My First Category

You could assign the following variable to this string:

FirstCategory

You would use the following

CATEGORY !!FirstCategory

Then, in the [strings] section, you would define the FirstCategory variable:

FirstCategory="My First Category"

Result: The My First Category string would be displayed without quotation marks in the Group Policy user interface.


CLASS

Your first entry in an .adm file must be CLASS xxxx, where xxxx can be one of the following:

MACHINE: This section includes entries found in the Computer Configuration node in Group Policy.

USER: This section includes entries found in the User Configuration node in Group Policy.

These are the only two valid classes within an .adm file. The Group Policy snap-in ignores non-valid classes.

The valid keywords for CLASS are

  • CLASS
  • CATEGORY
  • StringsSect
  • USER
  • MACHINE


CATEGORY

The category name is displayed in Group Policy as a node in either the Computer Configuration or the User Configuration node, depending on whether it is defined under the MACHINE class or the USER class.

The CATEGORY syntax is as follows:

CATEGORY !!"variable name"

[KEYNAME "key name"]

[... policy definition statements ...]

END CATEGORY

where:

variable name is the category name as it should appear in the Group Policy list box. Names with spaces must be enclosed by double quotation marks.

key name is the optional registry key name to use for the category. If a key name is specified, it will be used by all child categories, policies, and parts, unless they specifically provide a key name of their own. Names with spaces must be enclosed by double quotation marks.

A policy definition statement cannot appear more than once in a single category.

The following example shows a category name of MyNewCategory:

CATEGORY !!MyNewCategory

To close the category after filling in the options, use:

END CATEGORY ; MyNewCategory

Note that categories can be nested to create subcategories as in the following example:

CATEGORY !!FirstCategory
   CATEGORY !!SecondCategory
     CATEGORY !!ThirdCategory
     ...
     ...
     END CATEGORY ; ThirdCategory
   END CATEGORY ; SecondCategory
END CATEGORY ; FirstCategory

The valid keywords for CATEGORY are:

  • KEYNAME
  • CATEGORY
  • POLICY
  • END


POLICY

To identify the policy that the user can modify, you use the keyword POLICY:

POLICY !!MyFirstPolicy
...fill in all the policy specifics
...and then finish with:
END POLICY

You can use multiple POLICY key names under one KEYNAME. In the previous example, you must define the MyFirstPolicy variable in the [strings] section of the .adm file.

The valid keywords for POLICY are:

  • KEYNAME
  • VALUENAME
  • PART
  • VALUEON
  • VALUEOFF
  • ACTIONLISTON
  • ACTIONLISTOFF
  • END
  • HELP
  • CLIENTEXT
  • POLICY

VALUENAME

Defines the options available within a policy. You must first identify the registry value that is to be modified as a result of using the keyword VALUENAME. For example, VALUENAME MyFirstValue.

Unless you specify otherwise, the value will be written in the following format when the user selects or clears the option:

  • Selected: REG_DWORD with a value of 1.
  • Cleared: remove the value completely.

Other options are available and are listed in the following sections. If the option is to be selected within the lower pane of the Group Policy snap-in, then the VALUENAME needs to be within a PART scope, as described in PART.

CLIENTEXT

The CLIENTEXT keyword is used to specify which client-side extension (a .dll on the user's computer, for example) to the Group Policy snap-in is needed to process particular settings on the client computer. By default, the Registry extension processes all settings configured under the Administartive Templates node. The CLIENTEXT keyword changes the default behavior and causes the specified extension to process these settings after the Registry extension has placed them in the registry.

CLIENTEXT must be used within either the POLICY scope or the PART scope and should follow the VALUENAME statement.

For example:

POLICY !!DQ_Enforce
        EXPLAIN !!DQ_Enforce_Help
            VALUENAME "Enforce"
            CLIENTEXT {3610eda5-77ef-11d2-8dc5-00c04fa31a66}
           PART !!DQ_EnforceTip1                         TEXT
        END PART
END POLICY

The GUID that follows the CLIENTEXT keyword is the GUID of the client-side extension. The client-side extensions are listed in the registry under
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions.

VALUEOFF/VALUEON

You use VALUEOFF/VALUEON to write specific values based on the state of the option. You enable this functionality by writing the .adm file as shown in the following examples:

KEYNAME ....
   POLICY !!MyPolicy
   VALUENAME ValueToBeChanged
   VALUEON "Turned On" VALUEOFF "Turned Off"
   END POLICY

or:

KEYNAME ....
   POLICY !!MyPolicy
   VALUENAME ValueToBeChanged
   VALUEON 5 VALUEOFF 10
   END POLICY

Using simple policies and policies with the VALUEOFF/VALUEON statements

This section presents two examples that illustrate the difference between using the default policy states and specifying VALUEON/VALUOFF statements.

Example 1

In this example, no explicit VALUEON / VALUEOFF statements are used. This means that the Administrative Templates will use the default behavior when the user changes the state of this policy.

POLICY !!EnableSlowLinkDetect
    EXPLAIN !!EnableSlowLinkDetect_Help
    KEYNAME "Software\Policies\Microsoft\Windows\System"
    VALUENAME "SlowLinkDetectEnabled"
END POLICY

The following table lists the default behavior.

State | Behavior
Policy setting enabled | A DWORD with the value 1 is written to the registry.
Policy setting disabled | The registry value is deleted.
Policy setting not configured | No change is made to the registry.

The important thing to note is the Policy disabled state. The value is not written to the registry with the value of 0; instead it is explicitly deleted. This means a component reading the policy will not find it in the registry, and will fall back to using the default in the code. Essentially, having the policy in the disabled state is the same as having it in the dimmed state.

Example 2
In this example, the state values are explicitly defined, so the Administrative Templates will use these values when the user changes the policy.

POLICY !!EnableSlowLinkDetect
    EXPLAIN !!EnableSlowLinkDetect_Help
    KEYNAME "Software\Policies\Microsoft\Windows\System"
    VALUENAME "SlowLinkDetectEnabled"
        VALUEON NUMERIC 1
        VALUEOFF NUMERIC 0
END POLICY

The following table lists the behavior in this example.

State | Behavior
Policy setting enabled | A DWORD with the value 1 is written to the registry.
Policy setting disabled | A DWORD with the value 0 is written to the registry.
Policy setting not configured | No change is made to the registry.


EXPLAIN

You use the EXPLAIN keyword to provide Help text.

Each policy needs one EXPLAIN keyword with at least one space after it, followed by either the explain string in quotation marks or a reference to the explain string.

Example:

POLICY !!NetCache KEYNAME Software\Policies\Microsoft\Windows\NetCache #if VERSION >= 3 HELP !!IntelliMirrorExplain #endif ..... [Strings] IntelliMirrorHelp="Explanation for Windows 2000 IntelliMirror\n\n You can use this policy to configure the file system caching options."

\n\n creates a new line in the displayed text.

In the example, an explanation is offered for one of the Offline Files options. The following string means that this can be used with Windows 2000 (version 3) or later versions of Windows:

#if VERSION >= 3


PART

You can use PART to specify various options, including drop-down list boxes, text boxes, and text in the lower pane of the Group Policy snap-in.

The PART syntax is:

PART [!!]name  PartType
  type-dependent data
  [KEYNAME KeyName ]
  VALUENAME ValueName
END PART

where:

name is the part name as it should appear in the Group Policy list box. Names with spaces must be enclosed by double quotation marks. As a text string that is visible in the user interface, it should use the [STRINGS] variable !!.

PartType is the policy part flags. Flags are discussed individually in the PartTypes section.

type-dependent data is information about the part. Type-dependent data is discussed in the following section.

KeyName is the optional key name to use. If no key name is specified, the previous key name in the hierarchy is used.

ValueName is the value name to use to set the data for this part.

An example of PART use follows:

PART !!MyVariable	FLAG(s)  {one or more, defined later}
...
    END PART

or:

PART !!MyVariable	FLAG(s)		END PART

The valid keywords for PART are:

  • CHECKBOX
  • TEXT
  • EDITTEXT
  • NUMERIC
  • COMBOBOX
  • DROPDOWNLIST
  • LISTBOX
  • END
  • CLIENTEXT
  • PART


PartTypes

The basic ADM language allows the creation of a simple .adm file that either creates a VALUENAME of REG_DWORD type with a value of 1 or removes the value completely. Using the following modifiers can provide additional options.

TEXT

Displays a line of static (label) text. No associated registry value exists for this part type. The TEXT part type accepts no type-specific data. This is useful for displaying a description.

The only valid keyword for TEXT is END.

EDITTEXT

Displays an edit field that accepts alphanumeric text. The text is set in the registry with the REG_SZ type. The EDITTEXT part type accepts the following options:

  • DEFAULT value. Specifies the initial string to place in the edit field. If this option is not specified, the field is initially empty.
  • MAXLEN value. Specifies the maximum length of a string. The string in the edit field is limited to this length.
  • REQUIRED. Specifies that Group Policy will not allow a policy containing this part to be enabled, unless a value has been entered for this part.
  • OEMCONVERT. Sets the ES_OEMCONVERT style in the edit field so that typed text is mapped from ANSI to OEM and back. ES_OEMCONVERT converts text entered in the edit control. The text is converted from the Windows character set (ASCII) to the OEM character set and then back to the Windows set. This ensures proper character conversion when the application calls the CharToOem <JavaScript:hhobj_1.Click()> function to convert an ASCII string in the edit control to OEM characters. This style is most useful for edit controls that contain file names.

The valid keywords for EDITTEXT are:

  • KEYNAME
  • VALUENAME
  • DEFAULT
  • REQUIRED
  • MAXLENGTH
  • OEMCONVERT
  • END
  • EXPANDABLETEXT
  • CLIENTEXT

COMBOBOX

Displays a combo box. The COMBOBOX part type accepts the same options as EDITTEXT, as well as the following option:

SUGGESTIONS. Begins a list of suggestions to be placed in the drop-down list. SUGGESTIONS are separated with spaces and must be enclosed by double quotation marks when a value includes spaces. The list ends with END SUGGESTIONS.

For example:

SUGGESTIONS
  Alaska Alabama Mississippi "New York"
END SUGGESTIONS

CHECKBOX

Displays a check box. The value is set in the registry with the REG_DWORD type. The value will be nonzero if the check box is selected by the user and zero if it is cleared. The CHECKBOX part type accepts the following options:

  • ACTIONLISTOFF. Specifies an optional action list to be used if the check box is cleared.
  • ACTIONLISTON. Specifies an optional action list to be used if the check box is selected.
  • DEFCHECKED. Causes the check box to be initially selected.
  • VALUEOFF. Overrides the default "off" behavior of the check box if specified.
  • VALUEON. Overrides the default "on" behavior of the check box if specified.

The default behavior of a check box is to write the value 1 to the registry if it is selected and 0 if it is cleared. VALUEON and VALUEOFF are used to override this behavior. For example, the following option writes "Fred" to the registry when the check box is selected.

VALUEON "Fred"

The following option writes the value 12 to the registry when the check box is cleared.

VALUEOFF NUMERIC 12

The valid keywords for CHECKBOX are:

  • KEYNAME
  • VALUENAME
  • VALUEON
  • VALUEOFF
  • ACTIONLISTON
  • ACTIONLISTOFF
  • DEFCHECKED
  • CLIENTEXT
  • END

DROPDOWNLIST

Displays a combo box with a drop-down list style. The user can choose from only one of the entries supplied. The main advantage of a combo box with a drop-down list is that a number of extra registry edits can be specified, based on the user's selection. The DROPDOWNLIST part type accepts the ITEMLIST and REQUIRED options.

  • ITEMLIST. Begins a list of the items in the drop-down list. The list must end with END ITEMLIST.

    • Each item in the ITEMLIST option must be specified as follows:

    NAME name VALUE value
    [ACTIONLIST actionlist]
    ...

    where:

    name is the text to be displayed in the drop-down list for this item.

    value is the value to be written as the part's value if this item is selected. Values are assumed to be strings unless they are preceded by NUMERIC. The following example shows both string and numeric values.

    VALUE "Some value"
    VALUE NUMERIC 1

    If VALUE is followed by DELETE (for example, VALUE DELETE), the registry value name and value pair will be deleted.

    actionlist is the optional action list to be used if this value is selected.

  • REQUIRED specifies that Group Policy will not allow a policy containing this part to be enabled unless a value has been entered for the part.

The valid keywords for DROPDOWNLIST are:

  • KEYNAME
  • VALUENAME
  • REQUIRED
  • ITEMLIST
  • END
  • NOSORT
  • CLIENTEXT

LISTBOX

Displays a list box with Add and Remove buttons. This is the only part type that can be used to manage multiple values under one key. The VALUENAME option cannot be used with the LISTBOX part type because there is no single value name associated with this type. By default, only one column appears in the list box, and for each entry a value is created whose name and value are the same. For instance, a "Fred" entry in the list box would create a value named fred whose data was "fred".

The LISTBOX part type accepts the following options:

  • ADDITIVE. By default, the content of list boxes overrides any values set in the target registry. This means that a control value is inserted in the policy file, which causes existing values to be deleted before the values set in the policy file are merged. If this option is specified, existing values are not deleted and the values set in the list box will be in addition to whatever values exist in the target registry.
  • EXPLICITVALUE. This option makes the user specify the value data and the value name. The list box shows two columns, one for the name and one for the data. Note that this option cannot be used with the VALUEPREFIX option.
  • VALUEPREFIX prefix. The prefix you specify is used in determining value names. If a prefix is specified, the prefix and an incremented integer are used instead of the default value-naming scheme described previously. For example, a prefix of "SomeName" will generate the value names SomeName1, SomeName2, and so on. The prefix can be empty (""), which will cause the value names to be 1, 2, and so on.

The valid keywords for LISTBOX are:

  • KEYNAME
  • VALUEPREFIX
  • ADDITIVE
  • NOSORT
  • EXPLICITVALUE
  • EXPANDABLETEXT
  • END
  • CLIENTEXT


NUMERIC

Displays an edit field with an optional spinner control (an up-down control) that accepts a numeric value. The value is set in the registry with the REG_DWORD type.

The NUMERIC part type accepts the following options:

  • DEFAULT value. Specifies the initial numeric value for the edit field. If this option is not specified, the field is initially empty.
  • MAX value. Specifies the maximum value for the number. The default value is 9999.
  • MIN value. Specifies the minimum value for the number. The default value is 0.
  • REQUIRED. Specifies that Group Policy will not allow a policy containing this part to be enabled unless a value has been entered for this part.
  • SPIN value. Specifies increments to use for the spinner control.
  • SPIN 0 removes the spinner control. SPIN 1 is the default.
  • TXTCONVERT writes values as REG_SZ strings ("1," "2," or "128") rather than as binary values.

For example:

PART !!MyVariable	NUMERIC
VALUENAME ValueToBeChanged
END PART

The valid keywords for NUMERIC are:

  • KEYNAME
  • VALUENAME
  • MIN
  • MAX
  • SPIN
  • DEFAULT
  • REQUIRED
  • TXTCONVERT
  • END
  • CLIENTEXT

TEXT

Displays text only.

For example:

PART !!MyVariable	TEXT
END PART

NUMERIC

Writes a value to registry with data type REG_DWORD. This is the default unless another type is specified.

For example:

PART !!MyVariable	NUMERIC
VALUENAME ValueToBeChanged
END PART

EXPANDABLETEXT

Writes a value to registry with data type REG_EXPAND_SZ.

For example:

PART !!MyVariable	EDITTEXT EXPANDABLETEXT
VALUENAME ValueToBeChanged
END PART

EDITTEXT

Writes a value to the registry with data type REG_SZ.

For example:

PART !!MyVariable	EDITTEXT
VALUENAME ValueToBeChanged
END PART

REQUIRED

Generates an error if the user does not enter a value when required.

For example:

PART !!MyVariable	EDITTEXT REQUIRED
VALUENAME ValueToBeChanged
END PART

MAXLEN

Specifies maximum length of text.

For example:

PART !!MyVariable	EDITTEXT
VALUENAME ValueToBeChanged
MAXLEN 4
END PART

DEFAULT

Specifies a default value. This can be used for text or numeric data.

For example:

PART !!MyVariable	EDITTEXT
DEFAULT !!MySampleText
VALUENAME ValueToBeChanged
END PART

or:

PART !!MyVariable	NUMERIC
DEFAULT 5
VALUENAME ValueToBeChanged
END PART

MIN/MAX

Specifies lowest and highest valid values.

For example:

PART !!MyVariable	NUMERIC
MIN 100 MAX 999 DEFAULT 55
VALUENAME ValueToBeChanged
END PART

DROPDOWNLIST

Displays a list box of options from which to choose.

For example:

PART !!MyVariable 	DROPDOWNLIST
VALUENAME ValueToBeChanged
  ITEMLIST
    NAME "First"	VALUE NUMERIC 1
    NAME "Second" VALUE NUMERIC 2
    NAME "Third"	VALUE NUMERIC 3
    NAME "Fourth" 	VALUE NUMERIC 4
  END ITEMLIST
END PART

ACTIONLIST

Optional action list to be used if this value is selected.

ACTIONLIST can be used only as part of an ITEMLIST. See the example in the ITEMLIST section.

Two variants of ACTIONLIST exist (ACTIONLISTON and ACTIONLISTOFF), and they may be used with the POLICY tag and the CHECKBOX tag. See the example in the CHECKBOX section.


Resources

For more information about Windows 2000, see the Microsoft Windows (http://www.microsoft.com/) Web site.


Troubleshooting

An important part of troubleshooting Group Policy problems is to consider dependencies between components. For example, 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 it relies are working correctly. Event logs are useful for tracking down problems caused by this type of hierarchical dependency.

Are you having trouble using the Group Policy snap-in?

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

Cause: An administrator must have not just Read but Full Control of the Group Policy object to open it in the Group Policy console.

Solution: Be 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: Make sure DNS is working properly. For more information, see Domain name system (DNS).

Are Group Policy settings not taking effect?

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 containing that security group.

Cause: This is correct behavior. Group Policy affects only users and computers 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. Keep in mind that 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.

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 taking effect on users and computers in several ways. A Group Policy object can be disabled from affecting users, computers, or both. It also needs to be linked either directly to an organizational unit containing the users and computers, or 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 applied later have precedence. In addition, Group Policy can be blocked at the level of any organizational unit, or enforced through a setting of No Override applied to a particular Group Policy object link.

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

Solution: Make sure that the intended policy is not being blocked.

Make sure no overriding policy set at a higher level of Active Directory has been set to No Override.

If Block and No Override are both used, keep in mind that No Override takes precedence.

Verify that the user or computer is not a member of any security group for which the Apply Group Policy 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 ACE is set to Allow.

Verify that the user or computer is a member of at least one security group for which the Read ACE is set to Allow.

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.

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.

Are you having trouble with the Software Installation snap-in?

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

Cause: Several causes are possible:

  • Group Policy was not applied.
  • Active Directory cannot be accessed.
  • User does not have any published applications in the Group Policy objects that apply to them.
  • Client is running Terminal Server.

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

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

Cause: The administrator did not set autoinstall.

Solution: See To set autoinstall 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: Make sure the network is working correctly. Also see To set permissions for installing software, particularly the second note at the bottom of the page.

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

Cause: The user has created shortcuts, and Windows Installer has no knowledge of them.

Solution: The user needs to 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 the 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: Investigate and take appropriate action.

Note

  • For current information on troubleshooting, visit the Microsoft Personal Support Site on the World Wide Web. (http://support.microsoft.com)