[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.
Moral
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
Alan
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
Alan-
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?
Darren
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
things!
Alan Cuthbertson
Other related posts:
