1

I have a domain with a mix of physical and virtual servers. Some time ago another admin may have performed some manual scripted updates at the client level that are now preventing changes in the Security settings from reaching the clients. Changes made elsewhere in the group policy update fine.

Single Domain Controller - this is driven by contract policy, but I put that out there as I can't see how replication could be an issue but I'm open to any thoughts.

The old sysadmin was using the 'default domain policy' instead of a custom named policy for the site. I copied the old policy to a new name and unlinked the default policy. When I run gpupdate /force on the client it gives no errors and none appear in the logs. When I run the rsop I still see default domain policy as the winning policy for the Security settings but everywhere else it's the newly named policy. Where it gets very interesting for me is that when I right-click the properties for the RSOP I only see it drawing the new policy name and the default domain policy is nowhere to be found. RSOP throws no errors either.

Here's what I have done so far without success: 1. Backed up and deleted HKCU\Software\Policies 2. Backed up and deleted HKLM\Software\Policies 3. Backed up and deleted HKCU\Software\Microsoft\Windows\Current Version\Group Policy 4. Backed up and deleted HKLM\Software\Microsoft\Windows\Current Version\Group Policy 5. Deleted the c:\Windows\System32\Group Policy folder 6. Did a non-authoritative rollback on the DC

All bits and pieces of suggestions I've found during my searches. I'm a little baffled by what might be causing this. All other behaviors of the machines is consistent with good DNS settings. I can take them on and off the domain just fine - and it makes no difference.

Ted M
  • 11
  • 1
  • To add to this - I also did a registry check for the original 'default domain policy' SID on the client machine. Found several instances and cleared all of those as well. Did a GPupdate /Force and requeried the RSOP. Still getting that for the policy in the Security template – Ted M Feb 04 '16 at 20:01
  • One more interesting note. When I run gpresult I get the same data, sort of. I get the SID for the non-existent 'default domain policy' as the winning GPO in the security section of the html output. But I get the NAME of the winning GPO for the current domain policy GPO everywhere else. A recheck of the registry indicates that the old SID no longer exists anywhere so that tells me it's in the filesystem someplace. – Ted M Feb 04 '16 at 20:05

1 Answers1

1

I copied the old policy to a new name and unlinked the default policy.

You link disabled the Default Domain Policy?
Not a best practice, not recommended, probably not even supported. Would explain why it is missing from RSOP and your erratic results.

You may want to use the DCGPOFix tool to repair the DDP. https://technet.microsoft.com/en-us/library/hh875588.aspx Notice what is says should and should not be included in DDP:

As a best practice, you should configure the Default Domain Policy GPO only to manage the default Account Policies settings, Password Policy, Account Lockout Policy, and Kerberos Policy.

  1. Back up both GPO's - ideally you already did this before your first attempt to fix.
  2. Remove settings in those areas from your "New" GPO. You do not want to apply those settings defined in multiple GPO's.
  3. Either use DCGPOFix tool, or manually remove all settings from other areas from the DDP GPO.
  4. Re-enable the link for DDP GPO.
  5. Cross your fingers
Clayton
  • 4,523
  • 17
  • 24
  • Maybe I wasn't clear on part of this. I copied the 'Default Domain Policy' to a new policy with a different name and linked that newly named policy to the top of the domain. The name of the policy should not make a difference. It's the settings in the policy that are needed. However, just to satisfy my curiosity I'll link back in the restored Default Domain Policy following the DCGPOFix run and see if anything changes. This isn't my first rodeo with Active Directory or security settings. I'm here because I'm stumped, not inexperienced. – Ted M Feb 05 '16 at 15:12