Is it possible to Export the Local Group Policy Settings?

Posted on 2003-11-21
Medium Priority
Last Modified: 2010-08-05
I am trying to Export the settings so that I may be able to import them into several other clients. I am running a 30 station workgroup. We are avoiding a domain considering the costs involved...

I apperciate any thoughts that gos into this...
Question by:c0rrupti0n
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
LVL 57

Accepted Solution

Pete Long earned 200 total points
ID: 9797142
Yes use an administrative template


This article explains how to apply group policies to Microsoft Windows 2000 Professional-based computers which are installed in a Microsoft Windows NT 4.0 domain or in a workgroup.
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

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:

If 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 NT

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

To edit the LGPO and to configure Local Group Policy settings on a local computer, and then to distribute to other computers, you need to perform the following steps:
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.
The preceding settings are stored in the LGPO on that client. If this client later joins a Windows 2000 Active Directory, Active Directory can override the settings in the LGPO using Group Policy distributed from Active Directory.

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.

Author Comment

ID: 10047449
I thank you for your help... I ended up modifying one machine and exporting the local policy to each other.

LVL 57

Expert Comment

by:Pete Long
ID: 10054334

Featured Post

U.S. Department of Agriculture and Acronis Access

With the new era of mobile computing, smartphones and tablets, wireless communications and cloud services, the USDA sought to take advantage of a mobilized workforce and the blurring lines between personal and corporate computing resources.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
In today's business world, data is more important than ever for informing marketing campaigns. Accessing and using data, however, may not come naturally to some creative marketing professionals. Here are four tips for adapting to wield data for insi…
Monitoring a network: how to monitor network services and why? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the philosophy behind service monitoring and why a handshake validation is critical in network monitoring. Software utilized …
In this video, Percona Solution Engineer Rick Golba discuss how (and why) you implement high availability in a database environment. To discuss how Percona Consulting can help with your design and architecture needs for your database and infrastr…
Suggested Courses
Course of the Month8 days, 20 hours left to enroll

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question