Question

Locked

Old GPO settings keep returning

By wilde ·
Situation:
Multiple DC's running 2003 R2 SP2
One domain
Clients running XP SP2
Default Domain Policy is untouched

The problem:
A Custom GPO with Internet Explorer 6.1 settings, such as Starting page and Proxy settings. These settings have changed and have become more complex. So I decided to setup a new GPO for a select test group.
This seemed to work after several dozen logons from various workstations, so it was time to go live.
The old GPO was emptied and deleted and replaced with the new one. However, the old settings are still being displayed. A GPO Result query returned the settings coming from a GPO with one of those {FE525-....} names.
Now since this is a fairly large network I blamed it on replication issues, but this turned out to be a wild goose chase because every other (minor) change to GPO's replicated like the wind.
Since this wasn't a really big problem and there is other work to be done I decided to let it rest for a couple of days, but even after that the queries still returned the same.
I decided to get the old GPO back, which I backed up, and remove the newly made.
It loaded to the clients like it should. So I made the necessary changes in that GPO just to see what would happen.
Nothing! Not one thing changed. GPO Result queries kept returning the old values coming from the newly edited and correct GPO.

It has me stumped.

This conversation is currently closed to new comments.

14 total posts (Page 1 of 2)   01 | 02   Next
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Try removing

by IC-IT In reply to Old GPO settings keep ret ...

the Link to any and all OUs first. Then delete it or simply leave it unlinked.

Collapse -

Re: try removing

by wilde In reply to Try removing

Thanks. I tried that already. That is part of my procedure, like clearing out policies before deleting them. Bad experiences with custom ADM's tought me that.

I was typing my previous reply at the same time as your post. In it I wrote that I found the source of the problem, albeit not a solution.

Collapse -

Update

by wilde In reply to Old GPO settings keep ret ...

I took a few pc's from a batch of freshly imaged workstations and added them to the domain. I was surprised to see everything worked as it should be.
So it seems, although Microsoft states otherwise, that GPO are stored/cached locally.
To test this theory, I took one of the workstations that went wrong with the GPO and removed it from the domain. I removed everything that resembled cache or and any other remnants from it previous domain membership. Next I added it to the domain again. But yeah, the old error, the old, removed GPO came back again.

So, although it seems clear that the problem resides on a workstation level, I am still not sure what causes it.

I would like to know, because in the future, when this problem possible arises again, I want to be able to solve it without imaging 600+ workstations.

Collapse -

If you have isolated it to the workstation level

by Tig2 In reply to Update

Try a registry cleaner run recursively. I like CCleaner because it is free and effective. If it works for you, you can then go look for a more global solution. If it doesn't, you've lost nothing.

www.ccleaner.com

Just remember, you have to run it repeatedly until it finds no more errors.

Good luck!

Collapse -

No cigar

by wilde In reply to If you have isolated it t ...

I like ccleaner as well, but I've never used in a professional setup. But hey, as I am up that creek without the proverbial paddle, why not?

I ran it several times under different accounts, including 'local admin' on two workstations, but it didn't change a thing.

So, the question remains, where is this type of data stored and how can it be countered?

Collapse -

This is screwy

by IC-IT In reply to Update

Normally when the user logs on and interactive mode is on if a workstation can not connect to the DC then a cached version is loaded. That could cause an old Policy to still be present. But these ones are clearly connecting.
Is there any chance that the affected computers or user name does not have read and execute privleges on the policy?

The DC path for GPOs would be %systemroot%\sysvol\domainname\Policies\POLICYGUID\Adm

unless Automatic Update (of ADM) is turned off. See this link for more info;
http://support.microsoft.com/kb/316977

the local machine in the hidden folder C:\WINDOWS\system32\GroupPolicy

A gpudate /force hasn't helped either?

Collapse -

screwy indeed

by wilde In reply to This is screwy

Yeah, I was thinking in that direction as well about the cache. But it is policy (one that works :)) that workstations can't log on without a DC. So yeah, they are connecting.

The path on the DC is correct and all the ADM's are current. The old one, the mystery GPO, is nowhere to be found.

Automatic Update of ADM has been on for a day and a half now, but I haven't seen any difference.

That hidden folder you describe .... now that is what I am looking for. I've seen it being mentioned in various articles, but our workstations don't have that. Are you sure that applies to a 2003 domain?
I have to add, I have checked for that folder on the machines that went bad, the machines that logged on when something was screwy in the GPO, but I haven't checked it with the newly imaged machines. I doubt there is a difference, though.

I have created batch files for GPUPDATE /FORCE because I ran that 100 times a hour :)

Collapse -

A couple of suggestions

by NaughtyMonkey In reply to Old GPO settings keep ret ...

Is it possible there is a slow link causing the policy to not apply correctly at login, using a cached version. You can setup slow link detection to see if it helps. Here is a link:

http://tinyurl.com/23xba7

Slao there is a problem with slow/fast link detection an ICMP packet size that could cause this. Look here for info:

http://tinyurl.com/22bf4v

Other options:

Is it on laptops, desktops, or both? Do they use wireless? Is that policy being forced or is there another that is being forced and overwriting it? Are there any errors in the logs (server and client)? Is it being applied in the correct order?

Hope these ideas help. GPOs can suck sometimes.

Collapse -

thanks

by wilde In reply to A couple of suggestions

A slow link would surprise me, the clients are on a 100Mb LAN connected directly to a local serverpark on a 1Gb backbone.

I might have to add that this only happens to workstations that were logged on at the time it went wrong. Now, newly imaged workstations run all GPO's perfectly. The older ones just won't update.

Untill now it were just desktops, no wireless (brr:(). No GPO's overlap, so nothing is being overwriten. The 'winning policy' is always the one with the only settings.

And no, I wish, no relevant log entries, not on the server nor on the clients. Especially the latter surprises me a little.

I will look into your posted links though, thanks.

Collapse -

Just a thought...

by NaughtyMonkey In reply to thanks

but probably not true. If you use the same hardware config there could be an issue with the NICs initializing late and causing the cached policy to load. Same result of a slow link, different cause. I have seen this on a single machine but not across a whole network.<br><br>

Also,<br><i>The 'winning policy' is always the one with the only settings.</i><br><br>This is not true. GPO results depend on the precedence, status, settings, enabling, and enforcement. It is not a simple thing and can easily be mucked up.

Back to Networks Forum
14 total posts (Page 1 of 2)   01 | 02   Next

Related Forums