Question on creating .adm templates

  • Thread starter Thread starter Andrew Mitchell
  • Start date Start date
A

Andrew Mitchell

I have just been reading through the article on creating your own group
policy templates at http://support.microsoft.com/?kbid=323639 and have a
question related to group policy with 3rd party applications.

The above article states that it's recommended to create the registry entries
under the Policies subkey of the registry to avoid making the changes
persistent.

I'm wondering how this works internally within Windows. For example, suppose
I create a group policy that sets a registry entry at HKCU\Software\policies
\symantec to set a property for a symantec product. When the application runs
it will try to read the registry key at HKCU\Software\Symantec (not the
'Policies' subkey).
Does Windows automatically intercept the RegOpenKey and RegQueryValueEx API
calls and redirect them to the Policies subkey, or does the application have
to be written to be Group Policy aware?

Thanks
Andy.
 
Andrew, Great question!

The reason Microsoft says to create entries under the Polcies key (4 of
them) is because these entries are flushed and recreated at restart and
logoff/on. this creates a non-persistent Registry. However, there are only a
few entries that can be put in here. The app or OS must be designed to use
this key, if not, you are stuck with the other keys, which are persistent.

You will also find that getting them to show up in the GPO editor can be
difficult. Make sure you select the option to show all policies (or with
2003, policies that can't be managed).

they will show up with a red dot, not blue dot in the interface.

Hope this helps!
 
Derek Melber said:
Andrew, Great question!

The reason Microsoft says to create entries under the Polcies key (4 of
them) is because these entries are flushed and recreated at restart and
logoff/on. this creates a non-persistent Registry. However, there are
only a few entries that can be put in here. The app or OS must be
designed to use this key, if not, you are stuck with the other keys,
which are persistent.
Click to expand...

Thanks Derek. I was hoping that Windows would automatically check the
Policies subkey first and then revert to the non-policy key if the policy was
empty.

I'm thinking it wouldn't be too hard to write a small app that hooks the
registry API calls and does as described above. That would give system
administrators the ability to make any application GP aware without tattooing
the registry with persistent entries. I'll have to do a bit of thinking about
how the admin can determine which keys they want redirected.

I might see what I can throw together.

Andy.
 
Andrew,

Generally if an app wasn't designed with policies in mind, the settings you
would be talking about are configuration options. In other words, even if
the app read them from the policy hive, the app will probably allow the user
to simply change the values. Apps designed to support restrictive policies
must not only read the settings from the registry, but prevent the user from
changing them. This is a design decision within the app, and cannot
generally be altered by altering the location from which the setting is
retrieved.

Your suggestion would allow you to use blue dot ADM settings to control
non-policy key registry settings (not including binary and some other
types). However, it doesn't seem to be worth the effort - you're better off
with the red dot settings, as the result in the app is the same either way.
The "tattooing" is an artifact of the Microsoft registry client-side
extension (CSE). The Policy Maker registry extension is not tied to the
policy sections of the registry in this way, and allows you to create custom
settings by simply typing in the values into the GUI, or using a registry
browser.

More importantly, you can specify one of three modes for policy application:

(1) remove the setting when it is no longer applied [this is like a blue
dot]
(2) do not remove the setting [like a red dot]
(3) set the setting one time only [a true preference]

And you can apply graphical per-item filtering using 25 categories of
filters.

The Policy Maker registry extension is part of the Policy Maker Professional
product, which we sell, however in the next minor update - due out soon, the
registry extension will be absolutely free of change.

Regards,

Eric Voskuil
Policy Maker
http://www.autoprof.com/policy
 
Eric Voskuil said:
Andrew,

Generally if an app wasn't designed with policies in mind, the settings
you would be talking about are configuration options. In other words,
even if the app read them from the policy hive, the app will probably
allow the user to simply change the values.
Click to expand...

But I am proposing hooking the registry *reading* API's, not the API's that
write to the registry. The user could enter whatever settings they want and
they would be written to the usual location in the registry, but if the
administrator had applied a group policy in the 'Policies' location, these
would take precedence over the user settings (which is how it should be
IMHO) It may cause a bit of user confusion as their settings would never
'take' but that would be a small price to pay in order to stop users
breaking things.
Apps designed to support
restrictive policies must not only read the settings from the registry,
but prevent the user from changing them.
Click to expand...

In the case decribed above, the user could change them all they want but
the settings would never be read by the application if an over-riding group
policy existed in the "policies" subkey.
This is a design decision
within the app, and cannot generally be altered by altering the location
from which the setting is retrieved.

Your suggestion would allow you to use blue dot ADM settings to control
non-policy key registry settings (not including binary and some other
types). However, it doesn't seem to be worth the effort - you're better
off with the red dot settings, as the result in the app is the same
either way.
Click to expand...

Not really
I have seen situations where we want some users to have full access to
application configurations, while other users need to be locked down. This
would give us the option of using GP permissions to assign settings to some
users, while allowing other users full access to set their own
configurations.
I understand that this could be done using red-dot settings, but writing
the settings to a volatile section of the registry seems a more elegant
solution. Especially when you are talking about HKLM settings that are
applied to all users of that machine. In this case, a volatile setting is
much more desireable.

The tattooing of the registry would become irrelevant as the keys that are
identified would be read from the 'policies' subkey. If this section did
not exist it would be read from the tattooed registry entries.
The "tattooing" is an artifact of the Microsoft registry
client-side extension (CSE). The Policy Maker registry extension is not
tied to the policy sections of the registry in this way, and allows you
to create custom settings by simply typing in the values into the GUI,
or using a registry browser.
Click to expand...
More importantly, you can specify one of three modes for policy
application:

(1) remove the setting when it is no longer applied [this is like a blue
dot]
(2) do not remove the setting [like a red dot]
(3) set the setting one time only [a true preference]

And you can apply graphical per-item filtering using 25 categories of
filters.

The Policy Maker registry extension is part of the Policy Maker
Professional product, which we sell, however in the next minor update -
due out soon, the registry extension will be absolutely free of change.

Regards,

Eric Voskuil
Policy Maker
http://www.autoprof.com/policy
Click to expand...


Thanks Eric. I'll take a look at it now.

Andy.
 
Generally if an app wasn't designed with policies in mind, the settings
But I am proposing hooking the registry *reading* API's, not the API's that
write to the registry. The user could enter whatever settings they want and
they would be written to the usual location in the registry, but if the
administrator had applied a group policy in the 'Policies' location, these
would take precedence over the user settings (which is how it should be
IMHO) It may cause a bit of user confusion as their settings would never
'take' but that would be a small price to pay in order to stop users
breaking things.
Click to expand...

I understood your take on it, but I don't think that it will work out this
way in a lot of apps. Apps don't all read their settings each time they use
them. It's typical to read them once, and write them when they are changed.
However when a setting is changed, it is not necessary to re-read it (since
the app already has the change). Therefore in many apps, and possibly with
different behaviors even in a single app, the "restriction" won't take until
after the user closes the app, and then reopens it. And of course the user
can always change the setting each time they open the app - so it becomes
more of an annoyance than a restriction. Apps that are designed with policy
in mind are supposed to listen for a policy message, and reload policy
following a change event. This would not happen with the system you
describe. My guess is that the end result would be people changing settings
and leaving the app open, and possibly logging off less, in order to avoid
the annoyance.

In the cases where applications read their settings from the registry each
time prior to their use, this would probably work. But there is no reason
to assume this will be the case. Before taking the time to write this
fairly complicated code, I would test out this theory using regmon on the
desired apps and settings.
In the case decribed above, the user could change them all they want but
the settings would never be read by the application if an over-riding group
policy existed in the "policies" subkey.


Not really
I have seen situations where we want some users to have full access to
application configurations, while other users need to be locked down. This
would give us the option of using GP permissions to assign settings to some
users, while allowing other users full access to set their own
configurations.
I understand that this could be done using red-dot settings, but writing
the settings to a volatile section of the registry seems a more elegant
solution. Especially when you are talking about HKLM settings that are
applied to all users of that machine. In this case, a volatile setting is
much more desirable.
Click to expand...

It's an interesting idea, but my feeling, having worked related issues
closely for a long time, is that even if implemented well, the results would
be inconsistent across apps and settings due to the freedom that
applications have as to how/when they read and retain their settings.

Another thing you might consider is denying write access to the keys into
which the settings are written, especially with HKLM settings. This can be
done with Group Policy as well, and it's more effective since the app cannot
make a change to the setting, and well-written apps should then deny the
change attempt internally as well. The settings can still be written using
ADM Templates or Policy Maker, and when using PM you can also eliminate the
tattooing affect.
The tattooing of the registry would become irrelevant as the keys that are
identified would be read from the 'policies' subkey. If this section did
not exist it would be read from the tattooed registry entries.
The "tattooing" is an artifact of the Microsoft registry
client-side extension (CSE). The Policy Maker registry extension is not
tied to the policy sections of the registry in this way, and allows you
to create custom settings by simply typing in the values into the GUI,
or using a registry browser.
Click to expand...
More importantly, you can specify one of three modes for policy
application:

(1) remove the setting when it is no longer applied [this is like a blue
dot]
(2) do not remove the setting [like a red dot]
(3) set the setting one time only [a true preference]

And you can apply graphical per-item filtering using 25 categories of
filters.

The Policy Maker registry extension is part of the Policy Maker
Professional product, which we sell, however in the next minor update -
due out soon, the registry extension will be absolutely free of change.

Regards,

Eric Voskuil
Policy Maker
http://www.autoprof.com/policy
Click to expand...


Thanks Eric. I'll take a look at it now.

Andy.
Click to expand...

Great, let me know what you think.

Regards,

Eric
 
It's an interesting idea, but my feeling, having worked related issues
closely for a long time, is that even if implemented well, the results
would be inconsistent across apps and settings due to the freedom that
applications have as to how/when they read and retain their settings.
Click to expand...

Had a bit more of a think (some would say for the fist time...) and, yep,
it's probably a bad idea.

Thinking about the point you raised WRT how often apps actually read the
registry and you are correct. Most of the applications I've written only read
the registry at startup. The rest of the time, if the user changes a setting
it just writes it to the registry but doesn't read it again as it already
knows what was written.
The only exception I can think of was one application where I was feeling
lazy and had a generic function that read all settings for my app from the
registry. Every time I did a write, I just called the function and had all my
global variables set for me - But as I said, it was written on a bad day (and
in a hurry).

There is also the performance issue to be handled. I'm not sure of the
overhead of a system wide hook that traps all registry reads, but I wouldn't
think it would be minor.

There would also be the problems encountered if the dll didn't unload cleanly
to deal with.

Overall - Nice in theory, but..........

Andy.
 
Back
Top