Déploie DFS et vérifie l'accès malgré la perte d'un serveur de fichiers

L’idée reçue

« DFS est seulement un autre nom pour un partage SMB. »

Le namespace fournit un chemin logique indépendant de l’emplacement physique. La réplication, elle, maintient des copies de données entre membres. Les deux rôles répondent à des problèmes différents.

Topologie du TP

Deux serveurs de fichiers, SRV-FS01 et SRV-FS02, sont joints à corp.soria.test. Le client utilise le chemin logique \corp.soria.test\Donnees\Operations au lieu d’un nom de serveur physique.

01Établis les dépendances avant DFS

Sur les deux serveurs :

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name, Domain, PartOfDomain
Get-NetIPConfiguration
Resolve-DnsName corp.soria.test
Test-ComputerSecureChannel -Verbose

Depuis chaque serveur, vérifie l’autre :

Test-NetConnection SRV-FS01 -Port 445
Test-NetConnection SRV-FS02 -Port 445

Si DNS, le domaine ou SMB ne sont pas sains, DFS ne doit pas masquer le problème. Corrige d’abord la dépendance.

02Installe les rôles nécessaires

Sur SRV-FS01 et SRV-FS02 :

Install-WindowsFeature FS-DFS-Namespace,FS-DFS-Replication \
  -IncludeManagementTools -WhatIf

Après validation du laboratoire :

Install-WindowsFeature FS-DFS-Namespace,FS-DFS-Replication \
  -IncludeManagementTools

Get-WindowsFeature FS-DFS-Namespace,FS-DFS-Replication

03Prépare les dossiers et les droits

Sur chaque serveur, utilise un volume de données dédié si disponible :

New-Item -ItemType Directory -Path 'D:\DFSRoots\Donnees' -Force
New-Item -ItemType Directory -Path 'D:\SORIA\Operations' -Force

Crée les partages nécessaires :

New-SmbShare \
  -Name 'Donnees' \
  -Path 'D:\DFSRoots\Donnees' \
  -ReadAccess 'CORP\Utilisateurs du domaine'

New-SmbShare \
  -Name 'Operations$' \
  -Path 'D:\SORIA\Operations' \
  -ChangeAccess 'CORP\GG-Operations-RW'

Adapte les groupes au modèle d’habilitation réellement construit dans le fil rouge. DFS ne remplace ni ACL NTFS ni permissions de partage.

Vérifie :

Get-SmbShare -Name 'Donnees','Operations$'
Get-Acl 'D:\SORIA\Operations' | Format-List

04Crée un namespace de domaine

Depuis un poste d’administration ou SRV-FS01 :

New-DfsnRoot \
  -Path '\\corp.soria.test\Donnees' \
  -TargetPath '\\SRV-FS01\Donnees' \
  -Type DomainV2

Ajoute le deuxième root target :

New-DfsnRootTarget \
  -Path '\\corp.soria.test\Donnees' \
  -TargetPath '\\SRV-FS02\Donnees'

Vérifie :

Get-DfsnRoot -Path '\\corp.soria.test\Donnees'
Get-DfsnRootTarget -Path '\\corp.soria.test\Donnees'

Le namespace permet au client d’utiliser un chemin stable. Il ne copie encore aucune donnée entre Operations$ sur FS01 et FS02.

05Publie le dossier Operations avec deux cibles

Ajoute d’abord la première cible :

New-DfsnFolder \
  -Path '\\corp.soria.test\Donnees\Operations' \
  -TargetPath '\\SRV-FS01\Operations$'

Puis la deuxième :

New-DfsnFolderTarget \
  -Path '\\corp.soria.test\Donnees\Operations' \
  -TargetPath '\\SRV-FS02\Operations$'

Vérifie :

Get-DfsnFolder -Path '\\corp.soria.test\Donnees\Operations'
Get-DfsnFolderTarget -Path '\\corp.soria.test\Donnees\Operations'

À ce stade, les deux cibles existent mais leurs contenus peuvent diverger. La disponibilité d’un chemin sans cohérence des données serait une preuve incomplète.

06Crée le groupe de réplication

Crée un groupe dédié :

New-DfsReplicationGroup -GroupName 'SORIA-Operations-RG'

Add-DfsrMember \
  -GroupName 'SORIA-Operations-RG' \
  -ComputerName 'SRV-FS01','SRV-FS02'

New-DfsReplicatedFolder \
  -GroupName 'SORIA-Operations-RG' \
  -FolderName 'Operations' \
  -DfsnPath '\\corp.soria.test\Donnees\Operations'

Crée la connexion bidirectionnelle :

Add-DfsrConnection \
  -GroupName 'SORIA-Operations-RG' \
  -SourceComputerName 'SRV-FS01' \
  -DestinationComputerName 'SRV-FS02'

