Just putting these here as bookmarks to myself.<\/p>\n
One of our DCs at work had the following DFSR warnings in the DFS Replication logs:<\/p>\n
\nThe DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication. <\/p>\n
Additional Information:
\n Volume: C:
\n GUID: 56234A2C-C156-11E2-93E8-806E6F6E6111 <\/p>\nRecovery Steps
\n 1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
\n 2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:
\n wmic \/namespace:\\\\root\\microsoftdfs path dfsrVolumeConfig where volumeGuid=”56234A2C-C156-11E2-93E8-806E6F6E6111″ call ResumeReplication <\/p>\nFor more information, see http:\/\/support.microsoft.com\/kb\/2663685.<\/p>\n<\/blockquote>\n
Sounded like an easy fix, so I went ahead and tried resuming replication as directed. That didn’t work though. Got the following:<\/p>\n
\nThe DFS Replication service stopped replication on the folder with the following local path: D:\\SYSVOL_DFSR\\domain. This server has been disconnected from other partners for 154 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. <\/p>\n
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. <\/p>\n
Additional Information:
\n Error: 9061 (The replicated folder has been offline for too long.)
\n Replicated Folder Name: SYSVOL Share
\n Replicated Folder ID: xxxxx
\n Replication Group Name: Domain System Volume
\n Replication Group ID: xxxxxx
\n Member ID: xxxxx<\/p>\n<\/blockquote>\nYeah, bummer!<\/p>\n
Check out this Microsoft blog post<\/a> for content freshness and the
MaxOfflineTimeInDays<\/code> parameter. You can’t simple remove SYSVOL from DFSR replication groups via the GUI as it is a special folder, so you have to work around. I found some forum posts<\/a> and blog posts<\/a> that suggested simply raising this parameter for the broken server to a number larger than the number of days its currently been offline (154 in the above case) and then resuming replication. I wasn’t too comfortable with that. What if any older changes from this server now replicate to the other servers? That could cause more damage than it’s worth. I don’t think this will happen, but why take a risk. What I really want is to force a replication onto this server<\/em> from some other server. Do a non-authoritative replication basically. So I followed the steps in this article<\/a> and that worked.<\/p>\nA non-authoritative sync is like a regular sync, just that it is rigged to let the source win. :p So all the existing files on the destination server are preserved. The event log gets filled with entries like these:<\/p>\n
\nThe DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder. <\/p>\n
Additional Information:
\n Original File Path: D:\\SYSVOL_DFSR\\domain\\Policies\\{F4A04331-3C62-474A-A1CE-517F17914111}\\GPT.INI
\n New Name in Conflict Folder: GPT-{4B7F4510-3C34-4A8A-A397-BC736AE5D9B6}-v55459.INI
\n Replicated Folder Root: D:\\SYSVOL_DFSR\\domain
\n File ID: {8189DA2F-DCBE-4755-A042-72154B648111}-v949
\n Replicated Folder Name: SYSVOL Share
\n Replicated Folder ID: 05ECDBE0-A0E6-4A9A-B5BE-7C404E323600
\n Replication Group Name: Domain System Volume
\n Replication Group ID: 46C8DB83-463F-459F-8785-DCB19231C52B
\n Member ID: 7A0E2DA6-4841-40A1-B02D-F5F341345B98
\n Partner Member ID: 7851F335-6824-4B0D-9978-5A5520ECD547<\/p>\n<\/blockquote>\nIf you want to see where these files are now moved to check out this blog post<\/a>. That post has a lot more useful info.<\/p>\n","protected":false},"excerpt":{"rendered":"
Just putting these here as bookmarks to myself. One of our DCs at work had the following DFSR warnings in the DFS Replication logs: The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back … Continue reading [Aside] DFRS links<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[258,85],"tags":[355,249],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/3646"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=3646"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/3646\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=3646"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=3646"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=3646"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}