| Downloads |
|---|
| 125265.zip |
In Group Policy, one of the key components is the registry client-side extension, which makes changes to the Group Policy Objects (GPOs) in the local computers' registries. At regular intervals or upon reboot, Group Policy compares the server's list of GPOs that applied registry settings against each local computer's list of GPOs that applied registry settings. (The lists include more than just the GPOs' names. Other details—such as the GPO version and path—are also included.) If the GPO lists match, Group Policy doesn't run the extension by default. From a performance standpoint, it doesn't make sense to run the extension to refresh the local computer's registry when nothing has changed. However, there are situations in which a local computer's registry might need to be refreshed, even though the server's GPO list and the local computer's GPO list match.
You can force a registry refresh anytime by using the Gpupdate /force command or by enabling the Process even if the Group Policy objects have not changed option. However, you might not want to force a registry refresh at each computer startup because of the extra overhead it'll cause. This is especially true when you need to force a registry refresh only once in a while. A better approach is to use a one-time Group Policy registry refresh. A good example of when you might want to use this is after you install software that modifies some registry settings that are currently being managed through a GPO. As far as Group Policy is concerned, nothing has changed, even though the software has overwritten the registry settings. By triggering a one-time registry refresh, any settings that were overwritten during the software's installation will be set back to the way they should be.
Triggering a Refresh by Changing History
You can accomplish a one-time registry refresh by changing the local computer's Group Policy history. That way, at the next reboot or Group Policy refresh, Group Policy will detect a mismatch between the server's and the local computer's GPO lists and run the registry client-side extension.
On a server, Group Policy gets the GPO list from Active Directory (AD). On a local computer, Group Policy gets the GPO list from the registry. Specifically, information about the GPOs applied by the registry client-side extension is written to the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\\\{35378EAC-683F-11D2-A89A-00C04FBBCFA2\\} key. The number in the brackets is that extension's globally unique identifier (GUID). You can obtain a list of the GUIDs for the other basic Group Policy client-side extensions in the Microsoft article "Identifying Group Policy Client-Side Extensions". Although this article was written for Windows 2000, the GUIDs are the same for later versions of Windows.
Each subkey under the \\{35378EAC-683F-11D2-A89A-00C04FBBCFA2\\} registry key represents a GPO. The order of the subkeys indicates the order in which the GPOs were applied. The entries in each GPO subkey contain such details as the GPO's name, version, and path.
Rearranging the order of the subkeys, changing the GPO version information in any one of them, or making any other significant modification will change the local computer's GPO list. This means that the server's GPO list won't match local computer's GPO list, forcing the registry client-side extension to re-apply the registry settings at the next reboot or the next Group Policy refresh, which is every 90 minutes by default.
I've found that the easiest way to trigger a one-time registry refresh is to simply remove the entire first subkey under the \\{35378EAC-683F-11D2-A89A-00C04FBBCFA2\\} key, which will always be named 0, as Figure 1 shows.
If you have any registry policy settings defined in a Local Group Policy, the 0 subkey represents the Local Group Policy. If not, the 0 subkey represents the first GPO that applied registry settings from AD.
I wrote a VBScript script, TriggerGPORegistryRefresh.vbs, that deletes the 0 subkey. You need administrative rights to run this script. After you run it, the registry client-side extension will refresh the registry at the next reboot or the next Group Policy refresh.
Testing the Script
You should always test scripts before you use them in a production environment. To test and see TriggerGPORegistryRefresh.vbs in action, you can enable the registry's user environment debug logging functionality, which logs messages in the userenv.log file, on a test computer. (If you’re unfamiliar with how to enable this functionality, see http://support.microsoft.com/kb/221833.) When Group Policy registry settings haven't changed so no refresh occurred (and there were no settings to force a change), you'll see the following message in the userenv.log file:
Read extension Registry
Read Extension's Previous status successfully
The lists are the same.
No GPO changes and no security group membership change and extension Registry has NoGPOChanges set.
When you see this message, run TriggerGPORegistryRefresh.vbs and reboot the computer. Go back into the userenv.log file. It will now show the following message:
Read extension Registry
Read Extension's Previous status successfully
One list is empty.
Entering for extension Registry
The line "One list is empty" indicates that the script successfully triggered a registry refresh.
Another way to test and see TriggerGPORegistryRefresh.vbs in action is to follow these steps:
- On a test computer, find a nonpolicy registry setting that was previously configured by a GPO. By "nonpolicy" registry setting, I mean a registry preference setting that:
• Doesn't reside under the HKLM\Software\Policies key
or the HKLM\Software\Microsoft\Windows\CurrentVersion\Policies key.
Because it's not under a Policies key, it's considered a preference.
• Stays behind when the GPO that applied it is no longer used. - For the nonpolicy registry setting you selected in step 1, replace the existing value (which we will consider as the correct one) with a new value (which we will consider as the incorrect one) in the registry.
- Reboot the computer, then check the value of the nonpolicy registry setting you changed. You'll still see the new incorrect value, provided there were no GPOs applied elsewhere to cause the registry client-side extension to perform a registry refresh for that computer.
- Run TriggerGPORegistryRefresh.vbs on the test computer.
- Reboot the computer, then check the value of the nonpolicy registry setting you changed. You should now see the old correct value rather than the updated incorrect one.
Figure 2 shows an example of this kind of registry setting.
Using the Script
If you're going to install a software package in your AD environment that might overwrite some nonpolicy registry settings that are currently being managed through GPOs, you can use the code in Listing 1 as the last step of the installation process. You can download TriggerGPORegistryRefresh.vbs by clicking the Download the Code Here button.
Listing 1: TriggerGPORegistryRefresh.vbs
Option Explicit
Const REGROOT = "HKLM"
Const TITLE = "Trigger Registry Policy Processing"
Const REGHIST = "Software\Microsoft\Windows\CurrentVersion\" & _
"Group Policy\History\\\{35378EAC-683F-11D2-A89A-00C04FBBCFA2\\}"
Dim objShell, strCommand
Set objShell = CreateObject("WScript.Shell")
strCommand = "REG DELETE """ & REGROOT & "\" & REGHIST & "\0"" /F"
objShell.Run strCommand, 0, True
Another way to force a one-time Group Policy registry refresh on all computers in an AD organizational unit (OU) is to link a "toggle" GPO that does only one thing: Sets a single GPO registry setting to the same value that's already being managed through another GPO. That way, when you enable the link in AD, the "toggle" GPO will now be on the list of GPOs for registry processing, causing a mismatch between each local computer's GPO list and the server's GPO list. In 90 minutes or so, Group Policy will notice the mismatch and have the registry client-side extension perform a one-time registry refresh.
You can leave the "toggle" GPO linked and enabled until the next time you need to trigger a registry refresh. Then all you need to do is disable the GPO link in AD, which will trigger another mismatch between the GPO lists and hence another registry refresh. You can toggle the GPO on and off whenever you feel the need to ensure a one-time registry refresh.
