GPOs apply on some PCs and no on others?

[cshoffie]

Hey all,
I have a client who I'm migrating over from a work group to a domain. I have the domain setup and everything. I can verify that the workstations are in fact connecting to the domain no problem.

However, I'm trying to map network drives using GPOs. I've done this MANY times. I have all of the users and I'm assigning them to their respective groups. I've created the shares and assigned permissions to them. I've created the GPO to make the drives using the "Create" function (within drive mappings). I've made sure the share locations are correct and the item-level targeting I've assigned is accurate. I've then linked the GPO to the OU which houses all of the users and groups, and also applied the GPO to specific groups (I even assigned it to the group "Domain Users" and "Authenticated Users" for testing). Then I've updated the GPOs. I log in to the user and no drives are mapped. I created a test server and client to test GPOs before applying them, and it's set up the exact same way and it works just fine. The problem persists also with a power scheme I created. It wont apply. The only GPOs that apply are things like the screen saver policies I created.

HOWEVER, I logged into the clients domain using a personal laptop, and the network drives mapped just fine and the power scheme applied. I'm not sure what's going on.

Server is Windows Server 2008 R2 and all clients are Windows XP Pro SP3. The personal laptop I signed onto their domain with (and when everything worked perfectly) is also XP Pro SP3.

I am absolutely stumped. Any help??

 

[Jmtyra]

Remove the computer in question from the domain, and delete the computer OU object from within AD. Re-add the computer to the domain, and verify it is created in the correct OU group necessary to apply the GPO. After rebooting, run a gpupdate /force on the machine and have the client log into the machine. Might require another log out/log in to be seen successfully.

Are all of these machines within the same forest?
What domain functional level are you running?

Edit:

Windows 2000 mixed (the default in Windows Server 2003)

Windows 2000 native

Windows Server 2003 interim

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2

 

[cshoffie]

Remove the computer in question from the domain, and delete the computer OU object from within AD. Re-add the computer to the domain, and verify it is created in the correct OU group necessary to apply the GPO. After rebooting, run a gpupdate /force on the machine and have the client log into the machine. Might require another log out/log in to be seen successfully.

Are all of these machines within the same forest?
What domain functional level are you running?

Edit:

Thank you, I will do that. I'm using 2008 R2 functional level - is that a problem?

 

[Jmtyra]

Cool -- looking forward to hearing the results.

No, just obtaining background information on the situation.

 

[cshoffie]

The interesting thing is that when I logged into the domain using my personal PC (using a VM w/ XP Pro SP3), I logged in with the same user as the client's workstation uses and it worked just fine...

 

[cshoffie]

When the client's computers were on the domain, their user names were staff1, staff2, etc.. Their PC names were staff1pc, staff2pc, etc. Since they used Windows Server 2008 R2 to maintain the workgroup, those user names, passwords, groups, etc all moved over to the domain automatically when I installed AD. Is this going to be an issue?

 

[cshoffie]

Remove the computer in question from the domain, and delete the computer OU object from within AD. Re-add the computer to the domain, and verify it is created in the correct OU group necessary to apply the GPO. After rebooting, run a gpupdate /force on the machine and have the client log into the machine. Might require another log out/log in to be seen successfully.

Are all of these machines within the same forest?
What domain functional level are you running?

Edit:

UPDATE: Ok, I did this. I went in and removed the USER (staff1) from Active Directory Users and Computers, re created the user and added it to it's respective groups. Logged back in using the user name and pass, and NOTHING. I even created a NEW user with full rights, and logged it in with the client's workstation and still nothing. The only policies being applied are the screen saver policies. I also logged in again using my VM, and the policies apply just fine.

 

[Adragontattoo]

UPDATE: Ok, I did this. I went in and removed the USER (staff1) from Active Directory Users and Computers, re created the user and added it to it's respective groups. Logged back in using the user name and pass, and NOTHING. I even created a NEW user with full rights, and logged it in with the client's workstation and still nothing. The only policies being applied are the screen saver policies. I also logged in again using my VM, and the policies apply just fine.

Go to ONE system that is not accepting GPO.

My computer, Properties, Computer name.

Is it showing as being on the domain

ie

Staff1

