Back to Posts

Quickly verifying that Group Policy was applied to users with ControlUp registry controller

Systems administrators who are responsible for configuring and troubleshooting Group Policy are familiar with the uncertainty involved in this task. Once configured, a Group Policy Object is supposed to start affecting users and/or computers, but there is no quick and easy way to ensure that Group Policy is indeed active and working as expected. So instead of hoping for the best and waiting for frustrated users to call support, here’s an advanced method that will allow a thorough systems administrator to make a real-time comparison among multiple logged-on user sessions and determine whether a given Group Policy setting is correctly propagated to their desktops.
As you may know, a Group Policy setting applied to a user eventually modifies the user’s registry (the HKEY_CURRENT_USER or HKCU). Using windows administrative templates (ADMs) and ControlUp Registry Controller you can quickly compare the HKCU of many logged-on users. This is basically like opening dozens (or even hundreds) instances of Registry Editor in parallel, except ControlUp allows you to spot the differences almost instantly.

Step 1: Locating the registry key of a specific policy setting

Let’s say, for example, that yesterday you configured a GPO to disable Internet Explorer’s “Tools” / ”Options” menu and you now need to verify that the setting has been actually applied to the relevant users.

The first step would be to find the exact registry key that is associated with this setting. First, note the exact text of the setting. In our example, it is “Tools menu: Disable Internet Options…”.

At this point, we’re after the registry setting that this policy affects. It’s worth trying to Google the setting name followed by the word “registry”, since it’s rarely the case that you are the first one looking for the answer online. My first search result was this page, which gave me the desired registry value name right away. If you were as lucky as me finding the exact location, just jump right to Step 2.

The next step would be to locate the directory containing the ADM/ADMX files. In order to do so, use Group Policy Management Console (GPMC) to select the GPO and note the ‘Unique ID’ of the GPO you just set:

Now, open the following directory:

%logonserver%\sysvol\<domain FQDN>\Policies\<Unique ID>\adm

One of the ADM/X files in this location contains the relevant setting we’re after.

In order to find the exact files you can either guess (since our setting is relevant to Internet Explorer, our file is inetres.adm), or search the string noted in the first step as text within the file (If you use Windows 7, you will first have to perform THIS STEP before you can search by file content)

After we found the file, we can open it using notepad and search for our string within the file:

The string will be found in a section of the ADM file called ‘strings’. This section maps short setting name to their friendly name which is displayed in the Policy Editor MMC.

The next step would be to look for the short name of our policy. In this example: ‘ Tools_Menu’

Make sure you set the search direction to ‘Up’ because the ‘strings’ section is always on the bottom of the ADM file.
This is how it looks:

Note the VALUENAME parameter – this is the Registry value we’re after.

Last thing we need is to locate the Registry Key in which this value should reside.

In order to do so, look for the string ‘CATEGORY’ (use Match case) while searching upward:

A couple of lines under the ‘CATEGORY’, you will find the ‘KEYNAME’. In our example it is Software\Policies\Microsoft\Internet Explorer\Restrictions.
Since this is a ‘User’ setting, the registry hive is HKEY_CURRENT_USER.
So, no we know the exact registry value which causes Internet Explorer to hide the Options -> Internet Settings menu. It is:
HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\Restrictions\NoBrowserOptions
and we are expecting this value to be 1 if the policy is enabled (options menu removed).

Step 2: Using ControlUp’s Registry Controller to quickly find users with and without the policy

ControlUp’s Registry Controller offers a quick way to compare and spot registry differences on multiple computers’ or users’ hives simultaneously.

Open Controlup and connect to computers that has the users you want to verify. In the Sessions view, you see all the users that are currently logged on. Select the users you want to compare (or CTRL+A for all of them).

Once the users are selected, right click to get to the context menu and select the registry controller.

The Registry Controller open with an aggregated view of HKEY_CURRENT_USER hive for all users you have selected.

All you need to do is simply browse to the required registry key and select it:

Tip – If the registry key appears in YELLOW, it means that all users have it. If it appears as BLUE, it means that some have it and some don’t.
Now, drag the ‘Exist’ column on the right-most pane to the grouping area:

Voila! We found the one user who didn’t get the setting!
In this example, we compared the key of 322 users. You can see that 321 users have the key, but there is one that didn’t.
Although the registry key exist, it is possible that some users don’t have the registry value. In order to ensure that, simply select the value ‘NoBrowserOptions’ on the ‘Registry Values’ pane.
You will now see the actual data for each user. You can group by the ‘Data’ column and verify that everyone have the same value.

In this example you can see that one of the users has a 0 value, meaning that the restriction does not apply to him:

So, it looks like this user, ‘taphar’, didn’t get the restriction.

Step 3: Refreshing a user’s Group Policy remotely

Before checking for a policy misconfiguration, we can try to refresh policy for that specific user and see if it helps.

Simply switch to ControlUp’s “My Organization” pane, locate the rebel user’s session, right click on it and select Group Policy -> Refresh Policy:

Now, return to the Registry Controller, hit the “Refresh” button and you can see that Group Policy is refreshed and that the user’s session is now affected by the Group Policy restriction.

Summary

What we did here may take a few minutes of concentration and scrutiny, but it can save hours of troubleshooting. For example, if you have a few affected users out of several hundreds, poking around with tools like Registry Editor and Resultant Set of Policy (RSoP) will be extremely time-consuming and frustrating. The basic problem with classic Windows management tools is that they were never suited for multi-user environments, which is the reason we turned to ControlUp. It allowed us to locate an irregularity quickly and easily, which is already a big step towards resolving the issue. ControlUp’s “Refresh Group Policy” action (demonstrated in this video) is a great tool that allows an administrator to update an end user’s Group Policy environment without bugging the user to log off or otherwise interrupting their work.

Leave a Reply

Your email address will not be published. Required fields are marked *