GPOs don't refresh 2

[LawnBoy]

When I create a new GPO the users get all the settings and everything works great. But if I edit an existing GPO, the changed settings don't propagate to the users, the behavior never changes.

When I look at the GPO with gpmc it shows the changes. Gpresult show the GPO as being enforced. I've waited weeks in some cases.

Any help is appreciated.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[FloDiggs]

It should refresh every 90 minutes or so. If not, try doing a gpupdate from your command line. If the policy has changed, you shouldn't need the /force. You can find more info here:

http://technet2.microsoft.com/windo...8c85-4a17-8fff-481af6eaedf01033.mspx?mfr=true

I've also seen this kind of thing when there are replication problems between DCs.

 

[zram]

Go to a computer that should be receiving the policy changes and go start/run - MMC - Add in RSOP. Run RSOP and look to what policy each setting is coming from.

 

[LawnBoy]

RSOP shows the new settings in the appropriate GPO. Yet the client behavior has not changed.

For instance, I've a GPO that sets the Office template path to a server share. I've change the location of that share, but the clients are still pointed at the old share. I made this change 3 weeks ago.

Since RSOP shows the change, I assume that replication is working properly. I'm not sure if this is affecting all of the clients, but it is affecting many of them.

Should I delete the GPO and create a new one?
Any other suggestions?

thx.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[zram]

RSOP shows you what the affective policy setting is to your local computer. So if its showing up in RSOP then its being applied correctly.

 

[LawnBoy]

They're not being applied correctly, thus my question.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[m1ckG]

Hi,

Just a thought check the GPO as to what setting is disabled i.e computer or user.



MCSA

 

[FloDiggs]

Just to verify, your user account and the computer account are both in the OU that the policy is applied to?

 

[LawnBoy]

No, the users are not in the same OU as the computers. They have the same parent OU. In the example I gave, the policy is applied to the users OU.

My strategy is that if a GPO has both computer and user settings, I apply it to the parent OU. If the GPO has only user settings I apply it to the user OU, if it has just computer settings I apply it to the computer OU.

I'm a Netware guy trying to get used to AD, so I still think in Netware methods. If I should be doing things differently, please educate me.

thx.

"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[terry712]

let me get this right

you can create a gpo - lets say for instances - pink wallpaper. you apply this and it's all ok - fred gets his pink wallpaper.

fred then wants blue wallpaper - so you modify the policy but he is stuck with pink.

so works first time but doesnt like edit's ?

strategy is fine in my book - i dont really beleive there is a definative answer - splitting them seems easier to me though

 

[LawnBoy]

so works first time but doesnt like edit's ?

Exactly. It's as if the clients don't realize the policy has changed. Gpupdate /force doesn't help.

Any new-built machine freshly added to AD picks up the altered settings.

"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[baddos]

In the event viewer of machine's affected by this policy, does it have any error messages? Sometimes GPs will fail on something and will stop processing the rest of the GP.

 

[LawnBoy]

No error messages. I'm utterly stumped.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[terry712]

is there any clues - in the c:\windows\security\logs

there should be a few txt files

also i assume these are xp - so will process the policy asych by default - there is a setting and i cant remeber of top of head - but it's something like always wait for network
means policies go back to 2000

should matter but worth peaking

is this on all pc's or just test one

there are no loopback policies ?

 

[LawnBoy]

Well as of this morning, some of the policies have refreshed on some of the clients. pffffft.

No loopbacks, at least 20% of the clients affected. Will look into the wait for network setting, although the W2k clients are not having this problem.

Thanks.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[terry712]

2000 clients dont utilise this behaviour - as they process synchronusly (or something like that)

xp do it asynch - ie they cache the policy - hence sometimes policies take about 3 reboots /logins to reflect the new policy - if you have staic policies not a problem

the wait for network - effectively process them as if pc's are 2000

 

[pagy]

I've had something similiar in the past, I think the setting Terry is talking about is
Always wait for the network at computer startup and logon

We've had to use a gpo to push that setting out when we've had similair experiences to yours.

It's a computer gpo, Admin templates - System - Logon

Paul
MCSE 2003
MCTS:Active Directory
MCTS:Network Infrastructure
MCTS:Applications Infrastructure

If there are no stupid questions, then what kind of questions do stupid people ask? Do they get smart just in time to ask questions?
Scott Adams

 

[LawnBoy]

I'll give it a go and see what happens.
Thanks much.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes

 

[LawnBoy]

This is helping. It's taking a while to refresh the cached policies, but everyday I'm finding more machines sync'ed up.
Thanks again.


"We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth." - Sherlock Holmes