Two Way Group Policy Locator Tool

This article and the tool it introduces will likely be of interest only to Windows system administrators, IT security practitioners,  and other members of the priesthood involved in configuring or verifying machine & user group policies.  Others may choose to slowly back away from what follows. 😉

The Problem:

You’re looking at a particular policy setting somewhere under the (Computer or User) Administrative Templates node of a Policy Editor (local policies or Active Directory domain GPO), as in the screenshot below, and you’d like to know what Registry entry is set at what key when this policy is configured.  This could be for the purpose of verifying that the policy is being applied as expected, or maybe you’re considering converting the policy to a Registry Group Policy Preference (for easier targeting), which requires knowing the key, entry name, and value to set.

The Reverse Problem:

You’re looking at a particular entry in Regedit under a (local or remote) policy key, or even under a non-policy key that you suspect may be the result of an administrative template policy (e.g. FSLogix Profiles settings), and you’d like to get details of its purpose and know exactly what node (“category”) and policy title it corresponds to in Policy Editor (assuming of course that it is in fact the result of an administrative template policy).

The typical solution:

The typical solution to both versions of the problem:  Google it!  You’ll probably find the answer on a policy-oriented website (https://admx.help often comes up in searches) or somewhere in a blog post or vendor document (after you filter out unanswered forum posts asking the same question 😉), but your mileage will vary depending on your Windows UI language and on whether you’re dealing with a “well-known” policy.  Note however that an Internet search may be your only avenue if the “fast & easy” solution provided below doesn’t bear fruit, which can only happen in the “reverse” case, when it turns out that the Registry entry you’re trying to identify does not in fact correspond to an administrative template policy (or comes from a policy template absent from your template store).  This often means that the Registry entry is undocumented and was “hard-coded” either by some app or by someone acting under the guidance of a vendor’s tech support.

The fast & easy solution:

Use this new Policy Locator tool.  When it’s running, using the hotkey Ctrl + Shift + Q  while a policy is highlighted in Policy Editor OR while a Registry entry is highlighted in Regedit will almost instantaneously locate the corresponding Registry or policy information and combine both into a dialog like the one shown below — you may have already figured out that the policy highlighted in the first screenshot above and the Registry entry highlighted in the second screenshot in fact correspond to each other, so this would be the resulting dialog if the hotkey were used in either scenario:

Usage Notes:

• For the Policy Locator to function correctly, it should be pointed to the policy template store (the local or network folder containing ADMX files) used by Policy Editor and the current Windows UI language subfolder name should be specified (en-US, fr-CA, es-MX, …).  Even though the tool’s UI is in English, policy titles, categories, and explanations will then be displayed in the Windows UI language.

• By default, Policy Locator assumes the local policy template store (%SystemRoot%\PolicyDefinitions) and en-US as the language (ADML files) subfolder.  To change these settings, specify the full path to the desired ADMX store and/or the desired language subfolder name on the command line (or in a shortcut) that launches the tool, in any order.  The switch /Domain may be used instead of a path to specify the domain’s central policy template store (if it exists), \\domain.dns.name\SYSVOL\domain.dns.name \Policies\PolicyDefinitions.  For example, PolSearch.exe /Domain fr-FR will use the central store and assume French (France) as the UI language, and PolSearch.exe es-ES will default to the local store but assume Spanish (Spain) as the UI language.

• The template store and language in current use by Policy Locator can be verified via its tray icon’s Policy Store info context menu item:

• In order for Policy Locator to be able to “read” the currently selected category name and policy title from Policy Editor or the currently selected key and value from Regedit, when its Ctrl + Shift + Q hotkey is pressed, it needs to be running at the same or higher integrity level as the target app, which in most cases means it needs to be running elevated (i.e. as administrator) since Policy Editor and Regedit usually do.  Note that the tool’s sole system activity is reading ADMX/ADML template files, so this doesn’t present any risk.

• Note that the Ctrl + Shift + Q hotkey will also work when a policy (in Policy Editor) or a Registry entry (in Regedit) is open for editing, as long as the editing dialog has focus.

• The Continue Search button in the result dialog:  because Policy Locator can only “read” the currently selected policy category name and title from Policy Editor (not the entire category path), it may on rare occasions locate different matching policies that aren’t in fact the one selected  — it may for example first locate a matching computer policy when the selected policy is a user policy, or an entirely different policy that happens to have the same title at a node (“category”) with the same name. Using the Continue Search button in these cases guarantees that the correct policy will eventually be located.  As far as the “reverse” search is concerned (i.e. starting from Regedit), the Continue Search  option is almost never needed since the correct policy will always be located on the first try (assuming it’s “locatable” in the current ADMX template store). The only scenario in which multiple matches can exist would be if two separate ADMX policy templates define the exact same policy, an abnormal situation.

• As seen in the screenshot of the Policy Locator result dialog, the located policy’s entire XML definition (extracted from the relevant ADMX file) is shown (note that the dialog is fully resizable if a clearer view is needed).  The possible values of the corresponding Registry entry are usually listed there.  In cases where the values correspond to an enumeration of possibilities (rather than plain enable/disable options as in the example), the various options may be labeled with language-neutral string references of the form $(string.SomeStringID) – in such cases, you may highlight a reference and use the hotkey Ctrl + Shift + A to be shown the corresponding plain text in the defined UI language (note that the selection need not be precise before pressing Ctrl + Shift + A, as long as it contains the entire reference from the $ sign to the closing parenthesis).

• PolSearch.exe is a signed but compressed executable, and as such may nonetheless trigger a false positive from some anti-virus products.  There’s unfortunately not much I can do about it, so if this occurs in your environment and you’re unable to create an exclusion for it, just delete it and we’ll speak of it no more. 🤷‍♂️

I hope you find this tool as useful as I enjoyed writing it (plenty of meaty Regular Expressions involved).  Do please let me know if you run across some pathological ADMX/ADML pair that somehow confounds it.

Later.
JB

Follow Jacques Bensimon on Twitter @JacqBens for more great Windows insights and tricks.