Why is Group Policy Limited to specific keys?

  • Thread starter Thread starter BenHanson
  • Start date Start date
B

BenHanson

I've always failed to understand why Group Policy couldn't be used with
any registry key, the way it is used with the built-in ADM templates?
I know, I can create custom adm templates that will modify the registry
a la NT policies which tatoo the registry. But why can't they be
overlayed just like the real "policies?" I've always assumed the
overlaying was done in memory, e.g. loading keys under Group Policy in
place of the real key, thus leaving the previous setting in HKLM, or
HKU untouched. Why can't they do this with any key?
 
BenHanson said:
I've always failed to understand why Group Policy couldn't be used with
any registry key, the way it is used with the built-in ADM templates?
I know, I can create custom adm templates that will modify the registry
a la NT policies which tatoo the registry. But why can't they be
overlayed just like the real "policies?"
Click to expand...

Because it is not depending on MS.
It´s a functionality, that has to fullfilled from the developers
of the Software you want to control.

The "policies thing" is not a GPO feature on the client side, it´s more
like a trick. The difference between tattoo and policy is:
tattooing uses the "real" path in registry. software\name of software
policies uses \policies\name of software (or something similar)

What happens at startup time of an application?

It takes a look into the registry to get it´s settings. If it will find
some of them, they will be used.
Usual the programm take a look inside \software\name\ and reads it.
Thats all. This is what all applications do (if they don´t work
with .ini or .cfg ;-)
A "Full Supported Policy" application starts a little different:

1st look: into \policy\name\ settings there? Yes? Accept! No look
into \software\name
No settings there?
2nd look: \software\name

GPOs or full managed settings are just written in a different path
and the application has to be designed to take a look inside this
"redirected" folder.

Now MS can delete and handle fullmanaged settings, because the "real"
ones are not infected. There is have no efect in the "live system",
if a setting is removed, because the "real one" is still there.

If you are a software developer, than just follow the "trick" and your
software will be full managed. Working the "old style" it will only be
controlled with tattoing settings.

Mark
 
I actually don't quite understand why they stuck with just the 4 policy keys
myself. The way the un-tattooing feature works could also be used by non
policy keys just as easily. Basically, this how it works. When a machine
first process registry policy, it takes the contents of all of the
registry.pol files that it finds in the various GPTs of each GPO that is
processed, and merges them in memory, eliminating values that are
overwritten by conflicting settings linked later in the processing cycle. So
you end up with this ntuser.pol file that is written on the machine. The
machine then processes all of the entries in that file, including policies
and preferences. Now, then second time around, the first thing the machine
does is read through that ntuser.pol file and find all of the policy values
that are set in there (it ignores the preferences). It then deletes all of
the policy values it finds in that file, then reapplies the new list of
GPOs, merging all the registry.pol files again to create a new ntuser.pol
file. So, you kinda have to wonder why they don't just remove all of those
preferences along with the policies. I see no real technical reason for it,
other than the fact that by specifying a set of "policy keys", you make the
process of policy-enabling an application more predictable, because you can
always look in the same place for those keys.

Darren

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Training Videos, Whitepapers and Utilities for all things Group
Policy-related
Group Policy Management solutions at http://www.sdmsoftware.com
 
Hi Darren,
[...] I see no real technical reason for it, other than the fact that
by specifying a set of "policy keys", you make the process of
policy-enabling an application more predictable, because you can
always look in the same place for those keys.
Click to expand...

Full ACK.
bur I like the idea of having a centralized Hive (or 4) to control the
entries. Makes it much more comfortable.

Mark
 
One other factor I can think of, which is pretty much a none concern
today, is that in the 1997-1998 timeframe when they were devising
this there was a very real issue with registry bloat and performance
degradation as result on the NT4 systems of the day.
This may have been another consideration operative in the trade-off
analysis (especially given that they were not sure how large the new
"policies" sections would be).
 
Back
Top