Repairing broken DFSR toplogy

[BJG]

One of our servers had a problem with SYSVOL DFSR replication, and the warning in Event Viewer said it was so out of date that the server would need to be removed from the replication group and added back in.

 

After Googling for some info on how to do this, I deleted it from the DFSR topology container via Active Directory Administrative Centre by following these instructions:

 

https://www.oreilly.com/library/view/active-directory-administration/9781789806984/2dda7ed1-ca4b-40e1-89fc-0c463ef1d443.xhtml

 

Unfortunately this seems to have been the wrong thing to do (?), and I'm now trying to figure out how to get it back.

 

One solution is apparently to demote it and promote it again, though it's the DHCP/DNS server at a remote site on a different subnet so that sounds like a major hassle.

 

The only link I've found that talks about rebuilding the toplogy without going through demotion/promotion is this one...

 

https://community.spiceworks.com/how_to/160786-how-to-re-build-sysvol-dfsr-replication-group-without-demoting-promoting-dc

 

...but not only does that also sound like a major hassle, it was written in 2019 and the first registry key it mentions doesn't exist, so it's probably for a different OS and might mess things up even more.

 

There are also various tutorials on forcing an authoritative synchronisation for DFSR SYSVOL...

 

https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

 

...but I'm not sure if this will work after vandalising the toplogy...?

 

I'd be inclined to just do away with it but I haven't managed to sell that idea to the boss yet.

Edited June 9, 2022 by BJG

[kevin_lane]

How many DCs do you have ?

 

Like when you add any domain controller it would replicate and be added DFRs topology

 

Personally I would most probably try and demote and remove the dc via normal demotion if possible shutdown and and destroy and replace it last thing you want is bad replication

 

You could try and resolve the issue but sometimes it’s better to cut your loss than try and “fix” something that potentially could lead to further issues.

Edited June 9, 2022 by kevin_lane

[HPlum78]

The issue here is if any objects have been created on the failing DC when you demote that DC those objects will also be deleted /lost or any updates that have happed on any objects on that DC would also be lost. I don't know how busy your Domain is but the scope and scale of this will depend on that... Another consideration on the same note is if your using AAD Connect and syncing your users/ groups (objects) to Azure if this is bound to the failing DC this to could have implications (even if its not this could still cause some issues mind) on the integrity of what is being synced.

 

I would need to spend more time understanding what has gone on, but those are my initial thoughts. Tread carefully here as you may introduce a whole new set of issues and I would not just go demoting and promoting DC's.

Edited June 9, 2022 by HPlum78

[kevin_lane]

The issue here is if any objects have been created on the failing DC when you demote that DC those objects will also be deleted /lost or any updates that have happed on any objects on that DC would also be lost. I don't know how busy your Domain is but the scope and scale of this will depend on that... Another consideration on the same note is if your using AAD Connect and syncing your users/ groups (objects) to Azure if this is bound to the failing DC this to could have implications (even if its not this could still cause some issues mind) on the integrity of what is being synced.

 

I would need to spend more time understanding what has gone on, but those are my initial thoughts. Tread carefully here as you may introduce a whole new set of issues and I would not just go demoting and promoting DC's.

 

I do agree with this

 

What was the last thing you did before everything went wrong?

 

Do you have any backups ?

 

Do you have any issues with logging on I.e netlogon service ?

 

Have you done a dcdiag ? If so what are the results?

 

What state is DFRs in 0-5 ?

 

Are you able to share event logs from the last 24 hours ?

 

Thanks

[BJG]

We have a couple of DCs replicating OK at the main site, and one with broken replication at a remote site. It's in a rural area and the connectivity isn't great. There's only a handful of people using it. Although it's providing DNS/DHCP, the home/group folders for those users are at the main site. This seems a bit daft to me, and I've suggested simply pointing DNS at the main site too (it's already included as an option), then demoting it and leaving it as a member server. Or preferably just ditching it and using cloud services instead.

 

Anyway...in the meantime I'm still seeing if it's possible to get it back how it was before. SYSVOL replication hasn't worked since January and no-one's even noticed. There are no IT staff at the remote site, no-one will have made any changes on that server, so it just needs an updated copy.

 

The problem started when I noticed Event 4012 in the DFSR log for the remote server.

 

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL_DFSR\domain. This server has been disconnected from other partners for 136 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected. To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

 

I initially tried following these instructions, but they don't work; it's not possible to remove servers from a SYSVOL replication group via the DFS Management console. I've since read elsewhere that you should ignore this and follow the well-documented process for an authoritative / non-authoritative sync.

 

https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

 

Unfortunately, before I discovered that, I tried removing it from the group by deleting it from the topology as described above, and now I can't sync it or add it back.

 

https://www.oreilly.com/library/view/active-directory-administration/9781789806984/2dda7ed1-ca4b-40e1-89fc-0c463ef1d443.xhtml

 

There's now a new and more vicious error in the remote DFSR Event Log preventing replication, which is 6002. As I say, I haven't come across any solution so far except demoting it. I think I might have to do that...?

 

The DFS Replication service detected invalid msDFSR-Subscriber object data while polling for configuration information.

Additional Information:

Object DN: CN=Domain System Volume, CN=DFSR-LocalSettings

Attribute Name: msDFSR-MemberReference

Edited June 10, 2022 by BJG

[kevin_lane]

We have a couple of DCs replicating OK at the main site, and one with broken replication at a remote site. It's in a rural area and the connectivity isn't great. There's only a handful of people using it. Although it's providing DNS/DHCP, the home/group folders for those users are at the main site. This seems a bit daft to me, and I've suggested simply pointing DNS at the main site too (it's already included as an option), then demoting it and leaving it as a member server. Or preferably just ditching it and using cloud services instead.

 

Anyway...in the meantime I'm still seeing if it's possible to get it back how it was before. SYSVOL replication hasn't worked since January and no-one's even noticed. There are no IT staff at the remote site, no-one will have made any changes on that server, so it just needs an updated copy.

 

The problem started when I noticed Event 4012 in the DFSR log for the remote server.

 

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL_DFSR\domain. This server has been disconnected from other partners for 136 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected. To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

 

I initially tried following these instructions, but they don't work; it's not possible to remove servers from a SYSVOL replication group via the DFS Management console. I've since read elsewhere that you should ignore this and follow the well-documented process for an authoritative / non-authoritative sync.

 

https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization

 

Unfortunately, before I discovered that, I tried removing it from the group by deleting it from the topology as described above, and now I can't sync it or add it back.

 

https://www.oreilly.com/library/view/active-directory-administration/9781789806984/2dda7ed1-ca4b-40e1-89fc-0c463ef1d443.xhtml

 

There's now a new and more vicious error in the remote DFSR Event Log preventing replication, which is 6002. As I say, I haven't come across any solution so far except demoting it. I think I might have to do that...?

 

The DFS Replication service detected invalid msDFSR-Subscriber object data while polling for configuration information.

Additional Information:

Object DN: CN=Domain System Volume, CN=DFSR-LocalSettings

Attribute Name: msDFSR-MemberReference

 

Yea that last error doesn’t sound like a good one especially from what I’ve read

 

Have you ran a health report from the DFS application?

[kevin_lane]

Also had anything been renamed?

[BJG]

...thanks for looking at it; planning to demote it.

[mowgli82]

In the past I've had success with this command

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=enternumberofdaysgreaterthanerror then reboot the server.

 

Might be worth a try