| Author | Messages | |
gavinp
Posts:16
 | | 08/06/2010 3:52 PM |
| Hi
I am trying to get some clarification on a statement in http://www.gpoguy.com/FAQs/Whitepapers/tabid/63/articleType/ArticleView/articleId/5/Understanding-Policy-Tattooing.aspx
In this very interesting document there is a statement (I have highlighted in bold) in the section "How It Works Under the Covers"; namely
"You might wonder how this all works--how Windows manages to "un-tattoo" these policies when the GPO no longer applies. Well, the mechanism is quite simple really. Each time a foreground or background (see my whitepaper for a description of foreground and background processing) policy processing cycle kicks off, if Admin. Template policy is meant to be applied (that is, if the GPO has changed since the last time it was processed), the first thing that Windows does is remove all registry values under our 4 magic keys."
I created an additional test reg key (manually in the registry) under HKCU\Software\Policies\Microsoft\Windows\ControlPanel\Desktop where we have set via a GPO our companies ScreenSaver GPO settings. After a gpupdate /force reboot of the computer, I was somewhat surprised to see that the test reg key still existed. I repeated the test by manually changing one of the Screensaver GPO settings (ScreenSaveTimeOut) and after another gpupdate /force reboot of the computer, noted that the ScreenSaveTimeOut value was correctly "restored" but my test reg key was still present.
Can I assume that what this behavior is showing can be summarized in a statement "the first thing that Windows does is remove all registry values set by Group Policy under our 4 magic keys" ?
Regards Gavin
| | | |
| dmarelia
Posts:394
| | 08/06/2010 3:52 PM |
| Gavin-
Since I wrote the paper, I will respond to the list for everyone's benefit. You are correct below-the un-tattooing behavior only works if you deliver registry settings to those 4 "special" keys via GP. If you manually put values into one of those keys, the GP engine knows nothing about those manually managed values and just ignores them. Its an interesting but important distinction to make.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Parker, Gavin S
Sent: Thursday, May 27, 2010 4:06 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Clarification of the "Understanding Policy Tattooing" whitepaper
Hi
I am trying to get some clarification on a statement in http://www.gpoguy.com/FAQs/Whitepapers/tabid/63/articleType/ArticleView/articleId/5/Understanding-Policy-Tattooing.aspx
In this very interesting document there is a statement (I have highlighted in bold) in the section "How It Works Under the Covers"; namely
"You might wonder how this all works--how Windows manages to "un-tattoo" these policies when the GPO no longer applies. Well, the mechanism is quite simple really. Each time a foreground or background (see my whitepaper for a description of foreground and background processing) policy processing cycle kicks off, if Admin. Template policy is meant to be applied (that is, if the GPO has changed since the last time it was processed), the first thing that Windows does is remove all registry values under our 4 magic keys."
I created an additional test reg key (manually in the registry) under HKCU\Software\Policies\Microsoft\Windows\ControlPanel\Desktop where we have set via a GPO our companies ScreenSaver GPO settings. After a gpupdate /force reboot of the computer, I was somewhat surprised to see that the test reg key still existed. I repeated the test by manually changing one of the Screensaver GPO settings (ScreenSaveTimeOut) and after another gpupdate /force reboot of the computer, noted that the ScreenSaveTimeOut value was correctly "restored" but my test reg key was still present.
Can I assume that what this behavior is showing can be summarized in a statement "the first thing that Windows does is remove all registry values set by Group Policy under our 4 magic keys" ?
Regards Gavin
| | | |
| Syspro
Posts:0
| | 08/06/2010 3:52 PM |
| Gavin,
Further to this, the actual keys to be removed are held in the "nutser.pol"
file in the users profile. The machine entries are held in the "All Users"
directory. Therefore, if you delete this file, the un tattooing will not
occur. It is therefore important that when building a Default profile from
an existing user that if the ntuser.dat file is copied, ntuser.pol is also
copied.
You can also browse this file to see what tattooed policies are in place.
Alan Cuthbertson
Policy Management Software (Now with ADMX and Preference support):-
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml>
&f=pol_summary.shtml
ADM Template Editor(Now with ADMX support):-
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml>
&f=adm_summary.shtml
Policy Log Reporter - including Preference logging(Free)
http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml>
&f=policyreporter.shtml
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Darren Mar-Elia
Sent: Friday, 28 May 2010 9:10 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Clarification of the "Understanding Policy Tattooing"
whitepaper
Gavin-
Since I wrote the paper, I will respond to the list for everyone's benefit.
You are correct below-the un-tattooing behavior only works if you deliver
registry settings to those 4 "special" keys via GP. If you manually put
values into one of those keys, the GP engine knows nothing about those
manually managed values and just ignores them. Its an interesting but
important distinction to make.
Thanks!
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: Thursday, May 27, 2010 4:06 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Clarification of the "Understanding Policy Tattooing"
whitepaper
Hi
I am trying to get some clarification on a statement in
http://www.gpoguy.com/FAQs/Whitepapers/tabid/63/articleType/ArticleView/arti
cleId/5/Understanding-Policy-Tattooing.aspx
In this very interesting document there is a statement (I have highlighted
in bold) in the section "How It Works Under the Covers"; namely
"You might wonder how this all works--how Windows manages to "un-tattoo"
these policies when the GPO no longer applies. Well, the mechanism is quite
simple really. Each time a foreground or background (see my whitepaper for a
description of foreground and background processing) policy processing cycle
kicks off, if Admin. Template policy is meant to be applied (that is, if the
GPO has changed since the last time it was processed), the first thing that
Windows does is remove all registry values under our 4 magic keys."
I created an additional test reg key (manually in the registry) under
HKCU\Software\Policies\Microsoft\Windows\ControlPanel\Desktop where we have
set via a GPO our companies ScreenSaver GPO settings. After a gpupdate
/force reboot of the computer, I was somewhat surprised to see that the test
reg key still existed. I repeated the test by manually changing one of the
Screensaver GPO settings (ScreenSaveTimeOut) and after another gpupdate
/force reboot of the computer, noted that the ScreenSaveTimeOut value was
correctly "restored" but my test reg key was still present.
Can I assume that what this behavior is showing can be summarized in a
statement "the first thing that Windows does is remove all registry values
set by Group Policy under our 4 magic keys" ?
Regards Gavin
| | | |
|
|