Dysfonctionnements sur des partages DFS

Ces derniers jours, j'ai été confronté à un incident qui arrivait de manière complètement aléatoire lors de l'accès à des partages réseaux via DFS. Dans l'explorateur, un comportement erratique de celui-ci en naviguant dans les partages DFS, l'impossibilité de créer des répertoires ("une erreur réseau inattendue s'est produite"), la nécessité d'appuyer sur F5 pour voir le contenu d'un dossier ou encore l'impossibilité pour une application comme Excel d'écrire dans le chemin étaient des symptômes du dysfonctionnement.

Voici quelques caractéristiques :

  • Toutes les versions sur parc de Windows 10 sont concernées (1703, 1809, 1903)
  • De multiples serveurs de fichiers hébergeant les partages réseaux sont concernés
  • Les utilisateurs sont situés sur des emplacements géographiques différents et le dysfonctionnement est présent par connexion filaire, en WiFi ou via le VPN.

La recherche était d'autant plus compliquée pour isoler le dysfonctionnement que :

  • Aucun log n'était parlant ou utile sur les clients ou les serveurs de fichiers, pas plus que côté équipements réseau ou couche de virtualisation
  • Je n'avais aucun dysfonctionnement côté baie de stockage
  • Aucune modification n'a été faite côté infrastructure Windows / ActiveDirectory
  • Aucune campagne de patch n'a été réalisée avant l'apparition du bug.

Le travail n'a pas été facile car le problème étant complètement aléatoire et parfois résolu d'un simple F5 où d'un redémarrage, l'incident ne m'arrivait pas de suite et était généralement traité par les équipes support. Tous les serveurs étant sur le même hyperviseur, j'ai déplacé un ou deux serveurs sur un autre hôte : sans effet. Par chance, j'ai été très rapidement victime du dysfonctionnement, ce qui m'a permis de dégrossir l'incident et d'éliminer quelques pistes.

L'accès aux partages réseau DFS fonctionnait mal, que le lecteur soit monté sur un disque réseau ou un emplacement réseau ; à la main ou par GPO, aucune différence. Cependant, en accès direct en appelant le partage par le nom du serveur, aucun problème. Je n'ai rien relevé de particulier concernant la connectivité au serveur de fichiers en lui-même et les écoutes du réseau n'ont rien révélé de ce point de vue : j'étais donc quasiment certain qu'il s'agissait d'un problème au niveau de la couche DFS et non du partage de fichiers en lui-même.

J'axe donc mes recherches sur le DFS. Sur un poste qui rencontre le problème, une capture Wireshark est effectuée et je récupère les trames TCP qui vont enfin me permettre d'avancer. En effet, je vois régulièrement ces messages dans les trames TCP :

Ioctl Request FSCTL_DFS_GET_REFERRALS, File: \dundermifflin.inc\SHARES\MSCOTT
Ioctl Response, Error: STATUS_NOT_FOUND

En cherchant un peu sur le web, je suis tombé sur des cas où un référent DFS a été créé et supprimé rapidement, entraînant un souci lors de la redescente des informations sur le poste de travail. Le poste de travail tentait alors d'interroger un référent DFS qui n'existait plus. Ce n'était pas mon cas, en utilisant l'outil dfsutil comme ceci, je n'avais aucune trace du mauvais référent :

dfsutil /pktinfo

Cette commande permet de sonder les référents DFS qui répondent aux requêtes DFS soumises par les postes clients. Je n'avais aucun référent caduc ni aucun code d'erreur particulier. En continuant de creuser avec mon tractopelle, je suis tombé sur l'outil dfsdiag qui allait me mettre sur la bonne voie.

dfsdiag permet d'effectuer des tests sur le bon fonctionnement de l'infrastructure DFS. Voici l'instruction que j'ai utilisé :

dfsdiag /testdfsintegrity /DfsRoot:\\dundermifflin.inc\SHARES /Recurse

J'ai donc bien une erreur concernant ce namespace :

Je teste sur un autre namespace pour lequel je n'ai eu aucun cas de remonté et qui est porté par des serveurs différents, et je n'ai pas ce message d'erreur.