Configure le membre source initial :

Set-DfsrMembership \
  -GroupName 'SORIA-Operations-RG' \
  -FolderName 'Operations' \
  -ContentPath 'D:\SORIA\Operations' \
  -ComputerName 'SRV-FS01' \
  -PrimaryMember $true \
  -Force

Puis le second membre :

Set-DfsrMembership \
  -GroupName 'SORIA-Operations-RG' \
  -FolderName 'Operations' \
  -ContentPath 'D:\SORIA\Operations' \
  -ComputerName 'SRV-FS02' \
  -Force

07Vérifie la réplication avant toute panne

Inspecte la configuration :

Get-DfsReplicationGroup -GroupName 'SORIA-Operations-RG'
Get-DfsrMember -GroupName 'SORIA-Operations-RG'
Get-DfsrConnection -GroupName 'SORIA-Operations-RG'
Get-DfsReplicatedFolder -GroupName 'SORIA-Operations-RG'
Get-DfsrMembership -GroupName 'SORIA-Operations-RG'

Sur SRV-FS01, crée un fichier :

'preuve DFS ' + (Get-Date -Format o) |
  Set-Content 'D:\SORIA\Operations\preuve-dfs.txt'

Get-FileHash 'D:\SORIA\Operations\preuve-dfs.txt'

Après convergence, sur SRV-FS02 :

Get-Item 'D:\SORIA\Operations\preuve-dfs.txt'
Get-FileHash 'D:\SORIA\Operations\preuve-dfs.txt'

Les deux hashes doivent correspondre avant le scénario de disponibilité.

08Observe le chemin depuis le client

Depuis un client membre du domaine :

Get-ChildItem '\\corp.soria.test\Donnees\Operations'
Get-FileHash '\\corp.soria.test\Donnees\Operations\preuve-dfs.txt'

Tu peux examiner le cache de referrals :

dfsutil /pktinfo

Consigne la cible réellement utilisée avant la panne.

09Provoque la perte d’un serveur de fichiers

Dans un laboratoire contrôlé, arrête SRV-FS01 ou coupe son interface réseau depuis l’hyperviseur. Ne supprime pas les données.

Depuis le client :

Test-NetConnection SRV-FS01 -Port 445
Test-NetConnection SRV-FS02 -Port 445

Purge uniquement le cache DFS du client pour rendre le test lisible :

dfsutil /pktflush

Puis reteste le même chemin logique :

Get-ChildItem '\\corp.soria.test\Donnees\Operations'
Get-Content '\\corp.soria.test\Donnees\Operations\preuve-dfs.txt'
Get-FileHash '\\corp.soria.test\Donnees\Operations\preuve-dfs.txt'

La réussite est définie par le maintien du chemin logique et l’accès à une donnée cohérente. Le fait que SRV-FS01 soit inaccessible doit être prouvé séparément.

10Rétablis le nœud et contrôle la convergence

Remets SRV-FS01 en service puis vérifie :

Test-NetConnection SRV-FS01 -Port 445
Get-DfsnRootTarget -Path '\\corp.soria.test\Donnees'
Get-DfsnFolderTarget -Path '\\corp.soria.test\Donnees\Operations'
Get-DfsrConnection -GroupName 'SORIA-Operations-RG'

Crée ensuite un petit fichier depuis le chemin DFS, attends la réplication puis confirme sa présence des deux côtés.

Ne ferme pas l’incident uniquement parce que le serveur répond à nouveau. Vérifie namespace, targets, données, réplication et accès client.

11Distingue les limites de DFS

DFS apporte

DFS n’apporte pas seul

chemin logique indépendant du serveur

sauvegarde historique

plusieurs folder targets

protection contre suppression répliquée

réplication de dossiers

résolution automatique de tous les conflits métier

basculement de referral

disponibilité si domaine/DNS/réseau commun sont perdus

Une suppression ou une corruption peut être répliquée. Le scénario de résilience doit donc conserver les sauvegardes et tests de restauration déjà enseignés.

Panne BTS

Garde le même chemin après la perte d’un serveur

prouve DNS, domaine et SMB avant DFS ;
crée un namespace de domaine avec deux root targets ;
publie Operations avec deux folder targets ;
configure la réplication et prouve deux hashes identiques ;
accède au fichier depuis le chemin DFS ;
mets un serveur hors service ;
prouve que le serveur est réellement indisponible ;
réutilise le même chemin DFS depuis le client ;
remets le serveur en service et vérifie la convergence ;
documente impact, durée, dépendances et limites.

✓À retenir

DFS sépare le chemin logique de l’emplacement physique et peut associer cette publication à une réplication de dossiers. La résilience n’est démontrée qu’en vérifiant les données avant la panne, le chemin côté client pendant la panne et la convergence après retour du nœud.