GPO - tatoo themselves to my machine

[somejoe]

Hi guys,

Theory and practice are not matching up. Group Policies are not supposed to tattoo themselves to a computer - especially not "User" Group Policies.

I setup test "User" Policies and logged onto my laptop. I then took myself out of the OU that had the GPO associated with it. However, when I log on, I still see the effects of the policy. If a log onto a different 2k computer I don't see the policies. But, I can't remove the effect of the user policies from my laptop.

Any suggestions. I know that this is not supposed to happen.

 

[globalstrata]

Actually, that is the way Policies are supposed to work. If you want to delete the effects of a policy, create a TEMP OU. Then Add a Policy\Select All\Default Domain Policy
Gladys Rodriguez
GlobalStrata Solutions

http://www.globalstrata.com

 

[somejoe]

No, that's the way System Policies worked under NT 4.0.

2000 was supposed to get past this. Policies are applied at logon (for user policies) or boot up (for computer policies). If you move a user/computer out of an OU that had a policy applied to it, the policy would remove itself after the refresh period or reboot/relogon.

2000 Group Policies are NOT supposed to Tattoo themselves permanently onto the computer!!!

I tried to find a link to support my view but i couldn't. However, I just read a book on the subject and it reiterates this several times.

 

[Davetoo]

But if you move a computer from OU "A" that has a policy applied, to OU "B", that does not have a policy applied, what policy is the computer supposed to take? If there is no policy applied to OU "B", then the computer being moved can not inherit any policy. So, it makes sense that if you move a computer from an OU that did have a policy applied, to an OU that did not have a policy applied, that the computer would retain the policy from OU "A".

At least to me, that makes sense. If I wanted to remove a policy that had been applied to a computer, I would do like Gladys said, create an OU with a default policy as a median step to moving a computer out of an OU that had a policy applied to it.

 

[somejoe]

Hmmmm. . . .

What you say makes sense on one level, but in answer to your question.

If you move a computer (or in this case a user) from OU "A" to OU "B" what GPO would it inherit if OU "B" does not have a GPO associated with it?

The answer is that it would just inherit the Default Domain Policy. Or at least that seems like what the theory tells me.

 

[Davetoo]

But I don't believe the default domain policy applies to OU's?

 

[somejoe]

Here is a White Paper that supports what I'm talking about. That GPO's set policies that are removed if the link to the GPO or the GPO itself are removed.

http://www.microsoft.com/windows2000/docs/rbppaper.doc

I am reffering to "Policies" not "Preferences" in the NT sense.

The below quote is in the article above:

"If both a policy and preference are present, the preference will be successfully restored if the policy is removed or disabled. Preference settings persist in the registry until they are reversed by a counteracting policy setting or by editing the registry."

 

[somejoe]

You said:
"But I don't believe the default domain policy applies to OU's? "

Are you kidding? If not what does it apply to?


Policies inherit unless blocked. They inherit as follows

Site - Domain - OU (from top to bottom)

The bottom one's can overwrite the top ones unless "No Override" is specified.

 

[Davetoo]

I'd think it would apply to the default domain. When you create an OU, does the default domain policy apply? I base my answer/inquiry upon your findings...that when you had a computer in OU "A" with a policy applied, that policy remained even after you removed it from OU "A" into OU "B", to which the default policy should apply, correct? So, when you did this, and the policy from OU "A" remained, I theorized that the default domain policy was not being applied to OU "B" by your findings.

Of course, my assumption was that you had not blocked inheritance in OU "B", as then your whole question would be moot and a silly waste of time. ;-)

 

[Davetoo]

Ok, I had a minute to test this on my test servers. I had a highly restrictive GPO applied to an OU that I moved a computer into. GPO applied correctly and locked down the system. I then moved the computer to a different OU which did not have a specific GPO applied to it. Result? The computer was still locked down.

This tells me that the default domain policy is not applied to the OU, even though it is the default "Computer" in my AD.

 

[somejoe]

"When you create an OU, does the default domain policy apply?"


I believe the theoretical answer is yet, but in my situation GPO's are not updating properly. I believe my GPO infrustructure is somewhat buggy. BIG SURPRISE!!

I just need a fix and I can't get one. I'll try the OU GPO default thingy.

 

[somejoe]

WOW, I really appreciate you taking the time to do that!!!

Are you sure you waited long enough for the GPO/OU replication to take place?

Are you sure everything is updated??

 

[Davetoo]

Yes, I forced the replication manually, and also waited for the default replication to occur (just for fun).

The odd thing is we both agree that the default policy should apply to OU's unless it is explicitly blocked...but it's not. Hmmmmm...me thinks we're missing something somewhere.

Back to my lab (ok...ok...my "lab" is two old computers sitting on a desk in my tiny office, but hey...it works!)

 

[somejoe]

Yes, Sounds like the EXACT same situation I've had.

It runs contrary to the purported theory and I've not found any technet on it (i've been researching for the last 2 weeks on and off.)

If I find anything, I'll post it.

I'll go back to my lab (which consists of 14 domain controllers and 500 users). Nothing like the MONKEY/user when it comes time for testing.

 

[Davetoo]

somejoe,

I think I've figured out the problem...apples and oranges. I was working with a Computer OU, your original question dealt with a user OU.

Delete the local profile of the user on the local machine, then log on and all should be normal.

What I can't figure out is I applied those MS Intellimirror scenarios to test with, and I get this special screen that warns that only legit users should try to log on to this computer whenever my test station boots. No matter what I do to the Computer OU, it remains.

 

[somejoe]

Yes, that should "take care" of the problem, but that should not be required according to theory. Also, I have to migrate favorits, data, my documents etc. Which is a big pain in the axx.

Your error is strange. What's the exact error you get? Does it happen even after you remove the computer??

 

[somejoe]

I solved my problem. There just too damn many changes.


Back with 2000 Professional you would type "secedit /refreshpolicy" to refresh all GPO's

Now with XP Professional you type "GPRESULT /FORCE" and it will update your policies. It does not work to just type "GPRESULT" as there merely assesses what you have already.

Anyways, I did the the GPRESULT /FORCE and it took care of the problem.

 

[somejoe]

I just reread my last comment and i made a mistake.

GPUPATE (with or without the /force) will update your policies with the server

GPRESULT will tell you your RSOP - resultant set of policies.

Either way, it was by using GPUPDATE that I managed to get rid of the unwanted policies. It should happen automatically but it wasn't.

 

[Davetoo]

Did you do this at the server or at the client? I'll have to try it, I hadn't run into that one before.

 

[Davetoo]

Ok, this must be on the XP client side, as the GPUPDATE and GPRESULT are not available on the W2K server or client.