Domain OMGITSONFIRE.HELPPPPPPPP

and is it set to a static IP +DNS different from the DC?

Remove ONLY the system from the domain through AD (i.e right click and delete), log in with local admin on local system, remove any static IP/DNS, remove from domain, reboot, log in as local admin, and add to domain using acct with privleges to do so, reboot, log in with DOMAIN privilged acct and verify you can see the other systems on the domain, while on as privilged acct, start run GPUPDATE /force, reboot.

Log in as acct NOT hard set (i.e. domain\willywonka) and see if you are able to connect.

Are your Staff# accts local accts?

 

[cshoffie]

Go to ONE system that is not accepting GPO.

My computer, Properties, Computer name.

Is it showing as being on the domain

ie

Staff1

Domain OMGITSONFIRE.HELPPPPPPPP

and is it set to a static IP +DNS different from the DC?

Remove ONLY the system from the domain through AD (i.e right click and delete), log in with local admin on local system, remove any static IP/DNS, remove from domain, reboot, log in as local admin, and add to domain using acct with privleges to do so, reboot, log in with DOMAIN privilged acct and verify you can see the other systems on the domain, while on as privilged acct, start run GPUPDATE /force, reboot.

Log in as acct NOT hard set (i.e. domain\willywonka) and see if you are able to connect.

Are your Staff# accts local accts?

Yes it is on the domain. PC name is Staff1PC and the local acct is named staff1. The domain acct is ALSO staff1.

DNS/IP settings: IP is set to auto, primary DNS is pointing to the DC with the gateway as secondary. I couldn't get the PCs to join the domain without pointing it to the DNS hosted by the DC.

Now when you say remove ONLY the system from the domain, you mean the user name right?

I've done a gpupdate /force on the client as well as the server. Like I said, SOME policies are being applied (such as screen saver) but drive mappings and power schemes are not.

 

[Adragontattoo]

NO not the user name

SYSTEM

Admin tools, Domain users and computers.
Right click on the domain and select find users and computers.
Drop down from Users to Computers and look for system 1.
right click system1 and select delete.


why are you using a local acct for domain users?

Force them to only use DOMAIN accts. As is, you are defeating security if you are setting up a local account on the system. They can drop down from domain to local system and log in without GPO.

As a suggestion, change the machine name to something OTHER than the same as an account name.

Staff1 (user)
System1 (computer)

Staff2 (user)
System2 (computer)

etc...

I prefer the policy that I have seen at quite a few companies I have worked for.

System name= serial

Username =First letter +last name

It makes it much easier to track something down if I know that wwonka was the last one logged in to 1234567 and it was responsible for blasting out spam to the domain afterwards.

 

[cshoffie]

NO not the user name

SYSTEM

Admin tools, Domain users and computers.
Right click on the domain and select find users and computers.
Drop down from Users to Computers and look for system 1.
right click system1 and select delete.


why are you using a local acct for domain users?

Force them to only use DOMAIN accts. As is, you are defeating security if you are setting up a local account on the system. They can drop down from domain to local system and log in without GPO.

As a suggestion, change the machine name to something OTHER than the same as an account name.

Staff1 (user)
System1 (computer)

Staff2 (user)
System2 (computer)

etc...

I prefer the policy that I have seen at quite a few companies I have worked for.

System name= serial

Username =First letter +last name

It makes it much easier to track something down if I know that wwonka was the last one logged in to 1234567 and it was responsible for blasting out spam to the domain afterwards.

Thank you for the suggestion. I did what you suggested above. I went into AD Users and Computers and deleted the SYSTEM. I logged into the client as a local admin, removed myself from the domain, rebooted. Signed back in using local admin again, verified IP is set to auto and DNS is pointing to DC. Rejoined domain, restarted, logged back into client PC using domain credentials, applied gpupdate /force, rebooted and re logged into domain, and still nothing.

Like I said connection to the domain wasn't an issue. I still had policies being applied (such as screensaver preferences) but drive mapping and power schemes will not apply on client's workstation. Like I said also, if I log in to the domain using the SAME CREDENTIALS that I tried logging the client's workstation in with, the drive mappings and power policies are all applied just fine. Its just something is wrong with these client workstations that are somehow preventing drive maps and power schemes (but allowing other policies) from being applied! I can map the drives manually just fine, but that's not the point.

