Local Group Policy objects (LGPOs) cannot be managed using GPMC. They are visible only in the GPMC as the result of RSoP logging reports that include LGPO settings that have been applied as part of normal policy processing. You can, however, access your computer’s LGPO at any time by simply typing gpedit.msc at a command line. You can access a remote computer’s LGPO by following the steps discussed in Chapter 2 under "Accessing Local Group Policy on a Remote Machine"
When you perform a clean install of a new machine running Windows XP Professional or Windows Server 2003, there is initially no LGPO. The LGPO is created the first time you try to put settings in the LGPO. For example, if you try to view the LGPO by running Gpedit.msc, the LGPO is instantiated and a special Group Policy folder (%Windir%System32GroupPolicy) is created as well . Further, on machines without an LGPO, the LGPO is not processed during foreground or background policy processing. Policy application from LGPO only happens when there are some settings in the LGPO (indicated by Gpt.ini having a nonzero version number).
While editing the LGPO settings on a computer running Windows XP or later, you might find that some settings are dimmed. This can occur because policy settings enabled or disabled through domain-based policy cannot be overridden by LGPO settings. In Windows 2000, you were allowed to configure the LGPO settings that would be overridden by site, domain, or OU policy. In Windows XP Professional and later, those settings are dimmed in the interface because no policy setting change you can make locally will override site, domain, or OU policy.
The LGPO is not affected in any way by settings in other GPOs. If you enable or disable a setting anywhere in the domain, it will not impact what you see in the LGPO. The settings you see in the LGPO are simply whatever settings that administrator set in the LGPO.
Local GPOs are structured a bit differently than Active Directory–based GPOs. The LGPO is stored on the local file system of your Windows computer—specifically, within the %Windir%System32GroupPolicy folder. If you examine the LGPO on a given Windows computer, you will notice that its file structure is similar to that found within the GPT for an Active Directory–based GPO. There are the familiar ADM, Machine, and User folders as well as the Gpt.ini file that holds version information for the LGPO.
The gPCMachineExtensionNames and gPCMachineUserNames attributes, which are unique to the Gpt.ini file on the LGPO, are stored within this file because there is no GPC available to store them. These attributes serve the same purpose as their Active Directory counterparts. They tell Group Policy processing which CSEs should be run on the local GPO based on which policy areas have been set.
If you drill into the Machine or User folders under the GroupPolicy folder, you will find a Registry.pol file that contains Administrative Templates policy settings. Also, if you’ve defined machine or user scripts, you will see a scripts directory that contains subfolders for startup, shutdown, logon, and logoff scripts. However, if you define security policy on the local GPO, the changes are made directly to the local machine’s security database rather than stored in a file within the GroupPolicy folder or elsewhere. The security database is stored in the Secedit.sdb file in the %WindorSecurityDatabase folder.
Because the LGPO cannot be managed by the GPMC, you cannot perform many of the management tasks that are supported by the GPMC. Chief among these tasks is the ability to back up and copy the LGPO between computers. While there is no supported mechanism for copying the LGPO, most LGPO settings are merely files on a computer’s local file system, so you can usually copy them between computers without too much trouble.
Specifically, if you have made some changes to a LGPO on one computer and you need to propagate those changes to other computers but you don’t have the ability to deploy Active Directory–the preferred mechanism for Group Policy deployment—you can copy the contents of %Windir%System32GroupPolicy between computers using a simple copy command, where NewComputer is the name of the computer to which you want to copy the local policy settings:
xcopy %windir%system32GroupPolicy \NewComputeradmin$system32GroupPolicy /eYou don’t need to copy the entire set of policy between computers. You can copy only part of the policy settings. For example, if you want to copy the local Administrative Templates settings between computers, you can do this by copying the Registry.pol file. Similarly, if you defined a startup script in the LGPO on Computer A and want to propagate that startup script to other computers in your environment, you can simply copy the contents of %Windir%System32GroupPolicyUserScriptsLogon (including the Scripts.ini file) to the remote machines and the script will be deployed. You would also need to modify the Gpt.ini on the target machine to list the proper CSEs in the extensions list.
If you need to copy security policy between local computers, you can do this by copying the security database (Secedit.sdb), located in %windir%securitydatabase. Because not all security-related changes are in the security database, however, you might want to create a security template file that represents your local security policy and then use the Secedit.exe utility to apply that template to all of your computers instead. See Chapter 15 for more details about customizing security templates.
Tip
Any time you work with the LGPO, you must ensure that the related Gpt.ini has a version number greater than 0. For example, if you copy a Registry.pol file from one computer’s LGPO to another computer that has not had any Local Group Policy defined, the version number on that LGPO will be 0. If this number isn’t changed, the LGPO will be skipped during Group Policy processing. Therefore, it’s a good idea to increment the version number within the Gpt.ini file so it is greater than 0 and greater than it was during the last processing cycle. Otherwise, your new policy settings will never be processed.
Restricting computer access to the LGPO has no meaning because, by definition, only one computer can process the LGPO. On the other hand, you might need to control which users will process a local GPO. Unfortunately, there isn’t a Group Policy editing tool for managing the delegation and security filtering on LGPOs.
A limited way to manage security on LGPOs is to modify the NTFS permissions on the files that make up the LGPO. For example, if you don’t want desktop restrictions to apply to local administrators, you can prevent administrative users from processing Administrative Templates policy—the Registry.pol file.
The Registry.pol file is found in the %Windir%System32GroupPolicyUser folders. By default, this file grants Administrators Full Control rights over the file. By removing Read permissions for Administrators, you effectively prevent local administrators from being able to read, and thus process, the Registry.pol file. By allowing Write permission, you ensure that Administrators still have access to Administrative Templates policy for editing purposes.
Note
Controlling access to the LGPO is relevant only for users who log on to a computer using local credentials. If a domain user logs on to a computer, you can, of course, use domain-based GPOs to manage that user.
Tip
You can modify NTFS permissions on other policy files (including scripts and Internet Explorer maintenance policy) just as easily. Keep in mind, however, that this approach is not very manageable. It is always risky to modify the default permissions, and if you make a mistake, you might prevent critical policy settings from being applied. For this reason, always thoroughly test any changes you make before deploying them in production.