Je recherche donc sur le net à propos de cette erreur et je tombe sur ce lien salvateur. Les namespaces DFS portés par un serveur doivent être enregistrés dans le registre ; il s'agit des clefs présentes dans l'arborescence Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DFS\Roots\domainV2\. Dans le cas du serveur indiqué dans le message d'erreur, je n'ai rien, par contre sur un autre serveur du pool DFS, j'ai bien des clefs qui correspondent aux namespaces, avec pour chacune d'entre elles, deux valeurs de type REG_SZ (chaîne de caractères) LogicalShare et RootShare qui contiennent le nom du namespace en question (cachés sur la capture) :

J'ai donc procédé à la création des clefs et valeurs correspondantes sur le serveur incriminé, puis relancé le service DFS Namespace. En exécutant de nouveau dfsdiag, l'erreur a disparu et je n'ai plus eu de cas de dysfonctionnements d'accès aux partages DFS.

Introduction à Windows Server Core

Proposée déjà depuis quelques éditions, la version Core de Windows Server permet de s'affranchir de l'interface graphique habituellement livrée avec le système d'exploitation. Si certaines API graphiques sont disponibles et permettent l'exécution d'applications graphiques comme le bloc-notes, la philosophie de cette version est orientée ligne de commandes et plus précisément Powershell.

Dans ce dernier article de l'année, je vais présenter cette version de Windows en commençant par l'installation, la configuration et quelques exemples d'utilisation du système.

A noter que la version utilisée pour cet article est Windows Server 2019 ; si sur certaines versions précédentes de Windows il était possible d'installer ou désinstaller tout l'environnement graphique une fois l'OS déployé, cela n'est pas possible sur 2019. Il est donc important bien réfléchir au type d'environnement nécessaire avant de procéder à l'installation.

La phase d'installation ne présente aucune différence ; nous choisissons donc la version Windows Server 2019 et non celle avec le Desktop Experience. Une fois l'installation terminée, une fenêtre cmd s'ouvre avec un premier prompt de login.

Mot de passe configuré et utilisateur connecté, nous sommes face à un prompt cmd tout simple. Un outil permet d'effectuer toute la configuration de base du système : cet outil s'appelle sconfig et peut être appelé directement dans le prompt en tapant sconfig.

Nous allons donc renommer la machine, puis lui affecter une adresse IP ; tout ceci se fait sans la moindre ligne de commande. D'autres paramètres sont accessibles, mais je ne vais pas les aborder ici car l'outil est plutôt simple d'usage.

Le serveur a donc son nom et une adresse IP. La prochaine étape va être le déploiement des rôles ADDS et la création d'une nouvelle forêt. Dans un premier temps, il va falloir installer les rôles ADDS, puis ensuite procéder à la création de la forêt. Ceci se réalisant en Powershell, nous allons quitter sconfig pour revenir à notre prompt cmd, puis appeler le moteur Powershell en saisissant simplement powershell.

Cette instruction va installer les rôles :

Install-WindowsFeature -name AD-Domain-Services

Celle-ci va créer la forêt. Les paramètres DomainMode et ForestMode permettent de définir le niveau de fonctionnalité ; ici, WinThreshold représente le niveau maximal (2016). Pour plus d'informations concernant le commandlet Install-ADDSForest, je vous renvoie vers la documentation en ligne.

Install-ADDSForest -DomainName dundermifflin.inc -DomainMode WinThreshold -ForestMode WinThreshold -Database "C:\Windows\NTDS" -SysvolPath "C:\Windows\Sysvol" -Logpath "C:\Windows\Logs"

En validant, il ne reste plus qu'à confirmer que l'on souhaite bien procéder à la création d'une forêt avec un domaine pour que celle--ci commence, puis le serveur redémarre.

Une fois le serveur de nouveau accessible, nous allons nous connecter avec notre nouveau compte Administrator. De nouveau sous Powershell, nous allons voir les rôles et fonctionnalités installés sur le système :

Get-WindowsFeature

Le retour de la commande est vraiment bien fait car il présente hiérarchiquement les rôles et fonctionnalités comme sur la version à interface graphique. Dans le cadre de cet article, nous allons déployer le rôle DFS Namespace car nous souhaitons partager des répertoires et les présenter avec un nom de domaine plus parlant que le nom de la machine. Pour installer une nouvelle fonctionnalité, il suffit de reprendre le nom de la deuxième colonne en paramètre de la commande, comme ceci :

