Computer Picking Up Old GPO from Server

Hello.  I was having problems logging into machines with any domain user account.  I needed to explicitly add a domain user to a machine before that user could log in.  

I adjusted an old Default Domain Policy so that the setting for "Allow log on locally" is for Domain Users, Domain Admins and local Admins.  (It was lacking the "Domain Users" group and I believe this is what was creating this situation)

At first, this setting seemed work and I could go to a machine and domain users could log in no problem.  Then, it seemed to be randomly, it stopped working.  When I checked the GPO on the server, the policy was still the adjusted one.  However, when logging in locally, I noticed the local security policy had reverted back to the old one and disallowed domain users to log in without being added explicitly.  

I have researched this ad nauseum and have not gotten too far with this.  I have removed and rejoined the domain, I have tried to create a new default domain policy etc... I have looked into the registry but don't understand too much about that, hoping there was a way to change a setting or find the old policy and destroy it.  

Client is Windows 7 and Server 2008 R2.  Any other ideas?
jaxjagsAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Raymond PengConnect With a Mentor Systems EngineerCommented:
Try the following

Source:

http://community.spiceworks.com/how_to/show/27566-old-gpo-still-applying

1.      
Disconnect PC from the domain
Start --> run (Windows key + r ) --> sysdm.cpl --> Change --> select 'workgroup' button and type 'workgroup' in the field below.
Click OK --> Enter domain admin credentials --> Click OK
Click 'OK' --> Click 'OK'--> Click 'Close' --> Click 'Reboot Now'

2.      
Delete C:\WINDOWS\security\Database\secedit.sdb
"Deleting this file, completley trashes the group policies on the PC and forces a brand new refresh from the domain controller" - AndrewRead

This can also be done via command line:
Delete C:\WINDOWS\security\Database\secedit.sdb

Exercise caution when operating from the command line as misspelling or changing the ordering of your command can have unintended consequences

3.      
Reboot the computer
4.      
Join the computer to the domain
Start --> run (Windows key + r ) --> sysdm.cpl --> Change --> select 'Domain' button and type the Fully Qualified Domain Name (FQDN) in the field below.
Click OK --> Enter domain admin credentials --> Click OK
Click 'OK' --> Click 'OK'--> Click 'Close' --> Click 'Reboot Now'

5.      
GPUpdate /force /boot
This need to be run from either the run box or cmd.exe
1). Start --> run (Windows key + r ) --> gpupdate /force /boot
or
2). Start --> run (Windows key + r ) --> cmd --> OK --> gpupdate /force /boot

This command will force the computer to get any GPO's, that are applicable, from the Domain Controller and will rebuild the secedit.sdb database. Your computer should also reboot if it has any GPO's that only run when the PC starts up.
0
 
Raymond PengSystems EngineerCommented:
On the client machine can you run RSOP to see what GPOs are in effect?
Please also open cmd > gpresult /h and it will output to an html file.  Check what groups / gpos the user is in and applied.

Is it only applying to this user or all users?  If it's just one, try removing them from all groups and OU for testing purposes.
0
 
jaxjagsAuthor Commented:
Thanks.  I ran the RSOP on the machine and it says it is getting the default domain policy and that html file reflects that change!  However, when I go to "local security policy" it shows the old GPO and still behaves according to that old GPO.

It happens to any user I try to log in with... any domain user is locked out, except domain admins which is on the old GPO as permitted any way.

Now I think I'm more confused!
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
Raymond PengSystems EngineerCommented:
Just to confirm - you're applying to an OU with computers?

I would try creating a test OU and have 2 test pcs in there.  Link only the policy you want to test to it. Run gpupdate / force and see what it picks up.
0
 
jaxjagsAuthor Commented:
Thanks.  Yes I am apply to OU with computers.  It is inherited via the Default Domain Policy.  I also went ahead and tried to link directly even though I shouldn't need to.  By adding the "Users" group it worked... for a few hours.  By the time I signed back in the next morning, it once again reverted back to the old domain settings and said I can't log in using this method.  When running RSOP it says it's getting settings from default domain policy but these are NOT the settings on the server.  

Is there any way to find some rogue, old copy of the default domain GPO?  

What's even more confusing, is that I am testing this on two PCs.  The one I am speaking about and another one that IS picking up the new Domain Policy and HOLDING those settings without reverting back... perhaps this is a clue?
0
 
jaxjagsAuthor Commented:
Check that last paragraph... now the same condition is happening to both machines in that OU.  Even if I move the machines to a different OU, it picks them up.
0
 
jaxjagsAuthor Commented:
Thank you for that guidance.  Unfortunately, the domain policy applies but over night it reapplies the old one again.  So stuck at the same spot.
0
 
jaxjagsAuthor Commented:
These were all great steps to take to resolve this issue.  Unfortunately, the true issue was found in the Replication Log on the domain controller.  It was stuck in an error state and was not working properly.  I had Microsoft find that and fix it for a fee.

Event ID: 13568  "JRNL_WRAP_ERROR"

http://social.technet.microsoft.com/Forums/en-US/d88385dd-ba83-43d4-8bc7-85e15aa1ae58/event-id-13568
0
All Courses

From novice to tech pro — start learning today.