[gptalk] Re: How to test new ADMX files

  • From: "Cruz, Jerome L" <jerome.l.cruz@xxxxxxxxxx>
  • To: "gptalk@xxxxxxxxxxxxx" <gptalk@xxxxxxxxxxxxx>
  • Date: Fri, 18 Jul 2008 12:06:54 -0700

Hi Alan,

If you really need to avoid building a test domain, you could use Darren's 
idea, but change the idea a bit to simplify things.

First, create a couple of standard test ADMX files (e.g. Test01.admx, 
Test02.admx, Test3.admx, etc.). Create as many that you think you might 
require. Next, have the Domain Administrators copy them to the Central Store 
and set up the access and modification ACLs on them for yourself or for members 
of a designated security group.

The test ADMX templates would always be ready to use and test at a moment's 
notice. Once ready to go, send the deployable (and renamed) templates to the 
Domain Administrators for 'official' deployment.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = == = = = = = = = = = 
= = = = =
Domain Testing Options
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = == = = = = = = = = = 
= = = = =

1)      Having a pre-production domain is wise, but admittedly it can be hard 
to maintain as a true(or nearly true) copy of the production domain. We do pay 
for all the OS licenses, so it's a specific overhead cost and time commitment. 
And it certainly never has the 'load' of the real thing. In fact, we have 
several physical and virtual (Pre-production, Technical Testing, Crash & Burn) 
domains. Most times, we test everything we do in the lab/test domains before 
deployment. That said, what I run into is that, sometimes, the lab domains 
won't work because of 'something' missing (oops-wrong version of MOM/SCOM in 
lab, oops-no VPN wireless connections available in the lab, oops-need the old 
version of Exchange to test the client setting they want turned on). It's at 
these times that I fall back to testing-VERY CAREFULLY-in production or simply 
take the time to re-build/re-architect the lab environment.

2)      There are times when all I need to do is just test a policy setting to 
fully understand its operational behavior, so I simply turn it on for my own PC 
(example below).

3)      Also, you could also use a virtual domain loaded on your local hardware.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = == = = = = = = = = = 
= = = = =
Example Policy Behavior
User Configuration | Administrative Templates | System | Prevent access to the 
registry editing tools

Disables the Windows registry editor Regedit.exe.
If this setting is enabled and the user tries to start a registry editor, a 
message appears explaining that a setting prevents the action.
To prevent users from using other administrative tools, use the "Run only 
specified Windows applications" setting.

Pretty straightforward you'd think, right? So what's NOT documented?

1)      All access to the registry is ALWAYS available using any other means 
"other than" Regedit and Regedt32.

2)      If a user has the registry editor open at the time that the policy 
setting becomes active on their system, any number of additional running copies 
of the 'regedit' utilities may be launched.

3)      Only when the last 'regedit' utility is closed does the policy "then" 
become effective.

Until a policy setting is investigated thoroughly, you simply cannot know the 
expected behavior (as documented). This is why we wind up testing each policy 
setting whenever we use it for the first time.

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = == = = = = = = = = = 
= = = = =

Jerry Cruz | Group Policy Product Manager | Windows Infrastructure Architecture 
| Boeing IT

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Darren Mar-Elia
Sent: Thursday, July 17, 2008 5:54 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: How to test new ADMX files

Agreed. I asked for such flexibility early in the process of Vista dev but 
alas, it went unheeded. Perhaps another option is to create a junction point on 
the client editing the GP that points to an alternate location with the same 
name as the Central Store. This is just pure speculation as to whether this 
would work but I wonder...

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Alan & Margaret
Sent: Thursday, July 17, 2008 5:50 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: How to test new ADMX files

Hi Darren,

Your assumption is correct. It does ignore it and doesn't give an error 
message. Still, it is a rather messy solution... if you want to replace an ADMX 
file, you have to make it unreadable  to the tester and the new version 
readable only by the tester. And you are still changing security on a 
production system. With ADM files I was always able to convince Managers that 
it was safe to create a new GPO to test in, set the APPLY security so I was the 
only one to receive it and give me WRITE access to the Policy. Now I need them 
to fiddle security in the PolicyDefinitions directory as well.

Maybe I need a test domain... But I would love a registry key to point me to a 
different PolicyDefiniton Directory....

Alan Cuthbertson

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Darren Mar-Elia
Sent: Friday, 18 July 2008 9:29 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: How to test new ADMX files

How about permissioning the test ADMX file in the central store such that only 
a couple of test administrators can read it? If it can't be read, I would 
presume that GP Editor would simply not try to load it?


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On 
Behalf Of Alan & Margaret
Sent: Thursday, July 17, 2008 4:18 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] How to test new ADMX files

All (especially Darren!)

I am trying to work out how to test ADMX files when I have a Central repository 
in place. I cannot work out a way to do this without putting the entire domain 
at risk.

Once you have created the Central repository, all users on the domain use it. I 
cannot see any way to point them back to the local copy under Windows or to any 
other location.

I had thought I could use GPEDIT to edit my Local Policy and (hopefully) pick 
up the local ADMX files. But GPEDIT doesn't support ADMX files and GPME only 
supports GPO's and always looks at the Central repository if it is present.

The only options would seem to be:-
*         Have a separate domain for the testing (an overkill if it is just to 
test the ADMX files)
*         Don't use the central repository, just the local directory for all 
users (A maintenance nightmare)
*         Assume that the ADMX file will have no syntax errors and just throw 
it in.

Admittedly the last option is not as bad as you may think. If it is wrong it 
will only impact users trying to edit Admin Template entries and it can be 
easily reversed.  However most managers like to have change control on such 

Alan Cuthbertson

Other related posts: