Performance problem when domain security policies are appl..

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Hi there,

I'm not sure if this is the correct group to post this
question. But hopefully someone can help me.

I was wondering if anyone have noticed a problem with the
way windows 2000 applies the security policies when
updating group policy objects on machines in a domain.
What I have noticed is that every time this occurs (every
16 hours by default) the machine uses 100% CPU time for
about 5 to 10 seconds (maybe even longer if machine specs
are low) and the machine appears to slow down - I presume
this is because the security updates are being applied.

This problem can also be observed when you force a
security update by typing in the command line:
secedit /refreshpolicy {machine_policy |
user_policy} /enforce

The effect of this is that one of my processes suffers a
performance hit because it has been denied CPU process
time during the period of this security update.

So, what I would like to know is if this update
characteristic is normal on domain machines and if so, is
there a way to customise and minimise what security
policies are being updated so to reduce this performance
problem.

Thanks in advance,

Lee

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Lee-
This will typically happen if you're using some part of security policy that
is particularly expensive, such as registry or file system security, esp.
against many files or keys. Frankly, I try to avoid using GP to set these
types of security on large sets of files or keys, since it can impact the
client system so heavily. Are you using one or more of these?

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related



"Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
news:39f701c4a56f$147102c0$a301280a@phx.gbl...
> Hi there,
>
> I'm not sure if this is the correct group to post this
> question. But hopefully someone can help me.
>
> I was wondering if anyone have noticed a problem with the
> way windows 2000 applies the security policies when
> updating group policy objects on machines in a domain.
> What I have noticed is that every time this occurs (every
> 16 hours by default) the machine uses 100% CPU time for
> about 5 to 10 seconds (maybe even longer if machine specs
> are low) and the machine appears to slow down - I presume
> this is because the security updates are being applied.
>
> This problem can also be observed when you force a
> security update by typing in the command line:
> secedit /refreshpolicy {machine_policy |
> user_policy} /enforce
>
> The effect of this is that one of my processes suffers a
> performance hit because it has been denied CPU process
> time during the period of this security update.
>
> So, what I would like to know is if this update
> characteristic is normal on domain machines and if so, is
> there a way to customise and minimise what security
> policies are being updated so to reduce this performance
> problem.
>
> Thanks in advance,
>
> Lee
>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Darren,

Thanks for your reply. We don't use registry or file system security. Our
setup is basically not very different from the default domain security
setting. We haven't added anything we feel that would put a big load on
client systems. Do you notice this perfromance problem on machine when you
force a security update using secedit /refreshpolicy {machine_policy
|user_policy} /enforce

Lee

"Darren Mar-Elia" wrote:

> Lee-
> This will typically happen if you're using some part of security policy that
> is particularly expensive, such as registry or file system security, esp.
> against many files or keys. Frankly, I try to avoid using GP to set these
> types of security on large sets of files or keys, since it can impact the
> client system so heavily. Are you using one or more of these?
>
> --
> Darren Mar-Elia
> MS-MVP-Windows Server--Group Policy
> Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
> FAQs, Whitepapers and Utilities for all things Group Policy-related
>
>
>
> "Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
> news:39f701c4a56f$147102c0$a301280a@phx.gbl...
> > Hi there,
> >
> > I'm not sure if this is the correct group to post this
> > question. But hopefully someone can help me.
> >
> > I was wondering if anyone have noticed a problem with the
> > way windows 2000 applies the security policies when
> > updating group policy objects on machines in a domain.
> > What I have noticed is that every time this occurs (every
> > 16 hours by default) the machine uses 100% CPU time for
> > about 5 to 10 seconds (maybe even longer if machine specs
> > are low) and the machine appears to slow down - I presume
> > this is because the security updates are being applied.
> >
> > This problem can also be observed when you force a
> > security update by typing in the command line:
> > secedit /refreshpolicy {machine_policy |
> > user_policy} /enforce
> >
> > The effect of this is that one of my processes suffers a
> > performance hit because it has been denied CPU process
> > time during the period of this security update.
> >
> > So, what I would like to know is if this update
> > characteristic is normal on domain machines and if so, is
> > there a way to customise and minimise what security
> > policies are being updated so to reduce this performance
> > problem.
> >
> > Thanks in advance,
> >
> > Lee
> >
> >
> >
>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

