Microsoft

Working with Windows 2000 local group policies

Group policies can be one of the most powerful and confusing things in Windows 2000. Troy Thompson focuses on one of the key group policies you can work with: local group policies.


In the Daily Drill Down titled “Understanding Windows 2000 group policies,” Jim Boyce introduced you to group policies that you can implement on your Windows 2000 server. One of the group policies he introduced you to was the local group policy. In this Daily Drill Down, I’ll focus on the Windows 2000 local group policy and setting policies that affect individual computers or users.

What is a group policy?
Each Windows 2000 computer has one local group policy object stored locally. Using this feature, you can create a security policy for users and computers in your organization that is simple and easy to manage.

Group policy settings give a system administrator the ability to control various components of the user's environment. Group policies can control the programs that are available to users and the programs that appear on the user's desktop and Start menu options. Group policies include settings that can affect users or computers. If you want to create a desktop configuration for a specific group of users, you would use the Group Policy snap-in. To add an item to a new Microsoft Management Console (MMC) for a local computer, you would click Start | Run | MMC. From the Console menu, select Add/Remove Snap-In, and then click Add. In the list of snap-ins, double-click Local Computer. When you add the Group Policy snap-in to a new console, you need to confirm that the Administrative Templates (Users) check box is selected (under Available Extensions on the Extensions tab in the Add/Remove Snap-In dialog box as shown in Figure A). This is enabled by default on a new installation of Windows 2000.

Figure A
When you add the Group Policy snap-in, make sure the Administrative Templates (Users) check box is selected.


Group policy settings are contained in a group policy object (GPO), which is associated with selected Active Directory objects. Group Policy extensions will allow you to manage registry-based policy, assign scripts, redirect folders, manage applications, and specify security options. Once you have loaded the snap-in, be sure to save it using the Console menu. The new MMC console will look similar to the one in Figure B.

Figure B
You can create a custom MMC using the Local Computer Policy snap-in.


How do group policies work?
A group policy creates a file that contains registry settings, which are written to the User or Local Machine portion of the registry. 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

All four trees are secure and cannot be modified by a user who is not an administrator. If a group policy changes for any reason, these trees are wiped clean, and the new policies are then rewritten.

There are two kinds of GPOs: Non-Local and Local. GPOs are stored on a domain controller and are available only in an Active Directory environment. They apply to users and computers in the site, domain, or organizational unit with which the GPO is associated. Local GPOs discussed in this article are stored on each computer running Windows 2000. Only one Local GPO exists on a computer, and it has a subset of the settings available in a Non-Local GPO. Local GPO settings can be overwritten by Non-Local settings if they are in conflict; otherwise, both apply.

If a user has a policy that is applied to him, when he logs on, his policy will overwrite a portion of the registry. If a computer has a policy applied to it, it doesn’t matter who logs on, the policy for that computer will be applied. It is possible to have more than one policy apply to a user or computer. By default, policies that are applied later will overwrite previously applied policies when the policies are inconsistent. However, if the settings in the different policies are not inconsistent, both policies will contribute to the effective policy.

Order of group policy settings
Group policy settings are processed in the following order:
  • Local GPO—Each Windows 2000 computer has exactly one GPO stored locally.
  • Site—Any GPOs that have been linked to the site are processed next. Processing is synchronous and in an order specified by the administrator.
  • Domain—Multiple domain-linked GPOs are processed synchronously and in an order specified by the administrator.
  • Organizational units—GPOs linked to the organizational unit highest in the Active Directory hierarchy are processed first, then GPOs linked to its child organizational unit, and so on. Finally, the GPOs linked to the organizational unit that contains the user or computer are processed.

Group policies are always processed in this order unless you’ve set a policy to No Override with respect to the site, domain, or organizational unit to which you’ve linked the policy. This will prevent the policy settings from being overwritten. When more than one GPO has been set to No Override, the one highest in the Active Directory hierarchy takes precedence.