Install-WindowsFeature FS-DFS-Namespace

En validant par entrée, le système va déployer la fonctionnalité. Pour celle-ci, il n'y a pas besoin de redémarrer.

Procédons à la création d'un répertoire qui va être partagé pour être utilisé avec DFS. Ce répertoire nommé docs sera dans C:\dfs.

cd \
mkdir dfs
cd dfs
mkdir docs

Afin d'être déclaré en tant que répertoire DFS, ce répertoire doit être partagé au niveau serveur :

New-SmbShare -Name "docs" -Path "C:\dfs\docs" -FullAccess "DUNDERMIFFLIN\Administrator"

Une fois le répertoire partagé, il peut être ajouté en tant que racine DFS. Ici, je vais procéder à la création d'une racine DFS au niveau domaine. Pour plus d'informations, consultez la documentation en ligne du commandlet New-DfsnRoot.

New-DfsnRoot -TargetPath "\\w2019core01\docs" -Type DomainV2 -Path "\\dundermifflin.inc\docs" -EnableAccessBasedEnumeration:$true

Désormais, je peux parcourir les dossiers partagées grâce à l'URL \\dundermifflin.inc\docs. Procédons à la création d'un répertoire partagé accessible via DFS, nommé dsi.

New-DfsnFolder -Path "\\dundermifflin.inc\docs\dsi" -TargetPath "\\w2019core01\dsi"

Nous avons donc notre répertoire DFS et sa racine, mais pas d'utilisateurs ; notre AD fraîchement installé est toujours vide. Grâce aux modules ActiveDirectory pour Powershell installés, nous allons administrer notre annuaire local en Powershell également. Nous allons créer quelques OU pour ranger nos objets.

New-ADOrganizationalUnit "DUNDERMIFFLIN.INC"
New-ADOrganizationalUnit "Users" -Path "OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc"
New-ADOrganizationalUnit "Groups" -Path "OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc"

Ainsi, dans notre AD existera une OU DUNDERMIFFLIN.INC, comprenant 2 autres OU nommées Users et Groups. Procédons à la création d'un utilisateur et d'un groupe :

New-ADGroup -SamAccountName "admins" -Name "Admins" -Path "OU=Groups,OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc" -GroupScope "Domain"
New-ADUser -SamAccountName "michael.scott" -Name "Michael Scott" -Path "OU=Users,OU=DUNDERMIFFLIN.INC,DC=dundermifflin,DC=inc" -AccountPassword (ConvertTo-SecureString -AsPlainText "Password01" -Force)
Enable-ADAccount "michael.scott"

Ajoutons ce compte au groupe des admins du domaine :

Add-ADGroupMember -Identity "Domain Admins" -Members michael.scott

Puis connectons-nous avec. Tentons d'accéder au répertoire DFS créé plus haut avec le compte de Michael Scott, et nous aurons bien une erreur de droits insuffisants, car nous avons seulement autorisé Administrator à accéder à ce répertoire.

Get-ChildItem \\dundermifflin.inc\docs

Nous allons donc autoriser le compte à accéder à ce partage, mais seulement en lecture.

Grant-SmbShareAccess -Name "docs" -AccountName "michael.scott" -AccessRight Read

En validant, le retour du commandlet va afficher les droits positionnés sur le partage. Si on reexécute la commande plus haut, cela doit désormais fonctionner.

Voici qui conclut pour cette introduction à Windows Server Core. L'administration d'une telle machine n'a rien de spécialement compliqué pour peu que l'on soit habitué à travailler avec Powershell ; de plus la documentation en ligne de Microsoft est une véritable mine d'or permettant d'obtenir les syntaxes des commandlets. Plus une question d'habitude que de véritable connaissance technique, l'administration d'un serveur Core peut également se faire à distance depuis un serveur à interface graphique si ce dernier possède les RSAT (Remote Server Administration Tools) installés. En dehors de certains serveurs applicatifs qui nécessitent une interface graphique, il est tout à fait possible d'avoir une ferme de serveurs d'infrastructure sous Windows tous dépourvus d'interface graphique. Représentant un gain non négligeable de ressources, la démocratisation du mode Core dans une infrastructure pourra également pousser les équipes d'administration à scripter de plus en plus leur travail et tâches récurrentes, à centrer sur un serveur d'administration tous les outils et consoles à distance, ce qui va de pair avec une homogénéisation des processus et un travail plus efficace.

