Mise en place du “Content Freshness protection” dans DFS-R

Depuis Windows 2008 , DFS-R supporte un nouveau mécanisme appelé « Content Freshness ».

Cette option se rapproche de l’option Strict Replication Consistency crée pour l’AD, afin éviter de propager les lingerings objects.

Pour DFS-R, chaque élément supprimé d’un dossier répliqué est marqué en tombstone dans la base DFS-R, mais n’est pas supprimé physiquement.

C’est après une période de 60 jours que le « DFS-R garbage collection » va supprimer physiquement ces éléments.

Si un serveur n’a pas pu répliquer les données d’un dossier répliqué pendant plus de 60 jours, et que la réplication est de nouveau fonctionnelle, ses partenaires peuvent répliquer des anciennes demandes de suppressions qui sont pourtant « actives », ou répliquer des données anciennes, écrasant les plus récentes.

Pour éviter cela, l’option Content freshness se base sur un enregistrement appelé CONTENT_SET_RECORD , présent dans la base de donnée DFS-R du serveur, pour chaque dossier répliqué.

Cet enregistrement contient un timestamp appelé LastConnected.

DFS-R va mettre à jour ce timestamp pour indiquer que la réplication s’est produite.

Lors de la réplication entre membres, DFS-R compare alors l’heure de la dernière réplication et celle courante.

Si la date de la dernière est inférieure à 60 jours (MaxOfflineTimeInDays ), la réplication est autorisée.

Si elle est supérieure à 60 jours, elle est bloquée.

Cela protège l’envoi de données divergentes pour le reste des partenaires.

 

Activer l’option Content Freshness

Cette option n’est pas activée par défaut.

Elle est à activer sur chaque membre, dans le fichier DfsrMachineConfig.XML.

Il faut modifier la valeur de MaxOfflineTimeInDays via la commande suivante :

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60 

 

 

 

 

 

 

Pour visualiser la valeur :

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

La valeur recommandée est : 60.

Une fois en place, un event est retrouvé :

Log Name:      DFS Replication
Source:        DFSR
Date:          1/1/2010 3:37:14 PM
Event ID:      4012
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:     
Description:
The DFS Replication service stopped replication on the replicated folder at local path c:\xxx. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter.

Des informations sont retrouvées dans les logs DFS-R.

L’état du dossier répliqué est en erreur, définie à 5.

Pour voir l’état :

wmic.exe /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get ReplicationGroupName,ReplicatedFolderName,State

ReplicatedFolderName   ReplicationGroupName                 State
nom_dossier_répliqué    nom_du_groupe_de_réplication      5

MaxOfflineTimeInDays
Data type: uint32
Access type: Read/write
Qualifiers: MinValue(0)
The maximum number of days a replicated folder can be disconnected from other partners before it is put into an error state.
Windows Server 2003 R2:  This property is not supported until Windows Vista.
https://msdn.microsoft.com/en-us/library/bb540017(VS.85).aspx

 

Rétablir la réplication

Pour autoriser à nouveau la réplication, il est nécessaire de créer une sauvegarde de données.

Ensuite, désactiver le membre impacté via la console dfsmgmt.msc.

Attendre que la réplication AD entre DCS soit effectuée, puis sur ce membre, lancer la commande :

DFSRDIAG POLLAD

Vérifier la présence des events 4008 et 4114.

Réactiver le membre dans la console.

Il est à noter que ceci force une réplication initiale sur ce membre.

Tous les fichiers présents sur ce serveur et non présents sur le membre primaire seront déplacés dans PreExisting.

Tous les fichiers locaux perdront le conflit et seront retrouvés dans ConflictAndDeleted.

 

Joseph Besançon
Domain & Security Team