| Author | Messages | |
gavinp
Posts:16
 | | 09/01/2010 12:13 PM |
| Hi
In our company we allow computer users membership of the local Administrator group, and hence knowledgeable users can change GPO applied registry keys to a new value. The default policy processing behaviours for GPOs will NOT re-apply the GPO value until the GPO is changed (new settings or version etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply registry settings at computer startup and user logon and during periodic background processing (every 90 minutes) by the following setting:
Registry policy processing<javascript:void();>
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning and Deployment Guide "Process even if the Group Policy objects have not changed. If GPOs on the server do not change, it is not usually necessary to continually reapply them to the destination computer, except to override possible local changes. Because users who are running as local administrators might be able to modify the parts of the registry where Group Policy settings are stored, you might want to reapply these policy settings as needed during the logon process or during periodic background processing to return the computer to the desired state." Ref: http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in terms of the potential increase in network traffic and the additional load placed on the domain controllers. What I would like to understand (the crux of my question) is likely performance impact on the user's computer of registry values being re-applied every 90 minutes. We have less than 100 registry keys that would ever be re-applied. How would this compare to the processing load of GPPs (with their default policy processing behavior of re-applying registry keys during periodic background processing ) if GPPs were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background processing" but the issue with setting that as well is that IF a computer (particularly a laptop) is not actually rebooted AFTER a new or modified GPO is released then the new or modified computer settings will not be refreshed on that computer until it reboots which is an unacceptable "currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| DarraghOShaughnessy
Posts:161
| | 09/01/2010 12:59 PM |
| I would imagine the network traffic generated using GPP would be as large as
the XML file used to define the registry changes. If you have DC locality in
your sites this should not be a major problem. How big is the xml file and
are your sites on a LAN/WAN? Performance would depend on the actual keys
being set and their data values.
When you say "if GPPs were used to set the equivalent registry keys rather
than using GPOs", how would you set such keys using GPOS? Are you using a
custom .adm template or is it the security on the registry keys you are
setting?
Regards,
Darragh O'Shaughnessy
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: 01 September 2010 10:59
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator
group, and hence knowledgeable users can change GPO applied registry keys to
a new value. The default policy processing behaviours for GPOs will NOT
re-apply the GPO value until the GPO is changed (new settings or version
etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply
registry settings at computer startup and user logon and during periodic
background processing (every 90 minutes) by the following setting:
<javascript:void();> Registry policy processing
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning
and Deployment Guide "Process even if the Group Policy objects have not
changed. If GPOs on the server do not change, it is not usually necessary to
continually reapply them to the destination computer, except to override
possible local changes. Because users who are running as local
administrators might be able to modify the parts of the registry where Group
Policy settings are stored, you might want to reapply these policy settings
as needed during the logon process or during periodic background processing
to return the computer to the desired state." Ref:
http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in
terms of the potential increase in network traffic and the additional load
placed on the domain controllers. What I would like to understand (the crux
of my question) is likely performance impact on the user's computer of
registry values being re-applied every 90 minutes. We have less than 100
registry keys that would ever be re-applied. How would this compare to the
processing load of GPPs (with their default policy processing behavior of
re-applying registry keys during periodic background processing ) if GPPs
were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background
processing" but the issue with setting that as well is that IF a computer
(particularly a laptop) is not actually rebooted AFTER a new or modified
GPO is released then the new or modified computer settings will not be
refreshed on that computer until it reboots which is an unacceptable
"currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| DarraghOShaughnessy
Posts:161
| | 09/01/2010 1:11 PM |
| "The default policy processing behaviors for GPOs will NOT re-apply the GPO
value until the GPO is changed (new settings or version etc) or any other
GPO in scope of the user/computer had changed"
That is true for all (as far as I remember) cse's except one, the security
cse. There will be an enforced re-application of security settings
regardless every 16-18 hours as far as I remember. i.e. the security
settings cse will re-process regardless of whether a change has occurred or
not.
Regards,
Darragh O'Shaughnessy
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: 01 September 2010 10:59
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator
group, and hence knowledgeable users can change GPO applied registry keys to
a new value. The default policy processing behaviours for GPOs will NOT
re-apply the GPO value until the GPO is changed (new settings or version
etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply
registry settings at computer startup and user logon and during periodic
background processing (every 90 minutes) by the following setting:
<javascript:void();> Registry policy processing
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning
and Deployment Guide "Process even if the Group Policy objects have not
changed. If GPOs on the server do not change, it is not usually necessary to
continually reapply them to the destination computer, except to override
possible local changes. Because users who are running as local
administrators might be able to modify the parts of the registry where Group
Policy settings are stored, you might want to reapply these policy settings
as needed during the logon process or during periodic background processing
to return the computer to the desired state." Ref:
http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in
terms of the potential increase in network traffic and the additional load
placed on the domain controllers. What I would like to understand (the crux
of my question) is likely performance impact on the user's computer of
registry values being re-applied every 90 minutes. We have less than 100
registry keys that would ever be re-applied. How would this compare to the
processing load of GPPs (with their default policy processing behavior of
re-applying registry keys during periodic background processing ) if GPPs
were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background
processing" but the issue with setting that as well is that IF a computer
(particularly a laptop) is not actually rebooted AFTER a new or modified
GPO is released then the new or modified computer settings will not be
refreshed on that computer until it reboots which is an unacceptable
"currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| Syspro
Posts:0
| | 09/01/2010 1:18 PM |
| Hi Gavin,
(an answer from OZ!)
The load in either case will be quite small. Registry processing involves
taking the equivalent of a RegEdit file and applying it to the registry. For
100 keys it will be around 5K and the load to apply it will be small. GPP is
more verbose and so the file is likely be around 20K. The work involved in
applying it will be greater than for Registry files since it has to parse
the xml file and apply a lot more logic. Having said that it will still be
vanishingly small.
In fact you will get a much bigger hit from working out whether the policy
needs to be applied rather than doing the actual application of it. I would
recommend always applying policies even if they haven't changed because it
gives a more predictable result.
Alan Cuthbertson (Melbourne)
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 Parker, Gavin S
Sent: Wednesday, 1 September 2010 7:59 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator
group, and hence knowledgeable users can change GPO applied registry keys to
a new value. The default policy processing behaviours for GPOs will NOT
re-apply the GPO value until the GPO is changed (new settings or version
etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply
registry settings at computer startup and user logon and during periodic
background processing (every 90 minutes) by the following setting:
<javascript:void();> Registry policy processing
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning
and Deployment Guide "Process even if the Group Policy objects have not
changed. If GPOs on the server do not change, it is not usually necessary to
continually reapply them to the destination computer, except to override
possible local changes. Because users who are running as local
administrators might be able to modify the parts of the registry where Group
Policy settings are stored, you might want to reapply these policy settings
as needed during the logon process or during periodic background processing
to return the computer to the desired state." Ref:
http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in
terms of the potential increase in network traffic and the additional load
placed on the domain controllers. What I would like to understand (the crux
of my question) is likely performance impact on the user's computer of
registry values being re-applied every 90 minutes. We have less than 100
registry keys that would ever be re-applied. How would this compare to the
processing load of GPPs (with their default policy processing behavior of
re-applying registry keys during periodic background processing ) if GPPs
were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background
processing" but the issue with setting that as well is that IF a computer
(particularly a laptop) is not actually rebooted AFTER a new or modified
GPO is released then the new or modified computer settings will not be
refreshed on that computer until it reboots which is an unacceptable
"currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| gavinp
Posts:16
| | 09/01/2010 1:18 PM |
| Thanks for the feedback.
> When you say "if GPPs were used to set the equivalent registry keys rather than using GPOs", how would you set such keys using GPOS? Are you using a custom .adm template or is it the security on the registry keys you are setting?
>> What I simply meant to say was rather than using the GPMC to set a managed GPO registry setting (eg screensaver timeout), I could use a GPP to set the reg key "ScreenSaveTimeOut"="xxx". What I don't know is there much difference in processing load for the computer for processing (re-applying for example) a GPP set registry value versus one set by a GPO.
Regards Gavin
Gavin Parker | IT Domain Specialist
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darragh O'Shaughnessy
Sent: Wednesday, 1 September 2010 8:43 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
I would imagine the network traffic generated using GPP would be as large as the XML file used to define the registry changes. If you have DC locality in your sites this should not be a major problem. How big is the xml file and are your sites on a LAN/WAN? Performance would depend on the actual keys being set and their data values.
When you say "if GPPs were used to set the equivalent registry keys rather than using GPOs", how would you set such keys using GPOS? Are you using a custom .adm template or is it the security on the registry keys you are setting?
Regards,
Darragh O'Shaughnessy
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Parker, Gavin S
Sent: 01 September 2010 10:59
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator group, and hence knowledgeable users can change GPO applied registry keys to a new value. The default policy processing behaviours for GPOs will NOT re-apply the GPO value until the GPO is changed (new settings or version etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply registry settings at computer startup and user logon and during periodic background processing (every 90 minutes) by the following setting:
Registry policy processing<javascript:void();>
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning and Deployment Guide "Process even if the Group Policy objects have not changed. If GPOs on the server do not change, it is not usually necessary to continually reapply them to the destination computer, except to override possible local changes. Because users who are running as local administrators might be able to modify the parts of the registry where Group Policy settings are stored, you might want to reapply these policy settings as needed during the logon process or during periodic background processing to return the computer to the desired state." Ref: http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in terms of the potential increase in network traffic and the additional load placed on the domain controllers. What I would like to understand (the crux of my question) is likely performance impact on the user's computer of registry values being re-applied every 90 minutes. We have less than 100 registry keys that would ever be re-applied. How would this compare to the processing load of GPPs (with their default policy processing behavior of re-applying registry keys during periodic background processing ) if GPPs were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background processing" but the issue with setting that as well is that IF a computer (particularly a laptop) is not actually rebooted AFTER a new or modified GPO is released then the new or modified computer settings will not be refreshed on that computer until it reboots which is an unacceptable "currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| gavinp
Posts:16
| | 09/01/2010 1:25 PM |
| Greetings Alan - I have met you before @ Tech-Ed in Sydney. Thanks for your interesting feedback. I did not realize that your very handy & free tool "Policy Log Reporter' now does Preference logging - that is excellent news. This will allow me to compare processing times between a set of equivalent GPO versus GPP applied reg keys.
Do I gather from your comment "I would recommend always applying policies even if they haven't changed because it gives a more predictable result" that GPPs do not give as predictable a results compared to GPOs?
Regards Gavin
Gavin Parker | IT Domain Specialist
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Alan and Margaret Cuthbertson
Sent: Wednesday, 1 September 2010 9:00 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Hi Gavin,
(an answer from OZ!)
The load in either case will be quite small. Registry processing involves taking the equivalent of a RegEdit file and applying it to the registry. For 100 keys it will be around 5K and the load to apply it will be small. GPP is more verbose and so the file is likely be around 20K. The work involved in applying it will be greater than for Registry files since it has to parse the xml file and apply a lot more logic. Having said that it will still be vanishingly small.
In fact you will get a much bigger hit from working out whether the policy needs to be applied rather than doing the actual application of it. I would recommend always applying policies even if they haven't changed because it gives a more predictable result.
Alan Cuthbertson (Melbourne)
Policy Management Software (Now with ADMX and Preference support):-
http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml
ADM Template Editor(Now with ADMX support):-
http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml
Policy Log Reporter - including Preference logging(Free)
http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Parker, Gavin S
Sent: Wednesday, 1 September 2010 7:59 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator group, and hence knowledgeable users can change GPO applied registry keys to a new value. The default policy processing behaviours for GPOs will NOT re-apply the GPO value until the GPO is changed (new settings or version etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply registry settings at computer startup and user logon and during periodic background processing (every 90 minutes) by the following setting:
Registry policy processing<javascript:void();>
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning and Deployment Guide "Process even if the Group Policy objects have not changed. If GPOs on the server do not change, it is not usually necessary to continually reapply them to the destination computer, except to override possible local changes. Because users who are running as local administrators might be able to modify the parts of the registry where Group Policy settings are stored, you might want to reapply these policy settings as needed during the logon process or during periodic background processing to return the computer to the desired state." Ref: http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in terms of the potential increase in network traffic and the additional load placed on the domain controllers. What I would like to understand (the crux of my question) is likely performance impact on the user's computer of registry values being re-applied every 90 minutes. We have less than 100 registry keys that would ever be re-applied. How would this compare to the processing load of GPPs (with their default policy processing behavior of re-applying registry keys during periodic background processing ) if GPPs were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background processing" but the issue with setting that as well is that IF a computer (particularly a laptop) is not actually rebooted AFTER a new or modified GPO is released then the new or modified computer settings will not be refreshed on that computer until it reboots which is an unacceptable "currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| DarraghOShaughnessy
Posts:161
| | 09/01/2010 1:25 PM |
| Ah, ok, I get you 
But in that case, you cannot use GPP to set reg keys controlled by GP as GP
has a higher precedence and may overwrite the GPP setting.
Darragh O'Shaughnessy
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: 01 September 2010 12:02
To: 'xxxxxxxxxxxxxxxx'
Subject: RE: [gptalk] Another GPO question from OZ
Thanks for the feedback.
> When you say "if GPPs were used to set the equivalent registry keys rather
than using GPOs", how would you set such keys using GPOS? Are you using a
custom .adm template or is it the security on the registry keys you are
setting?
>> What I simply meant to say was rather than using the GPMC to set a
managed GPO registry setting (eg screensaver timeout), I could use a GPP to
set the reg key "ScreenSaveTimeOut"="xxx". What I don't know is there much
difference in processing load for the computer for processing (re-applying
for example) a GPP set registry value versus one set by a GPO.
Regards Gavin
Gavin Parker | IT Domain Specialist
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Darragh O'Shaughnessy
Sent: Wednesday, 1 September 2010 8:43 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
I would imagine the network traffic generated using GPP would be as large as
the XML file used to define the registry changes. If you have DC locality in
your sites this should not be a major problem. How big is the xml file and
are your sites on a LAN/WAN? Performance would depend on the actual keys
being set and their data values.
When you say "if GPPs were used to set the equivalent registry keys rather
than using GPOs", how would you set such keys using GPOS? Are you using a
custom .adm template or is it the security on the registry keys you are
setting?
Regards,
Darragh O'Shaughnessy
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: 01 September 2010 10:59
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator
group, and hence knowledgeable users can change GPO applied registry keys to
a new value. The default policy processing behaviours for GPOs will NOT
re-apply the GPO value until the GPO is changed (new settings or version
etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply
registry settings at computer startup and user logon and during periodic
background processing (every 90 minutes) by the following setting:
<javascript:void();> Registry policy processing
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning
and Deployment Guide "Process even if the Group Policy objects have not
changed. If GPOs on the server do not change, it is not usually necessary to
continually reapply them to the destination computer, except to override
possible local changes. Because users who are running as local
administrators might be able to modify the parts of the registry where Group
Policy settings are stored, you might want to reapply these policy settings
as needed during the logon process or during periodic background processing
to return the computer to the desired state." Ref:
http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in
terms of the potential increase in network traffic and the additional load
placed on the domain controllers. What I would like to understand (the crux
of my question) is likely performance impact on the user's computer of
registry values being re-applied every 90 minutes. We have less than 100
registry keys that would ever be re-applied. How would this compare to the
processing load of GPPs (with their default policy processing behavior of
re-applying registry keys during periodic background processing ) if GPPs
were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background
processing" but the issue with setting that as well is that IF a computer
(particularly a laptop) is not actually rebooted AFTER a new or modified
GPO is released then the new or modified computer settings will not be
refreshed on that computer until it reboots which is an unacceptable
"currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| Syspro
Posts:0
| | 09/01/2010 3:29 PM |
| Hi Gavin,
No, I wasn't comparing GPP against the Registry Processing (ADM(X)
Templates), I was just comparing Registry Processing every time against
Registry Processing only when the Policy Changes.
I would consider GPP and "Registry Processing every time" very predictable.
Alan Cuthbertson
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Parker, Gavin S
Sent: Wednesday, 1 September 2010 9:11 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Greetings Alan - I have met you before @ Tech-Ed in Sydney. Thanks for your
interesting feedback. I did not realize that your very handy & free tool
"Policy Log Reporter' now does Preference logging - that is excellent news.
This will allow me to compare processing times between a set of equivalent
GPO versus GPP applied reg keys.
Do I gather from your comment "I would recommend always applying policies
even if they haven't changed because it gives a more predictable result"
that GPPs do not give as predictable a results compared to GPOs?
Regards Gavin
Gavin Parker | IT Domain Specialist
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Alan and Margaret Cuthbertson
Sent: Wednesday, 1 September 2010 9:00 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Hi Gavin,
(an answer from OZ!)
The load in either case will be quite small. Registry processing involves
taking the equivalent of a RegEdit file and applying it to the registry. For
100 keys it will be around 5K and the load to apply it will be small. GPP is
more verbose and so the file is likely be around 20K. The work involved in
applying it will be greater than for Registry files since it has to parse
the xml file and apply a lot more logic. Having said that it will still be
vanishingly small.
In fact you will get a much bigger hit from working out whether the policy
needs to be applied rather than doing the actual application of it. I would
recommend always applying policies even if they haven't changed because it
gives a more predictable result.
Alan Cuthbertson (Melbourne)
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 Parker, Gavin S
Sent: Wednesday, 1 September 2010 7:59 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator
group, and hence knowledgeable users can change GPO applied registry keys to
a new value. The default policy processing behaviours for GPOs will NOT
re-apply the GPO value until the GPO is changed (new settings or version
etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply
registry settings at computer startup and user logon and during periodic
background processing (every 90 minutes) by the following setting:
<javascript:void();> Registry policy processing
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning
and Deployment Guide "Process even if the Group Policy objects have not
changed. If GPOs on the server do not change, it is not usually necessary to
continually reapply them to the destination computer, except to override
possible local changes. Because users who are running as local
administrators might be able to modify the parts of the registry where Group
Policy settings are stored, you might want to reapply these policy settings
as needed during the logon process or during periodic background processing
to return the computer to the desired state." Ref:
http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in
terms of the potential increase in network traffic and the additional load
placed on the domain controllers. What I would like to understand (the crux
of my question) is likely performance impact on the user's computer of
registry values being re-applied every 90 minutes. We have less than 100
registry keys that would ever be re-applied. How would this compare to the
processing load of GPPs (with their default policy processing behavior of
re-applying registry keys during periodic background processing ) if GPPs
were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background
processing" but the issue with setting that as well is that IF a computer
(particularly a laptop) is not actually rebooted AFTER a new or modified
GPO is released then the new or modified computer settings will not be
refreshed on that computer until it reboots which is an unacceptable
"currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
| dmarelia
Posts:394
| | 09/01/2010 6:12 PM |
| Gavin-
I think the comments so far have gotten to your original questions, but I'm going to open it up a bit and suggest that what you're doing by granting users local admin rights and then trying to rely on policy to clean up after their potential bad behavior is probably not the greatest solution in the long run. I'm not sure what business requirements you have for doing this but I would suggest that in today's world of malware and rootkits, making your users local admin is just asking for trouble. No amount of policy is going to fix that. I've said in the past that using Group Policy to lockdown desktops of users who are local admin is a waste of time-policy is absolutely useless in those cases, except as an obfuscation that will only slow down the least intrepid of users.
Hope that helps.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Alan and Margaret Cuthbertson
Sent: Wednesday, September 01, 2010 6:22 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Hi Gavin,
No, I wasn't comparing GPP against the Registry Processing (ADM(X) Templates), I was just comparing Registry Processing every time against Registry Processing only when the Policy Changes.
I would consider GPP and "Registry Processing every time" very predictable.
Alan Cuthbertson
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Parker, Gavin S
Sent: Wednesday, 1 September 2010 9:11 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Greetings Alan - I have met you before @ Tech-Ed in Sydney. Thanks for your interesting feedback. I did not realize that your very handy & free tool "Policy Log Reporter' now does Preference logging - that is excellent news. This will allow me to compare processing times between a set of equivalent GPO versus GPP applied reg keys.
Do I gather from your comment "I would recommend always applying policies even if they haven't changed because it gives a more predictable result" that GPPs do not give as predictable a results compared to GPOs?
Regards Gavin
Gavin Parker | IT Domain Specialist
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Alan and Margaret Cuthbertson
Sent: Wednesday, 1 September 2010 9:00 PM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] Another GPO question from OZ
Hi Gavin,
(an answer from OZ!)
The load in either case will be quite small. Registry processing involves taking the equivalent of a RegEdit file and applying it to the registry. For 100 keys it will be around 5K and the load to apply it will be small. GPP is more verbose and so the file is likely be around 20K. The work involved in applying it will be greater than for Registry files since it has to parse the xml file and apply a lot more logic. Having said that it will still be vanishingly small.
In fact you will get a much bigger hit from working out whether the policy needs to be applied rather than doing the actual application of it. I would recommend always applying policies even if they haven't changed because it gives a more predictable result.
Alan Cuthbertson (Melbourne)
Policy Management Software (Now with ADMX and Preference support):-
http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml
ADM Template Editor(Now with ADMX support):-
http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml
Policy Log Reporter - including Preference logging(Free)
http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Parker, Gavin S
Sent: Wednesday, 1 September 2010 7:59 PM
To: 'xxxxxxxxxxxxxxxx'
Subject: [gptalk] Another GPO question from OZ
Hi
In our company we allow computer users membership of the local Administrator group, and hence knowledgeable users can change GPO applied registry keys to a new value. The default policy processing behaviours for GPOs will NOT re-apply the GPO value until the GPO is changed (new settings or version etc) or any other GPO in scope of the user/computer had changed.
To get around this we could enable registry policy processing to re-apply registry settings at computer startup and user logon and during periodic background processing (every 90 minutes) by the following setting:
Registry policy processing<javascript:void();>
Process even if the Group Policy objects have not changed
Enabled
This is what Microsoft says about this option in their Group Policy Planning and Deployment Guide "Process even if the Group Policy objects have not changed. If GPOs on the server do not change, it is not usually necessary to continually reapply them to the destination computer, except to override possible local changes. Because users who are running as local administrators might be able to modify the parts of the registry where Group Policy settings are stored, you might want to reapply these policy settings as needed during the logon process or during periodic background processing to return the computer to the desired state." Ref: http://technet.microsoft.com/en-us/library/cc754948(WS.10).aspx
However there would presumably be some cost in applying this setting in terms of the potential increase in network traffic and the additional load placed on the domain controllers. What I would like to understand (the crux of my question) is likely performance impact on the user's computer of registry values being re-applied every 90 minutes. We have less than 100 registry keys that would ever be re-applied. How would this compare to the processing load of GPPs (with their default policy processing behavior of re-applying registry keys during periodic background processing ) if GPPs were used to set the equivalent registry keys rather than using GPOs?
PS - I know there is the setting "Do not apply during periodic background processing" but the issue with setting that as well is that IF a computer (particularly a laptop) is not actually rebooted AFTER a new or modified GPO is released then the new or modified computer settings will not be refreshed on that computer until it reboots which is an unacceptable "currency" problem.
Many thanks
Gavin Parker | IT Domain Specialist
Australia
| | | |
|
|