Normally, administrators use a Windows 2000 Active Directory to distribute Group Policy settings. In this situation, the administrator creates Group Policy objects which contain policy settings, and then uses Active Directory to target the delivery and application of these settings. When you use Windows 2000 clients in an environment where there is no Active Directory, you can distribute policy settings using Windows NT 4.0-style system policies or Local Group Policy.
- If the needed settings are available for editing with the Poledit.exe tool, administrators can create a policy on a Windows 2000-based server with the Poledit tool and save it as a Ntconfig.pol file. On the user's workstation, the administrator has to modify the NetworkPath registry value in the following location:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update\NetworkPathIf this value does not exist, the value must be added as a REG_SZ data type. For example, if the policy file is named Ntconfig.pol and it is saved in the shared Directory \Policies on a Windows NT server, the value of NetworkPath should contain the following universal naming convention (UNC) path: \\Servername\Policies\Ntconfig.pol.
After adding the above registry entry modify the registry entry UpdateMode(same location in the registry) to a value of 2. This sets the workstation to Manual Update mode which is what you are setting by specifying the registry information above. If this entry, UpdateMode, is not changed the workstation stays in Automatic mode which means that it will look for the NTCONFIG.pol file in the default location versus the location you have specified. For additional information about this, click the article number below to view the article in the Microsoft Knowledge Base:168231 System Policies Are Not Applied in Windows NTWhen the users log on to the workstation, Windows 2000 can read the policy file specified by NetworkPath, and then apply the appropriate policy to the computer or user.
- If the settings that the administrator wants to enable are available on the user and computer level from the Group Policy Microsoft Management Console (MMC) snap-in, the administrator should use Local Machine policies. Since it may be difficult to visit each client to distribute and configure Local Group Policy, you can use the following two methods to configure Local Group Policy on multiple clients:
- Local Group Policy can be configured for a single system; then it can be cloned. The Microsoft System Preparation (Sysprep) tool can be used in conjunction with other third-party software to clone the computers. The cloned computers can retain the settings.
- Administrators can also configure a Local Group Policy on one client computer, and then copy the associate's pieces that make up the Local Group Policy Object (LGPO) to other clients.
NOTE: The only settings you can transfer from one client to another are the settings from Administrative Templates.
- At the client requiring the policy settings, log on as an administrator and run the Group Policy snap-in (the Gpedit.msc file). Then focus the Group Policy snap-in on the Local Group Policy of the client.
- Configure the LGPO on the client.
- Edit and configure the policy settings you require.
- Take the entries found in the Local Group Policy Object which are stored in the %Systemroot%\System32\GroupPolicy folder, and then copy them to other clients where you also want to apply these Local Group Policy settings.
NOTE: The settings under User Configuration can normally take effect the next time the user logs on and the settings under Computer Configuration can normally take effect when you restart your system.
- It may be necesary to edit the %systemroot%\system32\grouppolicy\gpt.ini and change the version entry so that the policy gets applied.
Security permissions on this folder can be changed to deny access to administrators to ensure that the policy does not apply to the local administrators.
If you use the preceding method, you must exercise much care because anything that is set on the original system that is specific to that particular computer is unsuccessful on the new target computer. In particular, many of the security settings for the computer should be avoided. If you are only interested in the administrative templates settings, copy the Registry.pol file to the target computer.
The method of setting the access control lists (ACLs) on the folder to prevent the local administrators from being affected can work with any local built-in group as well. When a change to the policy settings is required, the local administrator must take ownership, change the ACLs, make the change to the LGPO, and then change the ACLs back to deny for the local administrator. A failure to do this when combined with a certain set of policies could make it impossible to make any further changes.
Consider, for example, if the "Disable registry editing tools" or "Take ownership of files or other objects" policy is set and the "Deny access to this computer from the network" policy is set. This can lead to a situation where administrators can find themselves locked out of a system.
In general, to avoid problems, be aware of the following suggestions:
- Each setting variance needs to be methodically tested prior to implementation.
- An administrator's strategy must be based on all clients having remote network access with Windows 2000.
Article ID: 274478 - Last Review: Mar 15, 2008 - Revision: 1