Comparing it to Windows NT System Policy Editor
Windows NT 4.0 used the System Policy Editor, which is similar to the group policy feature in Windows 2000 in that you can control a user’s work environment and actions and enforce system configuration settings. Using the System Policy Editor, you could define the applications available to the user, the options in the Start menu, and the icons that would appear on the desktop. If you upgrade from Windows NT, you will find that with Windows 2000, group policies are more robust and will provide a unified replacement for many of the tools with which you are familiar.

Although it is possible for a Windows NT Administrative Template (.adm file) to be added to the group policy in Windows 2000, it is not recommended. This can lead to undesirable and unpredictable results because the Windows NT policy may set registry values outside of the approved Group Policy trees.

Windows NT 4.0 policies do not respect these special trees in Windows 2000 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.

Please note that if a Windows NT 4.0 client computer managed by a Windows 2000 server is upgraded to Windows 2000, it will receive only the Computer Configuration Group Policy and not the 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, the user will get Windows NT 4.0 User System Policy.

Using group policies
There are hundreds of items that you can manage with group policies. For an example, let’s assume you want enable disk quotas for a computer. From the MMC you created, navigate the tree in the left pane to Computer Configuration/Administrative Templates/Disk Quotas. The available policies will appear in the Policy Window (Figure C). Their initial settings will be set to Not Configured.

Figure C
You can set Disk Quota Policies.


To configure a policy, double-click on the item. The property sheet will appear, allowing you to enable the policy (Figure D). You can also choose the Explain tab to get a better understanding of the policy.

Figure D
Select the Enabled radio button to enforce disk quota limits.


Once you have enabled disk quotas, you would also need to set the other policies that correspond to it. If you do not plan to configure all of the policies, you can disable those you will not use.

Inheritance
It is important to note that in a domain environment, group policies are passed down from parent to child. If you are in an organization that has policies set at the domain level, those policies can affect your local computer.

Parent policies that are not configured are not inherited, but those that are disabled at the parent level are inherited. Policies are inherited as long as they are compatible. If a parent policy and a child policy are compatible, the child inherits the parent policy, and the child's setting is also applied. 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 will see both folders. If a parent policy is not compatible with the child policy, the setting in the child is applied. You can choose to block inheritance of policies or to enforce inheritance of policies.

Making group policies efficient
Group policies are powerful tools that allow you to better manage the users and computers in your organizations. However, you must be careful not to overuse them. You should minimize the number of GPOs associated with users in domains or organizational units. The more GPOs are applied to a user, the longer it will take that user to log on.

If a GPO has only settings that are set to Not Configured, you can avoid processing those settings by disabling the node. This will expedite startup and logon for those users and computers subject to the GPO. In a domain environment, you should also use the Block Policy Inheritance and No Override features sparingly because they can make troubleshooting policies difficult.

Do not override a user-based group policy with computer-based group policy unless the desktop configuration will be the same regardless of who logs on. Also, avoid cross-domain GPO assignments. If objects are obtained from another domain, it will slow the logon and startup processes.

Another item to be aware of is that there are ways around many policies. If you disable access to the drives from My Computer, a user may still be able to access those drives and delete files from within an application such as Microsoft Word.

Creating Startup, Shutdown, Logon and Logoff Scripts
You can setup Logon/Logoff scripts for users, as well as Startup/Shutdown scripts for computers, and implement them using group policies. Once you have written the script, copy it and the dependent files to the Netlogon share (or other share) of the domain controller from which you want the script to run. Then you can configure them using the Scripts tab under the Windows Settings for Computer Configuration and for User Configuration.

You may want the computer to map a drive each time the computer is booted regardless of who logs on, or you may only want to map the drive for a specific user. You can use script files to make automatic backups, display banners, copy files, set the time, e-mail people, launch applications, etc.

Conclusion
Windows 2000 gives you many new choices in terms of setting policies. As an administrator, it is important to plan how you will take advantage of group policies.

Editor's Picks