Jump to content

Domain Policies Not Replicating between DCs


ericargyle

Recommended Posts

PREFACE: I recently had to restore an image of our 2 DCs due to a DNS issue we were having. I restored from the previous night prior to the issue. The restore went cleanly. However, since then, GPOs have not replicated.

SYSVOL is replicating. Login scripts have transferred over. Policies are not.

Domain policies are not replicating from Dc1 to DC2 in my ADI domain. DNS is clean. Clients are able to log in, new clients are able to join the domain, and authenticate cleanly at each site. DNS updates dynamically for my clients. DFSR throws no errors, and communicates cleanly, even mapping drives over the WAN.

It's 2008 R2 entirely, so FSR is not running, that fix won't work in my world. I have rebooted DC2 (which is having the issues), have pushed over with sites and services, and have checked DC2 for DFSR errors.

Latest info on DC2:

The DFS Replication service successfully established an inbound connection with partner DC1 for replication group Domain System Volume.

To me, this would allow group policy objects to make the jump. No AV, no firewall running.

I'm running out of ideas. Any help appreciated.

Link to comment
Share on other sites


repadmin runs clean as well.

C:\Windows\system32>repadmin /showrepl

Repadmin: running command /showrepl against full DC localhost

East\DC1

DSA Options: IS_GC

Site Options: (none)

DSA object GUID: b90d4c8c-fde8-439f-82aa-50d5c8022040

DSA invocationID: 2dc9628e-4f4b-40da-b567-2fa6a1a9f9ce

==== INBOUND NEIGHBORS ======================================

DC=leyden,DC=local

West\DC2 via RPC

DSA object GUID: 56afd570-f325-4bf5-a05a-b7762ef5ff19

Last attempt @ 2011-06-17 10:06:11 was successful.

CN=Configuration,DC=leyden,DC=local

West\DC2 via RPC

DSA object GUID: 56afd570-f325-4bf5-a05a-b7762ef5ff19

Last attempt @ 2011-06-17 10:06:11 was successful.

CN=Schema,CN=Configuration,DC=leyden,DC=local

West\DC2 via RPC

DSA object GUID: 56afd570-f325-4bf5-a05a-b7762ef5ff19

Last attempt @ 2011-06-17 10:06:11 was successful.

DC=DomainDnsZones,DC=leyden,DC=local

West\DC2 via RPC

DSA object GUID: 56afd570-f325-4bf5-a05a-b7762ef5ff19

Last attempt @ 2011-06-17 10:06:11 was successful.

DC=ForestDnsZones,DC=leyden,DC=local

West\DC2 via RPC

DSA object GUID: 56afd570-f325-4bf5-a05a-b7762ef5ff19

Last attempt @ 2011-06-17 10:06:11 was successful.

Link to comment
Share on other sites

Thanks Allen. Unfortunately that is mainly dealing with frs. Mines 2008 functional , dfsr through and through. I think I should AdSiedit to make dc1 primary dfsr point. Then I should non authorative restore dc2 dfsr. Does that sound about right? Thanks as always Allen. Not the first time you've helped me. :)

Link to comment
Share on other sites

First, if a DC dies (assuming it wasn't the only GC in the domain), it would have been much easier for you to simply seize the FSMO roles (if necessary) to another DC that was online, clean up the old computer object and any old metadata for the failed DC in ntdsutil, reinstall Windows on and re-dcpromo AD on the failed box, and let AD replication do it's thing - that is all you would have needed to have done. The only time you really need to do a restore like that is if you lose the last GC in a domain, or if all DCs had fallen down and you were in a domain (or worse, forest) recovery scenario.

If you *really* need to do a restore of a DC due to a DR scenario, there are a few steps you must take (and you cannot really skip any). With that in mind, you should *NEVER NEVER NEVER* restore a DC from a backup image without at least doing a non-authoritative restore of the objects from that machine in DS Restore mode (unless it's the only DC, which..... shouldn't be the case anyway!), or with the AD services stopped. You really (*really*) need to do a non-auth restore on the objects on that machine once you restore a backup image, and ****then**** bring the DC back online. What you have right now are conflicting USNs in AD, most likely (this is the same sort of thing that could happen if you were to pause a VM running a DC for a day or two). The steps you must do if you restore a DC image (or at least the system state), in order:

Step 1 - restore that machine from an image

Step 2 - boot into DS Repair mode

Step 3 - do a non-auth restore of the objects you just restored

Step 4 - reboot into normal mode, and let AD fix itself

You skipped steps 2 and 3, and step 4 cannot happen right now because of it.

If you're at 2008 native (not mixed), you should be using DFS-R anyway (consider migrating using dfsrmig after you fix this), as FRS is the old way and is inefficient comparatively. Ultimately at this point, if SYSVOL and the scripts folder are synced but your policies are not, this would likely indicate that you have a problem in the system container - not a filesystem issue, but a root issue with USNs in AD for policy. You honestly would be better off making sure the GC and FSMO roles are on another DC, removing that failed DC, and then set about removing it from the domain and rebuilding it again. Once it's back up, simply dcpromo it back to a DC. AD has multimaster replication, so assuming you have more than one GC in the domain, this is the easiest (and safest) way to do DR of a failed DC anyway.

Good luck!

Link to comment
Share on other sites

Cluberti, thanks for the reply. I am using DFS-R. I did manage to fix SYSVOL replication by setting DC1 as authorative and DC2 as non-authorative, and pushing DC2 to DC1 as the parent computer.

However, DNS, which is fully ADI, seems to be replicating only from DC1 to DC2, and not vice versa. I'm wondering if you have any suggestions for that?

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...