To answer your other question:

The clients workstations used to be on a work group some had personal login accts (using heir name) other's didn't. The primary source of login for the workstations have been a local user named staff# with the PC's being names staff#PC. When we turned on AD, all those users/groups were applied to the domain. So now, once we turn on the domain for EVERYONE, they will be logging in as staff#@domain.com with the same password and everything they're used to. We are trying to SLOWLY merge everyone from the workgroup to the domain because we want to make sure their programs they use every day still function. Once we can get the kinks out of the domain (such as these issues) everyone will be converted to the domain and the local accts will be deleted, thus using GPOs to cinch down the security.

 

[Adragontattoo]

Thank you for the suggestion. I did what you suggested above. I went into AD Users and Computers and deleted the SYSTEM. I logged into the client as a local admin, removed myself from the domain, rebooted. Signed back in using local admin again, verified IP is set to auto and DNS is pointing to DC. Rejoined domain, restarted, logged back into client PC using domain credentials, applied gpupdate /force, rebooted and re logged into domain, and still nothing.

Like I said connection to the domain wasn't an issue. I still had policies being applied (such as screensaver preferences) but drive mapping and power schemes will not apply on client's workstation. Like I said also, if I log in to the domain using the SAME CREDENTIALS that I tried logging the client's workstation in with, the drive mappings and power policies are all applied just fine. Its just something is wrong with these client workstations that are somehow preventing drive maps and power schemes (but allowing other policies) from being applied! I can map the drives manually just fine, but that's not the point.

To answer your other question:

The clients workstations used to be on a work group some had personal login accts (using heir name) other's didn't. The primary source of login for the workstations have been a local user named staff# with the PC's being names staff#PC. When we turned on AD, all those users/groups were applied to the domain. So now, once we turn on the domain for EVERYONE, they will be logging in as staff#@domain.com with the same password and everything they're used to. We are trying to SLOWLY merge everyone from the workgroup to the domain because we want to make sure their programs they use every day still function. Once we can get the kinks out of the domain (such as these issues) everyone will be converted to the domain and the local accts will be deleted, thus using GPOs to cinch down the security.

The reason it is working with the same acct elsewhere is due to the local acct.

Hence the log in with a DIFFERENT acct.

 

[cshoffie]

The reason it is working with the same acct elsewhere is due to the local acct.

Hence the log in with a DIFFERENT acct.

Ok, I also created a brand new user (using my name). And logged into the domain using those credentials from the client's workstation, and still the same issues.

 

[Jmtyra]

Just got back online -- leaving this to Adragontattoo for the time being, and will check back in later this evening.

Good luck cshoffie

 

[cshoffie]

Well, I'm all out of ideas here.. Short of bringing in another box, joining the domain, and seeing if the policies can be applied to it, not much else I know how to do.

My suspicion is that it will work just fine if I did that, because I already did that test with a VM.

My gut feeling is that there is something wrong with these workstations... some kind of configuration that is preventing these policies from being applied for some reason.

 

[TempliNocturnus]

Have you generated an RSoP to see whether the GPO's are even being processed?

 

[G33K454URU5 R3X]

I'd bet my monies that there is a local GPO being applied to the units which is taking precedence over domain policy. Start->Run-> type 'MMC' and hit Ok -> File -> Add/Remove Snap-ins ->Click 'Add' -> Select Group Policy from the list and hit Ok. Running an RSoP will also help you to narrow things down.

 

[Adragontattoo]

I'd bet my monies that there is a local GPO being applied to the units which is taking precedence over domain policy. Start->Run-> type 'MMC' and hit Ok -> File -> Add/Remove Snap-ins ->Click 'Add' -> Select Group Policy from the list and hit Ok. Running an RSoP will also help you to narrow things down.

Either a local policy or similar is preventing GPO from being applied.

What happens if you back up the necessary data and then reimage the system? Does it still not accept GPO?

 

[terran2k]

local security policy does not over ride domain GPOs. Have you looked at the event viewer?

 

[G33K454URU5 R3X]

comment removed