Background refresh of GP

[Jeff]

What are the pros/cons of disabling the background refresh
of GP on the user level? We really dont make changes to
the GP and I believe this is giving us errors. Thanks.

 

[Andrew Mitchell]

What are the pros/cons of disabling the background refresh
of GP on the user level?

Possible security risks and unauthorised changes to PC configurations.
If a user creates a .reg file that alters your GPO settings that have been
applied to their PC it won't be set back until they logout/login again.

We really dont make changes to
the GP and I believe this is giving us errors.

I'd be investigating the cause of the errors. Turning it off would be like
turning up your car radio so you can't hear the clunking sound your engine is
making......

 

[Jeff]

If you look at my previous post this morning (about an
hour before this one), you could see the issue. The
message is called Userenv. Basically, one of the errors
is pointing at invalid handles from the background refresh.

 

[Andrew Mitchell]

If you look at my previous post this morning (about an
hour before this one), you could see the issue. The
message is called Userenv. Basically, one of the errors
is pointing at invalid handles from the background refresh.

If this is a terminal server farm it even more critical that background
refreshes work as a .reg file that alters computer settings will affect all
users logged in to the server, and not just an individual user.

Your problem is probably being caused by incorrect security settings on
registry keys, and not by the background refesh. Turning off the background
refesh is only hiding the symptoms and not addressing the root cause of the
problem.

Have a look here:
http://support.microsoft.com/default.aspx?scid=kb;en-us;319006
&Product=win2000

or
http://tinyurl.com/5p8k2 for a shorter link to the same article.

 

[Jeff]

I assumed as such but when I checked the key (im assuming
these are on HKEY_LM), SYSTEM had Full Control which I
assume is who is modifying the keys.

 

[Andrew Mitchell]

I assumed as such but when I checked the key (im assuming
these are on HKEY_LM),

The key you need to check is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Group Policy\History as stated in the KB article I posted.

SYSTEM had Full Control which I
assume is who is modifying the keys.

That's correct, but you also need to delete any subkeys.

You can then run
secedit /refreshpolicy machine_policy /enforce
to cause the subkeys to be recreated with the correct permissions if you want
them created immediately.

 

[Jeff]

Ok.. I see what you are saying. So all the other errors
are caused BECAUSE of this right? I have a weekly meeting
tomorrow and I want to bring this to light. If we make
these changes:

1. Can users be on the Terminal Server when these changes
are being made?
2. Will a reboot or service restarts be necessary?

Thanks.

 

[Andrew Mitchell]

Ok.. I see what you are saying. So all the other errors
are caused BECAUSE of this right?

That's correct. As a result of not being able to update the GPO history,
Windows will not apply a refresh to the current GPO keys.

I have a weekly meeting
tomorrow and I want to bring this to light. If we make
these changes:

1. Can users be on the Terminal Server when these changes
are being made?

Yes. No interruption to service will (or should...) occur.

2. Will a reboot or service restarts be necessary?

The required keys will be created at the next scheduled refresh or if you run
the secedit command (whichever comes first)
No services will need to be restarted but if you have made any changes to the
GPO's that require a reboot to work, these will not take effect until the
server is restarted.

 

[Jeff]

Thank you for all your help. If you dont mind, id like to
contact you in case this does not fix the problem to see
if you may have any other ideas about this.

 

[Andrew Mitchell]

Thank you for all your help. If you dont mind, id like to
contact you in case this does not fix the problem to see
if you may have any other ideas about this.

That's fine. Contact me at andrew at mitchellclan dot net today though, as
I'm not at work. I'm also going away for the weekend so I won't be available
from about 1:00am tomorrow (Melbourne Australia time)

Andy.