GPO Tattooing? OLD GPOS still applying to the local workstations

[Prophecy]

Scenario:

NEW DC with Server 2003 replaces OLD server 2000

The workstations have been removed and added to the new domain however some of the OLD GPO settings are still set in the workstations. We have of course applied gpupdate /force on all the workstations and rebooted numerous times. However when we log in to the machine I am seeing the settings in the local workstation GPEDIT.MSC are the same in the local security policy even after being added to the new DC.

Any ideas how I can flush this old stuff from the workstations? Ive been reading on tattooing and ADMs and this is kinda a new problem.

This problem has stemed from the users home directories not syncing correctly. In fact only one user can sync their home directory when they log off.

Any ideas?

Thanks

[petroid]

As far as I remember, new policies will overwrite old ones only if they are configured. Any individual settings set to "not configured" will not be defaulted, so if they were set previously they will remain. You can delete the user profile on the local machines so that new user policies will be downloaded on next login. Workstation policies are a bit different, you may have to manually go through the policies and change "not configured" ones to the setting that is applicable to what you're trying to do.

Of course, I am pretty tired right now, so that information could be a red herring :p

[sc302 Veteran]

that is true if you have not made a change to the new policy that will over write the old, the old will stay. dc policy is above local policy, so anything that the dc pushes out will over write anything in the local policy.

[Prophecy]

Well my DC policy is kinda loose at this point where as the local is pretty strict. I plan on locking it down more tight. Im wondering if its set to "NON CONFIGURED" on the DC and its set to configured on the local will it revert to the DC policy"

Thanks

[sc302 Veteran]

technically no, if it is not configured on the dc the local policy will take over. but I would configure it on the dc using groups so that you can have different pc's/users using different policies if that is what you need.

it is really sloppy the way you are doing it. one pc may have a policy that the other doesn't, you don't have a way to tell what policy is on what pc easily, you have no way of undoing the policy based on logon, etc.

when doing gpos on a domain try to have one policy do one thing. for instance one policy to lock the taskbar and another to set classic start menu. doing it granular like this allows you to know easily what each policy is doing at a glance and to be able to add the groups that need to have this policy applied.

Edited July 1, 2009 by sc302

[Aldur82]

The DC policy will only overwrite a local policy if it has a setting other than 'Not Configured', otherwise there would be no point in having anything but a DC policy without worrying about the application sequence regarding policies.

What you might want to do is check the Resultant Set of Policy.

I also did a quick search online and found someone suggesting the following steps on techrepublic

Create a test gpo and link it to an existing OU for testing purposes(idealy affecting the problem workstation(s)). Put the changes you want in this test gpo. Now enable, enforce, link the gpo and check off block inheritance.

Next go to users and computers (on the server) and make a user(with the problem WS) in the above test OU a member of Administrators.

Run gpudate /force on server.

Go to the users' workstation(as above) and run gpupdate /force or reboot.

Vuala, you should see the changes.

Let us know how it worked out.

P.S. Once the gpo issue is resolved, remove the user from being member of Admin grp

[Prophecy]

technically no, if it is not configured on the dc the local policy will take over. but I would configure it on the dc using groups so that you can have different pc's/users using different policies if that is what you need.

it is really sloppy the way you are doing it. one pc may have a policy that the other doesn't, you don't have a way to tell what policy is on what pc easily, you have no way of undoing the policy based on logon, etc.

when doing gpos on a domain try to have one policy do one thing. for instance one policy to lock the taskbar and another to set classic start menu. doing it granular like this allows you to know easily what each policy is doing at a glance and to be able to add the groups that need to have this policy applied.

I have numerous polcies, I dont ever stick with just one policy. Ive written numerous policies for numerous tasks. The policies I am writting work on a Computer configuration rather than a user configuration. I will work on enforcing the new policies I have in place to re-write the old. It could be the previous policies were written on a user logon level rather that a computer level and we may have some issues there. I just need to look at it. Unfortunetly there is no way to see the old GPO written by the previous staff as the OLD DC has been removed.

I appreciate that help.

Thanks

[sc302 Veteran]

Some policies are user only, some are computer only. I have been using groups to assign policies to computers or users, depending on what is needed, you can put computers in global and/or security groups as well as users. you can assign groups to group policies to help make life a little easier. you can't have folder redirection applied to computers, it is not a computer policy it is a user policy; you can't have windows update as a user policy as it is a computer policy. Everything in the User section gets applied to users, everything in the computer section gets applied to computers. I hope that makes sense. Quite possibly why your policies aren't getting assigned properly.

[sc302 Veteran]

a couple of good books regarding group policy

http://www.amazon.com/Profiles-IntelliMirr...y/dp/0782142982

http://www.amazon.com/Microsoft-Windows-Gr...cp_ob_b_title_2

[Prophecy]

a couple of good books regarding group policy

http://www.amazon.com/Profiles-IntelliMirr...y/dp/0782142982

http://www.amazon.com/Microsoft-Windows-Gr...cp_ob_b_title_2

I know GP and I appreciate the resources. The local workstations are not accepting the new GP's over their old. Its referred to Tattoing. So I am troubleshooting why the old group policy is still tattooing or lingering around on the machines after they have been added to the new domain and forced to do group policy updates. Usually this doesnt happen so Im wondering whats lingering. I have a check list of things to look over to see why its not propagating over the network.

Thanks

Proph

[Joel]

What's the RSOP say? Have you checked in the event viewer for any errors relating to GP?

[Prophecy]

What's the RSOP say? Have you checked in the event viewer for any errors relating to GP?

Well RSOP indicates all of my GPOS that I have written are being applied. However I am not seeing all the changes. I am still working on it. I need to to see if there is a GPO which affects Home Directory Syncing.

[Joel]

Wait, are you expecting to actually see your changes in the LOCAL gpedit.msc? I'm pretty sure that's not going to happen.

[sc302 Veteran]

the only option that I can recall that would have anything to do with any type of syncing would be offline folders. and that has nothing to do with one particular mapped drive or another. also just to note, pst files do not get synced, so if your pst file is stored on your "home drive" then it will not work.

[Joel]

Databases won't sync either.