Dans un annuaire Active Directory, et dans l'implémentation libre Samba, DFS permet de mettre en place des alias sur les lecteurs partagés, d'unifier derrière un même nom des partages réseau stockés sur des serveurs de fichiers différents. Exemple : smb://nas.masociete.example/compta et smb://nas.masociete.example/direction : un même nom, mais, en réalité, les données sont stockées sur deux serveurs. Encore mieux : la syntaxe smb://nas.masociete.example/<NOM_UTILISATEUR> peut envoyer deux utilisateurs différents sur deux serveurs de fichiers différents.

La table des correspondances est stockée dans la machine qui a le rôle DFS, qui n'est pas forcément le contrôleur de domaine.

La machine qui joue le rôle DFS effectue uniquement la redirection, les transferts de données ne passent pas par elle. Dit autrement : un ss sur un poste de travail montrera une connexion SMB entre cette machine et le véritable serveur de fichiers, pas entre elle et la machine DFS.

Cas d'usage ?

• Migrer plus facilement les utilisateurs lors du remplacement d'un serveur de fichiers. Sans DFS (ni alias DNS), tu dois migrer utilisateur par utilisateur ou service/équipe par service/équipe (car tous les membres d'un service montent souvent les mêmes lecteurs réseaux), en passant sur chaque poste de travail pour changer l'adresse du/des lecteurs partagés (ce qui rend impossible une migration "tout en une nuit"), ce qui est galère, surtout avec le télétaff, et ce qui nécessite une synchronisation entre l'équipe qui migre le stockage et l'équipe qui paramètre les postes de travail ;
  
  
• Masquer l'infrastructure de stockage aux utilisateurs. Sans DFS, si l'on veut les rendre autonomes pour monter leurs lecteurs réseaux, il faut leur donner le nom du serveur et le nom du partage, voir pondre un bout de site web qui leur donne ces infos. #Compliqué.

Merci Rémi de nous avoir appris et mis en place cela.