Well, it looks like the answer to my problems was found here: http://support.microsoft.com/kb/840674
I had one DC that was a replication partner to all other DCs. It passed every replication diagnostic test I could throw at it except one: nothing would actually replicate... I did a non-authoritative restore of the data in the sysvol folder as described in http://support.microsoft.com/kb/840674 and all seems to be replicating. -Bill On Tue, Apr 2, 2013 at 1:30 PM, Bill Songstad <[email protected]> wrote: > Thanks for your response Damien. I definitely had some replication > issues when I discovered this issue. But I fixed that a couple of > weeks ago and replication seems to be occurring properly now. NTFRS > isn't flopping any errors at this time and dcdiag is whining about > account mapping (related to a user account in my phantom DDC policy) > but no other problems. Next stop is combing through the replication > in sites and services on each machine to see if I can spot anything. > > Just for giggles, I think I will make a change to the real DDC policy > and see if it gets replicated. > > -Bill > > On Tue, Apr 2, 2013 at 10:36 AM, Damien Solodow > <[email protected]> wrote: >> Sounds like you have some sysvol replication issues. DCDiag should be your >> friend here. >> In general, those ntfrs_xxxx folders are from replication conflicts so you >> can usually delete them safely. >> >> I'd check your replication topology for sysvol (maybe dead links or an old >> DC still in there) as well as your File Replication Service event logs on >> the domain controllers to see what replication errors are being thrown. >> >> >> DAMIEN SOLODOW >> Systems Engineer >> 317.447.6033 (office) >> 317.447.6014 (fax) >> HARRISON COLLEGE >> >> -----Original Message----- >> From: Bill Songstad [mailto:[email protected]] >> Sent: Tuesday, April 02, 2013 1:23 PM >> To: NT System Admin Issues >> Subject: GPOs back from the dead >> >> Hi folks. I have an issue that I can't seem to pin down and am hoping >> someone here can help out. I recently inherited a W2K3 domain with about 20 >> DCs - some W2K3 some W2K8R2. The Default Domain Controller's policy is >> largely empty. However, at some point in the past, the Default Domain >> Controller's policy had dozens of settings. I recently moved a number of >> DCs into another container where the Default Domain Controllers policy was >> applied and enforced above a policy to temporarily change some WSUS >> settings. However, some of the DCs started applying the old (years old...) >> Default Domain Controllers policy. RSOP.msc revealed the dozens of policies >> from the old Default Domain Controllers policy being applied. Then when I >> moved the DC back to its original container and ran gpupdate >> /target:computer /force, the policy was updated to the current policy and >> related problems went away. >> >> Checking the sysvol folder on all of the DCs for policies referencing the >> old settings I discovered that 17 of 20 DCs have a secedit folder in sysvol >> \Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\MACHINE\Microsoft\Windows >> NT with the old policies configured. There are also 3 to 5 folders named >> secedit_ntfrs_xxxxxxxx that do not have the settings or any settings for >> that matter. The other 3 DCs do not have the secedit folder at all, but >> they do have the secedit_ntfrs_xxxxxxxx folders. >> >> So, I have two questions. 1) Why did these settings suddenly get applied? >> I mean the same Default Domain Controllers Policy was linked and enforced in >> both containers. >> >> and >> >> 2) How do I exorcise these old settings? Just delete the Secedit folders >> with the old data? Delete the gptTmpl.inf files with the old data? >> Something else? I'm a little fearful of blowing things out of the sysvol >> folder even if they are wrong. I guess I'm a little fuzzy on the >> replication process. >> >> Thanks for any insight, >> >> Bill >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ >> <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> >> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >> ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ >> >> --- >> To manage subscriptions click here: >> http://lyris.sunbelt-software.com/read/my_forums/ >> or send an email to [email protected] >> with the body: unsubscribe ntsysadmin >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
