Nigel Boulton's Blog
31Jan/126

Tracking down registry changes made by Group Policy Objects

I was troubleshooting an issue a week or so ago in conjunction with a Citrix Technical Support Engineer, and thought I would blog a handy tip that my esteemed colleague Phil Reeve pointed out to me, which assisted in tracking down the problem.

So, let me set the scene for you. We had discovered a problem where one of our Citrix Web Interfaces was no longer notifying users of the impending requirement to change their password, during the period prior to the date on which they would be forced to do so by Active Directory.

Citrix Technical Support had been working on this problem on our behalf for a few weeks, and had been able to reproduce it successfully. I won't go into great detail here, as this is a post about troubleshooting Group Policy and not Citrix problems – suffice to say that Citrix had narrowed it down to an incorrectly set registry value on a Citrix Zone Data Collector (ZDC) that the Web Interface was reading and processing.

The value in question was HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\passwordexpirywarning. On the ZDC, it had been incorrectly set to 0. The next challenge was to find out what had done this in order to be able to change it back to the correct value, and make it stay that way.

The "passwordexpirywarning" value can be set by local or Active Directory Group Policy via the setting "Interactive Logon: Prompt user to change password before expiration". A quick check in the Local Group Policy Editor (gpedit.msc) on the affected ZDC indicated it was being set by Active Directory Group Policy, as it was greyed out:

PromptUserSetByGPO

So how to track down which Group Policy Object (GPO) was applying this incorrect value? "Try GPResult.exe or the Group Policy Results Wizard in the GPMC" I hear you shout! Of course, I tried these tools, but to no avail, as they have a "limitation" (shall we call it?) in that they don't reliably show all the registry values that Group Policy processes – and this was one such case. I have seen the same thing many a time over the years I have been working with Active Directory, and to be honest, am quite surprised that this is still the case after all this time.

So finally, to the point of this post. Below is the tip I mentioned, in the form of a procedure that can be used should you find yourself in a similar position (paths and GUIDs have been changed to protect the innocent!).

1. Open a Windows Explorer window on your domain's Sysvol folder. This will be something like "\\mydomain.com\Sysvol\mydomain.com"

2. In the Explorer Search field in this window, type the name of the registry value you are working with (in my case "passwordexpirywarning")

SearchResultsNotFound

3. Press Enter and wait for the search to complete – it won't find anything, so you will then need to click Search in File Contents. Once the search completes, you should have one or more GptTmpl.inf files returned in the results, as shown below:

SearchResults

4. Open each of these files in turn in Notepad (or your preferred text editor), and search each for the registry value in question:

SearchInFile

In the above screenshot, you can see that this is a "candidate" GPO as it is setting "passwordexpirywarning" to 0. Ignore any files that don't correspond to the value you are interested in

5. For each of the corresponding GptTmpl.inf files that contain the value in question, obtain the GPO GUID (Globally Unique Identifier) by inspecting the properties of the GptTmpl.inf file, as shown below, and copying and pasting the GUID part of the path, EXCLUDING the curly brackets {} into a temporary text file:

GetGPOGUID

The aim of this is to build up a list of GUIDs for candidate GPOs

6. Now, if you are not already on a Windows 2008 R2 server with PowerShell and the Group Policy Management Console (GPMC) installed, log on to one, and open a PowerShell session

7. In the PowerShell session, type the following command:

Import-Module GroupPolicy

followed by

Get-GPO -GUID <GUID>

where <GUID> is the first GUID you collected in the text file above, for example

Get-GPO -GUID AD77FD0E-3E55-4B7B-AD7A-2C6B4E680F80

This should return the display name of the GPO corresponding to this GUID, as shown below:

PS C:\> Import-Module GroupPolicy
PS C:\> Get-GPO -GUID AD77FD0E-3E55-4B7B-AD7A-2C6B4E680F80

DisplayName      : Terminal Server Security Policy
DomainName       : mydomain.com
Owner            :
Id               : ad77fd0e-3e55-4b7b-ad7a-2c6b4e680f80
GpoStatus        : AllSettingsEnabled
Description      :
CreationTime     : 08/01/2011 11:17:44
ModificationTime : 27/01/2012 10:48:26
UserVersion      : AD Version: 1, SysVol Version: 1
ComputerVersion  : AD Version: 25, SysVol Version: 25
WmiFilter        :

PS C:\>

8. Copy the display name of the GPO into a text file and repeat the Get-GPO command for each of the other GUIDs you collected in the previous text file, collecting each GPO's name in the new text file as you go

All that remains is to determine which of these GPOs are applied to the affected machine:

9. Log on to the affected machine as an administrator and run gpresult /v > gpresult.txt in a command prompt. This will create a text file with a detailed output from GPResult.exe

10. Open the gpresult.txt file in Notepad (or your preferred text editor), and search for the name of each GPO collected from the Get-GPO cmdlet. Once located, this will confirm which GPO(s) are applied to the affected machine

Armed with the information determined by this procedure, I was able to update another GPO that was applied only to the ZDC in question and set the "passwordexpirywarning" value to the correct number of days, and password notifications then worked as expected.