GPO Corrupt...?

Hello Experts!

I've been working on this issue for quite some time now, and I have really just ran out of things to try for this issue.
This all started several months back when I started looking into AD replication. I found AD had not replicated across sites so I dove into that issue. I tried a couple of things before getting BurFlags to work - recreating the policies on all of the domain controllers besides the PDC. This started replication to working again, but I've had various issues (such as the one I have right now) along the way and I really don't know what is causing this or how to fix it without recreating the entire domain.

It seems that every time I go to edit a group policy, the one I need to edit is inaccessible. This times it's my Windows 7 policy that I need to edit, and I'd rather not have to recreate the entire thing again...

So here's a little info about our setup:
2 sites - Site (A) has 4 domain controllers, Site (B) has 2 domain controllers
2003 Functional Level, but have 2003, 2003 R2, 2008, and 2008 R2 Domain Controllers
It looks like replication has been modified from the default replication schedule, but this was not done by me - it was done by the previous IT guy. I don't think I would ever modify the replication schedule, but for some reason, he did. I don't want to modify it back because I don't know why it was changed in the first place, though I wish it was back to normal because replicating 1 an hour is kind of annoying when we have, at minimum, 3 bonded T1 lines (so we definitely have the bandwidth)
We have about 52 policies currently setup.

The particular issue I'm having today is when I try to EDIT the Windows 7 Policy, I get a prompt "Group Policy Error. Failed to open the Group Policy Object. You may not have appropriate rights. Details: The system cannot find the path specified", then the group policy management editor comes up with red X icons in it, and nothing displaying (like the policy is corrupt or something).

On the policy's Settings tab, all my policy settings show up like it's working fine. I have even been able to export those settings to HTML so I can print them off in case I have to recreate the policy.
On the policy's Details tab, the Unique ID has been written down, and I browsed to "\\<domain-name>.com\sysvol\Policies"... The weird thing is this particular GUID is showing up twice (as two directories). The first one is the GUID, and the second one is the GUID and "_NTFRS_22ec101d" at the end.
At first glance, this sounds like a replication issue just because of the NTFRS on and the multiple policy folders, but at this point I don't know.

The "regular" policy folder has only two files:

The "Long" policy folder has what appears to be a full policy listing:
\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf
\Scripts\Startup (empty)
\Scripts\Shutdown (empty)

The file permissions look correct on the folders, subfolders, and files within. The permissions in the Group Policy Management Console appear to be correct as well (Delegation Tab):
Authenticated Users: Read (from Security Filtering)
Domain Admins: Edit settings, delete, modify security
Domain Computers: Read (from Security Filtering)
Enterprise Admins: Edit settings, delete, modify security
SYSTEM: Edit settings, delete, modify security

I've tried playing around with DCDIAG and repadmin/replmon, but haven't made any progress.

If you'd like me to give something a shot, please leave detailed instructions on what/how to run it. For example, if you want me to give you replication summary, don't just say "can you provide replication summary?". Please say "can you run 'repadmin /showrepl' and 'repadmin /replsummary' and post the results here?" - this would be greatly appreciated to ease confusion and make things as easy as possible.

Please let me know what you guys have for me!
Thank you so much!
Who is Participating?
jay_tullisAuthor Commented:
We will be upgrading to a 2008R2 functional level in the next few months, and I expect this issue to go away once we've fully switched to DFS-R and eliminated FRS from AD. I've stopped having issues with GP's, to my knowledge, and they seem to be replicating correctly now.
Dirk MareSystems Engineer (Acting IT Manager)Commented:
Why don't you just recreate the curropt policy with all the settings apply it to a test machine our user, then when it works just link the newly created policy to the domain, container, group it is supposed to be linked to..

And then just delete your old policy if you need to keep your old policy name you can rename it when you delete the old one, or just complete rename it.
jay_tullisAuthor Commented:
Recreating the policy may work for now, but that doesn't fix the problem. The issue keeps reoccurring - it may be the same policy, it may be a different policy, but ever time I go to edit a policy like this (about once every month), there's this problem.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

SandeshdubeySenior Server EngineerCommented:
I would recommend to first verify the health DC which is having correct GPO.You can run gpotool command to verify the same.If it is Win2008 server then you need to download resource kit tool for gpotool command to work.

Once healthy DC is verfied perfrom d4 on healthy DC and d2on other DCs as below.

1) Normally for an Authoritative Restore you stop at NTFRS services on all DCs.
2) Set burflags to D4 on a known good sysvol (or at this time restore sysvol data from backup then set burflags to D4) then start NTFRS on this server.  You may want to rename the old folders with .old extensions prior to restoring good data.
3) Clean up the folders on all the remaining servers (Policies, Scripts, etc) - renamed them with .old extensions.
4) Set burflags to D2 on all remaining servers and start NTFRS.
5) Wait for FRS to replicate.
6) Clean up the .old stuff if things look good.

This is probably what you need to do to get it back.  Essentially the "" article.
jay_tullisAuthor Commented:
Thanks for the help everyone!

I really think this issue has to do with some of the items the previous administrator setup, such as modifying the default replication schedule, but unfortunately I am unable to change this schedule back to the original!

That being said, I deleted and re-created the policy and it looks like it replicated through the domain successfully.

I think the only thing I can do at this point is wait to see if this happens again in a few weeks when I have to edit another policy... Unless anyone has any other ideas...?
jay_tullisAuthor Commented:
Well, today there's another replication issue.

Checked on a DFS replica server I had setup for one of our departments that requires folders to be synchronized between two geographically separated locations, and found several hundred Event ID 6402's.

This appears to be a separate conflict between DFS-R and FRS. This entire setup that I have here is definitely NOT ideal, but I'm working with what I've been given:
Our domain functional level is 2003 (not R2), so I cannot just decommission FRS completely, like I would like to do.
The DFS-R server in location A is a 2003 R2 server (also a domain controller).
The DFS-R server in location B is a 2003 R2 server.

The third replication partner (location B) in this cluster (as in a cluster I want no part of - not as distributed computing) is a 2008 R2 domain controller. I had to use a 2008 R2 server in this setup due to restrictions incurred when trying to build replication partners using 2003R2. Replication to this server is disabled and is setup as "READ ONLY" as I don't really want data replicated here. I guess you could say I'm using this server to setup the replication groups and partners through 2008 R2 DFS, while the other partners are 2003 R2.

The problem is that I can't find very reliable documentation about how to approach this particular setup, especially since 2 of my members are domain controllers. I would love to remove the NTFRS Subscriptions object in Active Directory users and computer for my non-domain controller DFS server, however I am afraid that doing so will cause problems, even though FRS is now disabled on that particular server (I stopped the service and changed it to "Disabled").

Can anyone verify if I am headed in the right direction here and if I should remove the NTFRS Subscriptions folder in ADU&C for the DFS member server that is NOT a Domain Controller?

Eventually, we will have a 2008 R2 Functional Level domain and I plan on rebuilding all of the DFS Replication when we get there, but I'm just trying to get us by until then...
jay_tullisAuthor Commented:
No solution was provided, so to close the question out, I am accepting my own last comment as the solution.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.