There are a couple of things to note. First, the every 16 hour security
update that happens is different from doing a secedit /enforce. The latter
will actually run every client side extension--not just security--and on
that you will definitely notice a performance impact if you have a lot of
policies. In terms of performance impact on the security stuff, it really
depends upon what you're setting--some settings are more "expensive" than
others. What I would do is enable verbose security policy logging (check out
my ADM for GP logging at www.gpoguy.com/tools.htm --it contains and option
to enable this) and see where its spending time. You can always decrease the
frequency of the every 16 hour update via registry setting if needed.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related



"Lee_Lieu" <Lee_Lieu@discussions.microsoft.com> wrote in message
news:F0302250-49CA-4F28-8FA7-ED6DCD0F6A21@microsoft.com...
> Darren,
>
> Thanks for your reply. We don't use registry or file system security. Our
> setup is basically not very different from the default domain security
> setting. We haven't added anything we feel that would put a big load on
> client systems. Do you notice this perfromance problem on machine when you
> force a security update using secedit /refreshpolicy {machine_policy
> |user_policy} /enforce
>
> Lee
>
> "Darren Mar-Elia" wrote:
>
>> Lee-
>> This will typically happen if you're using some part of security policy
>> that
>> is particularly expensive, such as registry or file system security, esp.
>> against many files or keys. Frankly, I try to avoid using GP to set these
>> types of security on large sets of files or keys, since it can impact the
>> client system so heavily. Are you using one or more of these?
>>
>> --
>> Darren Mar-Elia
>> MS-MVP-Windows Server--Group Policy
>> Check out http://www.gpoguy.com -- The Windows Group Policy Information
>> Hub:
>> FAQs, Whitepapers and Utilities for all things Group Policy-related
>>
>>
>>
>> "Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
>> news:39f701c4a56f$147102c0$a301280a@phx.gbl...
>> > Hi there,
>> >
>> > I'm not sure if this is the correct group to post this
>> > question. But hopefully someone can help me.
>> >
>> > I was wondering if anyone have noticed a problem with the
>> > way windows 2000 applies the security policies when
>> > updating group policy objects on machines in a domain.
>> > What I have noticed is that every time this occurs (every
>> > 16 hours by default) the machine uses 100% CPU time for
>> > about 5 to 10 seconds (maybe even longer if machine specs
>> > are low) and the machine appears to slow down - I presume
>> > this is because the security updates are being applied.
>> >
>> > This problem can also be observed when you force a
>> > security update by typing in the command line:
>> > secedit /refreshpolicy {machine_policy |
>> > user_policy} /enforce
>> >
>> > The effect of this is that one of my processes suffers a
>> > performance hit because it has been denied CPU process
>> > time during the period of this security update.
>> >
>> > So, what I would like to know is if this update
>> > characteristic is normal on domain machines and if so, is
>> > there a way to customise and minimise what security
>> > policies are being updated so to reduce this performance
>> > problem.
>> >
>> > Thanks in advance,
>> >
>> > Lee
>> >
>> >
>> >
>>
>>
>>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Lee,

In addition to what Darren has suggested, I might suggest that this is
normal behavior. Every 16 hours Workstations and Member Servers ask the
Domain Controllers for the latest Group Policies. All of them!

This is where all of the GPOs are brought down to the machine. It is the
same thing as doing the secedit /refreshpolicy machine_policy/enforce. It
is the /enforce that gives it the 'umph!'. It is saying, "Do not bring down
only the new changes since the last time, bring them all down!". It is a
way of making sure that the settings remain in effect. And that all of the
workstations have the latest policies.

Do not get this confused with the background policy processing. This is
what happens every 90 minutes on Workstations and Member Servers ( with an
+/- offset ) and every five minutes on Domain Controllers.

Does this help?

Cary

"Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
news:39f701c4a56f$147102c0$a301280a@phx.gbl...
> Hi there,
>
> I'm not sure if this is the correct group to post this
> question. But hopefully someone can help me.
>
> I was wondering if anyone have noticed a problem with the
> way windows 2000 applies the security policies when
> updating group policy objects on machines in a domain.
> What I have noticed is that every time this occurs (every
> 16 hours by default) the machine uses 100% CPU time for
> about 5 to 10 seconds (maybe even longer if machine specs
> are low) and the machine appears to slow down - I presume
> this is because the security updates are being applied.
>
> This problem can also be observed when you force a
> security update by typing in the command line:
> secedit /refreshpolicy {machine_policy |
> user_policy} /enforce
>
> The effect of this is that one of my processes suffers a
> performance hit because it has been denied CPU process
> time during the period of this security update.
>
> So, what I would like to know is if this update
> characteristic is normal on domain machines and if so, is
> there a way to customise and minimise what security
> policies are being updated so to reduce this performance
> problem.
>
> Thanks in advance,
>
> Lee
>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Actually Cary, the every 16 hour thing only applies to security policy--not
all policy. This is specific to the client side extension for security
processing.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related



"Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
news:ekU7WRXpEHA.2636@TK2MSFTNGP09.phx.gbl...
> Lee,
>
> In addition to what Darren has suggested, I might suggest that this is
> normal behavior. Every 16 hours Workstations and Member Servers ask the
> Domain Controllers for the latest Group Policies. All of them!
>
> This is where all of the GPOs are brought down to the machine. It is the
> same thing as doing the secedit /refreshpolicy machine_policy/enforce. It
> is the /enforce that gives it the 'umph!'. It is saying, "Do not bring
> down
> only the new changes since the last time, bring them all down!". It is a
> way of making sure that the settings remain in effect. And that all of
> the
> workstations have the latest policies.
>
> Do not get this confused with the background policy processing. This is
> what happens every 90 minutes on Workstations and Member Servers ( with an
> +/- offset ) and every five minutes on Domain Controllers.
>
> Does this help?
>
> Cary
>
> "Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
> news:39f701c4a56f$147102c0$a301280a@phx.gbl...
>> Hi there,
>>
>> I'm not sure if this is the correct group to post this
>> question. But hopefully someone can help me.
>>
>> I was wondering if anyone have noticed a problem with the
>> way windows 2000 applies the security policies when
>> updating group policy objects on machines in a domain.
>> What I have noticed is that every time this occurs (every
>> 16 hours by default) the machine uses 100% CPU time for
>> about 5 to 10 seconds (maybe even longer if machine specs
>> are low) and the machine appears to slow down - I presume
>> this is because the security updates are being applied.
>>
>> This problem can also be observed when you force a
>> security update by typing in the command line:
>> secedit /refreshpolicy {machine_policy |
>> user_policy} /enforce
>>
>> The effect of this is that one of my processes suffers a
>> performance hit because it has been denied CPU process
>> time during the period of this security update.
>>
>> So, what I would like to know is if this update
>> characteristic is normal on domain machines and if so, is
>> there a way to customise and minimise what security
>> policies are being updated so to reduce this performance
>> problem.
>>
>> Thanks in advance,
>>
>> Lee
>>
>>
>>
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Yep!

You are correct. It is the security settings, not all of them. Strike two
on me!

Cary

"Darren Mar-Elia" <dmanonymous@discussions.microsoft.com> wrote in message
news:%23$mR2TXpEHA.800@TK2MSFTNGP14.phx.gbl...
> Actually Cary, the every 16 hour thing only applies to security
policy--not
> all policy. This is specific to the client side extension for security
> processing.
>
> --
> Darren Mar-Elia
> MS-MVP-Windows Server--Group Policy
> Check out http://www.gpoguy.com -- The Windows Group Policy Information
Hub:
> FAQs, Whitepapers and Utilities for all things Group Policy-related
>
>
>
> "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> news:ekU7WRXpEHA.2636@TK2MSFTNGP09.phx.gbl...
> > Lee,
> >
> > In addition to what Darren has suggested, I might suggest that this is
> > normal behavior. Every 16 hours Workstations and Member Servers ask the
> > Domain Controllers for the latest Group Policies. All of them!
> >
> > This is where all of the GPOs are brought down to the machine. It is
the
> > same thing as doing the secedit /refreshpolicy machine_policy/enforce.
It
> > is the /enforce that gives it the 'umph!'. It is saying, "Do not bring
> > down
> > only the new changes since the last time, bring them all down!". It is
a
> > way of making sure that the settings remain in effect. And that all of
> > the
> > workstations have the latest policies.
> >
> > Do not get this confused with the background policy processing. This is
> > what happens every 90 minutes on Workstations and Member Servers ( with
an
> > +/- offset ) and every five minutes on Domain Controllers.
> >
> > Does this help?
> >
> > Cary
> >
> > "Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
> > news:39f701c4a56f$147102c0$a301280a@phx.gbl...
> >> Hi there,
> >>
> >> I'm not sure if this is the correct group to post this
> >> question. But hopefully someone can help me.
> >>
> >> I was wondering if anyone have noticed a problem with the
> >> way windows 2000 applies the security policies when
> >> updating group policy objects on machines in a domain.
> >> What I have noticed is that every time this occurs (every
> >> 16 hours by default) the machine uses 100% CPU time for
> >> about 5 to 10 seconds (maybe even longer if machine specs
> >> are low) and the machine appears to slow down - I presume
> >> this is because the security updates are being applied.
> >>
> >> This problem can also be observed when you force a
> >> security update by typing in the command line:
> >> secedit /refreshpolicy {machine_policy |
> >> user_policy} /enforce
> >>
> >> The effect of this is that one of my processes suffers a
> >> performance hit because it has been denied CPU process
> >> time during the period of this security update.
> >>
> >> So, what I would like to know is if this update
> >> characteristic is normal on domain machines and if so, is
> >> there a way to customise and minimise what security
> >> policies are being updated so to reduce this performance
> >> problem.
> >>
> >> Thanks in advance,
> >>
> >> Lee
> >>
> >>
> >>
> >
> >
>
>

 

