Many times we need to apply a registry file (.reg) to our many systems (1400+), and it's a real pain ... specially that we really like using Group Policies for everything.
if it's just a few values we create an ad-hoc registry policy and set the values thru GPO, but when we have a large .REG file with a lot of settings things become a lot harder, and we have to start dancing around figuring out how to best deploy this settings.
To make things worse, after a while, we would look at the policy and trying to figure out what those registry setting meant and where they came from ... like I've said: a real Pain ...
In the past, I attempted to create an ADM file for a couple of our most common application, but I gave up due to the complexity of the ADM syntax.
Last weekend I was thinking about this again and I decided to give it another try. I did not want to use and "old" standard, so I decided to research the ADMX policies. I opened the ones I found in my systems and it seemed pretty simple to understand.
So I downloaded the
ADMX samples and the
schema/syntax definition from MS and got to work.
Luckily for me, the syntax is really simple, XML simple, and I quickly realized that instead of creating a new ADMX to apply the setting of my problematic .REG file, I could create a tool to parse any registry file into a corresponding ADMX policy definition.
It took me the whole weekend but by 2 AM Monday I had a functional (and much debugged) tool.
I did not had any development tool installed on my system so I decided to use good-old VBScript to write the tool. This has the added bonus that anyone can read it and update it without much requirements.
What it does
Reads a registry file (.reg) and creates the corresponding ADMX and ADML files that would allow to set the registry values detail led in the original .reg file.
in order to create the GUI definition required by the GPMC, it makes a few assumptions:
a) the "name" of the value is also used as the caption for all displays.
b) all dwords values are assigned a numeric textbox for data entry
c) all other value types are treated as strings and assigned a textbox for data entry.
Caveats
@ or
(Default)
The tools will not handle correctly the "@" or unnamed valuename. This is the one that in the registry editor shows as (Default).
The reason for this is that I have not been able to find the correct way to define this in ADMX/L.
WORKAROUND: For now it's assigning the value to a "(Default)" value, but as you can see in the examples bellow, windows does not recognize this "(Default)" value as the real "(Default)" value.
I will need to find an existing ADMX that sets this kind of values and read it's XML in order to learn how it's done. OR maybe someone can let me know so I can correct the tool.
Hex,
Hex(0) ...
This is another example of things that I was not able to learn from the ADMX files that I have available.
We have several cases of registry files that assing a value composed of several 2 char Hexadecimal values, but I have not find any ADMX file that applies this kind of settings to to policies.
WORKAROUND: For now, and until I can find the way to do it correctly, the script will make this hexadecimal values into a text.
I will need to find an existing ADMX that sets this kind of values and read it's XML in oder to learn how it's done. OR maybe someone can let me know so I can correct the tool.
Usage:
CSCRIPT REG_2_ADMXL.vbs registry-file language [name]
registry-file is the name and path of the registry file to be converted.
language is the language and culture to be used, ie: en-US, sp-AR, etc.
name Display Name to show in the GPO. if omited "REG_2_ADMXL Generated Policy" will be used.
The output file will be named after the .REG file (if the input is myfile.REG, the output will be myfile.ADMX and myfile.ADML.
The ADMX output file will be saved in the same folder the input .REG file is located, while the ADML output file will be saved in a subfolder of the one the .REG file is located. The subfolder will be named after the language specified.
So, if the reg file is C:\myapp\myfile.reg and the lang is en-US, then the ADMX file will be as in C:\myAPP\myfile.ADMX and the ADML file will be saved as C:\myAPP\en-US\myfile.ADMX
EXAMPLE
I converted the following .reg file into ADMX/L
Windows Registry Editor Version 5.000
[HKEY_CURRENT_USER\Software\Marianok\Myapp]
@="default value of the key"
"MyAppName"="SuperApp123"
"MyAppServer"="SomeServer"
[HKEY_CURRENT_USER\Software\Marianok\Myapp\Config]
"bottom"=dword:00000000
"left"=dword:00000000
"right"=dword:00000000
"top"=dword:00000000
"color"="red"
So I ran the following command:
CSCRIPT REG_2_ADMXL.vbs c:\temp\myregfile.reg en-us
(the last parameter basically defines the language and culture to use, in this case US English)
The tool generated 2 files
c:\temp\myregfile.ADMX and
c:\temp\en-us\myregfile.ADML
Once you have the ADMX and the ADML files you can use them in the Group Policy Management Console to edit your GPOs more confortably.
The following 4 images show the test GPO created from the .REG file above
Notice that the diferent registry keys (the Path) became nodes on the tree, and that the "Config" Key is correctly subordinated to the "MyApp" key.
Also notice that in order to help the people that might be using this ADMX file in the future, the tool will add a description to each one of them detailling what keys is being affected.
Here one of the values was selected.
Notice that the "@" from the .reg file was replaced with (Default).
Also notice that the tool has added a comment to each setting detailling what registry value will be affected, what was the datatype reported in the .reg file and what was the value assigned in the original .reg file.
Same for the MYAPP\CONFIG node.
Notice that there are 4 values, but only 3 are enabled (only this 3 will be applied to the targets).
In this screen you can see one being edited.
Once again you can see the description/help that was created by the tool based on the .reg file.
Also notice that the value that was assigned in the original .reg file has become the default value for the field.
This is the report from the Group Policy Management
This is a millon times more readable than the mess of registry keys and setting that the GPM would be showing if we did not have the ADMX/L files inplace.
Notice that only 3 values are listed under the CONFIG section, that it's because the fourth is still disabled.
Now, after the GPO was applied to the user/workstation, we can see the registry:
Notice the issue I was mentioing before with the (DEFAULT) valuename. There are 2 of them one without data and the other witht he data we were trying to assign.
Had I imported the registry file into this system the first one would have a value ("default value of the key"), but this is not happening.
Here is the Config folder, notice that the fourth value does not show, just as expected.
WOW, that was a long post :-) ... sorry, but I'm really exited about this work :-)
if you want it, feel free to
download it from my site
Posts