Faciliter sa migration de fileserver DFS avec Powershell

Ayant éprouvé ces scripts lors d'une migration d'un serveur de fichiers, je vais les partager dans ce billet. Le but n'est pas d'automatiser complètement la migration mais de faciliter le travail et de limiter les risques d'erreurs humaines.

A noter qu'il est important de vérifier le bon fonctionnement des scripts sur votre environnement : en effet, il est possible que les espaces dans les noms de chemin pour les scripts Robocopy puissent causer des dysfonctionnements. Il est également important que les noms de répertoires sur le serveur correspondent au nom des répertoires DFS. Il peut donc être nécessaire d'adapter le code pour qu'il fonctionne correctement.

Ce snippet appelle Robocopy pour faire le transfert des données.

$servername = "fs001.dundermifflin.inc"
cd c:\mig\robocopy
$FoldersToDo = Get-Item \\$ServerName\C$\shares\* | select name
foreach($Folder in $FoldersToDo){
    $FolderName = $Folder.Name
	start-process "robocopy.exe" -ArgumentList "/MIR /COPYALL /ZB /W:0 /R:0 /MT:16 \\$ServerName\C$\shares\$FolderName C:\shares\$FolderName /log:robocopy_$ServerName_$FolderName.log /v" -wait
}

Ce script va s'occuper de la partie DFS ; il va ajouter le nouveau serveur de fichier en tant que répertoire cible pour chaque répertoire DFS qui contient un lien vers l'ancien serveur. Ce nouveau lien sera en désactivé, ainsi la migration peut être préparée en amont.

Param([Parameter(Mandatory=$true)][string] $OldServer, [Parameter(Mandatory=$true)][string] $NewServer, [Parameter(Mandatory=$true)][string] $Namespace)
$fNameSpace = "$Namespace\*"
$folderlist = Get-DfsnFolder $fNameSpace | foreach { (Get-DfsnFolderTarget $_.Path).TargetPath } | Where-Object { $_ -like "\\$OldServer*" }
foreach($folder in $folderlist){
	$folderName = $folder.SubString($OldServer.Length+3,$folder.Length-$OldServer.Length-3)
    echo $folderName
	New-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$NewServer\$folderName" -State Offline
}

Par exemple, si l'on souhaite migrer de fs001 vers fs002 tous les liens DFS du namespace Documents, le script pourra être appelé de cette manière :

.\ImportationDFS-NewServer.ps1 -OldServer fs001 -NewServer fs002 -Namespace \\dundermifflin.inc\Documents

Ainsi, le jour de la migration, en jouant ce script on réalise la bascule vers le nouveau serveur fs002 puisque celui-ci va activer les liens DFS vers le nouveau serveur en désactivant ceux de l'ancien serveur.

Param([Parameter(Mandatory=$true)][string] $OldServer, [Parameter(Mandatory=$true)][string] $NewServer, [Parameter(Mandatory=$true)][string] $Namespace)
$fNameSpace = "$Namespace\*"
$folderlist = Get-DfsnFolder $fNameSpace | foreach { (Get-DfsnFolderTarget $_.Path).TargetPath } | Where-Object { $_ -like "\\$OldServer*" }
foreach($folder in $folderlist){
	$folderName = $folder.SubString($OldServer.Length+3,$folder.Length-$OldServer.Length-3)
    echo $folderName
	Set-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$NewServer\$folderName" -State Online
    Set-DfsnFolderTarget -Path "$Namespace\$folderName" -TargetPath "\\$OldServer\$folderName" -State Offline
}