[Guest]

Archived from groups: microsoft.public.win2000.group_policy (More info?)

Thanks guys,

You helped confirm what I suspected was going on. So what I would like to
know is that if all the security settings are applied (even if there have
been no chnages) every 16 hours, is there a way of changing this so that not
all of the security policy are applied (maybe just a selected few). This is
so to minimise the impact on client machines where we have processes that
require a % of the CPU at all times. It appears when this update occurs every
16 hours, it takes up the whole whack and disrupts these porcesses.

Cheers,

Lee

"Cary Shultz [A.D. MVP]" wrote:

> Yep!
>
> You are correct. It is the security settings, not all of them. Strike two
> on me!
>
> Cary
>
> "Darren Mar-Elia" <dmanonymous@discussions.microsoft.com> wrote in message
> news:%23$mR2TXpEHA.800@TK2MSFTNGP14.phx.gbl...
> > Actually Cary, the every 16 hour thing only applies to security
> policy--not
> > all policy. This is specific to the client side extension for security
> > processing.
> >
> > --
> > Darren Mar-Elia
> > MS-MVP-Windows Server--Group Policy
> > Check out http://www.gpoguy.com -- The Windows Group Policy Information
> Hub:
> > FAQs, Whitepapers and Utilities for all things Group Policy-related
> >
> >
> >
> > "Cary Shultz [A.D. MVP]" <cwshultz@mvps.org> wrote in message
> > news:ekU7WRXpEHA.2636@TK2MSFTNGP09.phx.gbl...
> > > Lee,
> > >
> > > In addition to what Darren has suggested, I might suggest that this is
> > > normal behavior. Every 16 hours Workstations and Member Servers ask the
> > > Domain Controllers for the latest Group Policies. All of them!
> > >
> > > This is where all of the GPOs are brought down to the machine. It is
> the
> > > same thing as doing the secedit /refreshpolicy machine_policy/enforce.
> It
> > > is the /enforce that gives it the 'umph!'. It is saying, "Do not bring
> > > down
> > > only the new changes since the last time, bring them all down!". It is
> a
> > > way of making sure that the settings remain in effect. And that all of
> > > the
> > > workstations have the latest policies.
> > >
> > > Do not get this confused with the background policy processing. This is
> > > what happens every 90 minutes on Workstations and Member Servers ( with
> an
> > > +/- offset ) and every five minutes on Domain Controllers.
> > >
> > > Does this help?
> > >
> > > Cary
> > >
> > > "Lee Lieu" <anonymous@discussions.microsoft.com> wrote in message
> > > news:39f701c4a56f$147102c0$a301280a@phx.gbl...
> > >> Hi there,
> > >>
> > >> I'm not sure if this is the correct group to post this
> > >> question. But hopefully someone can help me.
> > >>
> > >> I was wondering if anyone have noticed a problem with the
> > >> way windows 2000 applies the security policies when
> > >> updating group policy objects on machines in a domain.
> > >> What I have noticed is that every time this occurs (every
> > >> 16 hours by default) the machine uses 100% CPU time for
> > >> about 5 to 10 seconds (maybe even longer if machine specs
> > >> are low) and the machine appears to slow down - I presume
> > >> this is because the security updates are being applied.
> > >>
> > >> This problem can also be observed when you force a
> > >> security update by typing in the command line:
> > >> secedit /refreshpolicy {machine_policy |
> > >> user_policy} /enforce
> > >>
> > >> The effect of this is that one of my processes suffers a
> > >> performance hit because it has been denied CPU process
> > >> time during the period of this security update.
> > >>
> > >> So, what I would like to know is if this update
> > >> characteristic is normal on domain machines and if so, is
> > >> there a way to customise and minimise what security
> > >> policies are being updated so to reduce this performance
> > >> problem.
> > >>
> > >> Thanks in advance,
> > >>
> > >> Lee
> > >>
> > >>
> > >>
> > >
> > >
> >
> >
>
>
>