Ce script prend les mêmes paramètres que le précédent. En fonction du type de migration effectuée, il peut-être nécessaire de jouer le script plusieurs fois : si le nouveau serveur remplace et conserve le nom de l'ancien, il y a de grandes chances qu'à un moment le nouveau serveur doive être renommé. Dans ce cas, Microsoft conseille de supprimer le répertoire de destination dans DFS avant de renommer le serveur ; cependant si un répertoire DFS n'a plus de répertoire de destination, alors ce répertoire DFS est supprimé (en conservant bien sûr, les données sur le disque du serveur en question). Il sera donc nécessaire de procéder en plusieurs étapes et en jouant le script plusieurs fois afin de toujours conserver un lien DFS, qu'il soit actif ou non.

Par exemple, si l'on considère le serveur fs001 et le serveur fs001new, en admettant que l'on renomme le serveur fs001 en fs001old une fois la migration effectuée, cela nous donne ceci :

Etape #Serveurs contenus dans les liens DFSDétails
1fs001Etat pré-migration
2fs001 : actif - fs001new : inactifAjout de fs001new
3fs001 : inactif - fs001new : actifActivation de fs001new
Désactivation de fs001
4fs001new : actifRetrait de fs001
Renommage en fs001old
5fs001new : actif - fs001old : inactifAjout de fs001old
6fs001old : inactifRetrait de fs001new
Renommage en fs001
7fs001 : actif - fs001old : inactifAjout de fs001
8fs001Etat post-migration

Il n'y a pas de dysfonctionnement grave à ne pas retirer le serveur des répertoires cibles avant qu'il soit renommé. Il faudra cependant attendre une petite trentaine de minutes que côté AD tous les liens DFS soit remis en état par le système car bien qu'il s'agisse toujours de fs001, l'objet dans l'annuaire n'est pas le même. Il ne reste ensuite plus qu'à valider le bon fonctionnement.

Répertoires DFS visibles sans autorisation d'accès

J'ai été confronté à un problème provenant de la bureautique. Des utilisateurs voyaient dans leur liste de répertoires partagés sous Windows des partages DFS auxquels ils n'avaient pas accès, en plus de leurs répertoires DFS usuels. Normalement, Windows n'affiche pas de répertoire partagé si l'utilisateur n'a pas d'accès en lecture. Par exemple, si l'on considère la racine \\dundermifflin.inc\ et 3 répertoires DFS Sales, Accounting et Boss, si l'utilisateur n'a accès qu'au dernier il ne peut pas voir les dossiers Sales et Accounting.

Or dans mon cas, ces répertoires étaient bien visibles. La cause provient de la manière dont les permissions ont été positionnées dans la console DFS. Lors de la création d'un répertoire DFS, il est possible de positionner les privilèges de deux manières : en utilisant soit les permissions NTFS, soit DFS.

En choisissant l'option Use inherited permissions from the local file system, Windows ne va pas appliquer de permissions DFS sur le répertoire. Ainsi, comme son nom l'indique, les droits seront les mêmes que ceux positionnés sur le serveur qui héberge le répertoire en question. C'est justement ce réglage qui déclenche l'affichage dans l'explorateur. N'ayant aucune permission DFS de configurée, Windows ne sait pas avant d'interroger le serveur qui porte le répertoire si l'utilisateur a le droit de se connecter au non ; le répertoire est donc affiché. Ce n'est que lorsque l'utilisateur tente d'y accéder que Windows va récupérer les ACL et empêcher l'accès. Le comportement est par ailleurs expliqué dans la fenêtre ci-dessus.

La deuxième option, Set explicit view permissions on the DFS folder, place donc des permissions DFS directement sur le lien DFS (traduction de \\FileServer03.dundermifflin.inc\Shares vers \\dundermifflin.inc\shares). Ainsi, dès l'ouverture de l'explorateur, Windows lit ces ACL et n'affiche pas le répertoire puisqu'il sait que l'utilisateur n'y a pas accès.

Ce script Powershell permet d'afficher les répertoires DFS qui sont configurés avec la première option et qui apparaissent dans l'explorateur, si jamais vous souhaitez faire une passe complète sur tous vos shares DFS afin d'adopter une configuration homogène :

Param([Parameter(Mandatory=$true)][string] $Namespace)
$fNameSpace = "$Namespace\*"
Get-DfsnFolder $fNameSpace | where-object { (Get-DfsnAccess $_.Path) -eq $null }

Il suffit de l'appeler de cette manière :

.\DFS-NoPerm.ps1 -Namespace \\dundermifflin.inc\shares