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.

Migration de la définition des shares Windows

C'est ballot, mais Robocopy est incapable de faire une copie d'un répertoire en conservant son statut de répertoire partagé et les détails associés. Lorsqu'on migre un serveur de fichiers avec par exemple des homedirs, il faut donc transférer les dossiers vers le nouveau avec Robocopy, puis ensuite, appliquer les partages. Plutôt contraignant si il y a des centaines de répertoires à refaire.

Heureusement, si le serveur d'origine et de destination ont exactement la même configuration disque et les mêmes chemins, il est possible d'extraire la définition des shares et donc de l'importer sur le nouveau serveur pour que les répertoires soient de nouveau partagés.

La clef HKLM\System\CurrentControlSet\Services\LanmanServer\Shares contient ces définitions :

Ces clés contiennent le nom du partage, ainsi que d'autres informations (chemin, description)... Il est donc important que les chemins concordent ; en effet, ouvrir le fichier .reg contenant la clef et ses valeurs avec un éditeur de texte ne permettra pas une modification directe.

Un redémarrage est nécessaire après l'import de la clef sur le nouveau serveur afin que les partages soient visibles dans la console Computer Management.

Impossibilité de se connecter à Veeam après un changement de nom de machine

J'ai récemment été confronté à la situation où après un remplacement de serveur de sauvegarde fonctionnant sous Veeam Backup & Replication entraînant un changement de nom, je ne pouvais plus me connecter même en local.

La console ne peut pas se connecter car le service Veeam Backup Service n'est pas démarré. Il accepte de se lancer, mais se coupe aussitôt.

La solution se trouve dans le registre, où Veeam stocke en dur le nom de la machine lors de l'installation. Fatalement, lorsqu'il change par la suite, les deux valeurs ne concordent plus, et le service ne peut s'exécuter.

Il faut aller chercher dans HKLM\SOFTWARE\Veeam, les clefs Veeam Backup and Replication et Veeam Backup Catalog. Ces deux clefs contiennent une entrée chacune avec l'ancien hostname.

La valeur de SqlServerName doit être votre nom de serveur, p. ex. "srv-veeambkp"
Ici, le hostname fait partie d'un chemin. Par exemple, la valeur sera "\\srv-veeambkp\VBRCatalog".

L'information est disponible sur ce fil de discussion sur les forums Veeam, merci au contributeur d'avoir exposé la solution.

Powershell : modification du registre pour contourner CredSSP

Au mois de mars, des correctifs Microsoft ont corrigé certaines failles par rapport à CredSSP qui est notamment utilisé pour sécuriser des connexions RDP (voir ce lien). Un message d'erreur peut survenir si un client patché tente de se connecter à un serveur non patché ou vice-versa. Pour faire simple, il est nécessaire que client comme serveur soient patchés pour qu'ils puissent communiquer.

J'ai réalisé un script Powershell permettant de contourner la sécurité via le registre afin que le système ne tienne pas compte du delta de version entre le CredSSP client et serveur. Dans un monde parfait, cela ne devrait pas exister car postes de travail et serveurs devraient être patchés en temps et en heure, mais la réalité est bien évidemment tout autre pour tout un tas de raisons. 👍

#Requires -RunAsAdministrator
$CredSspPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$ParametersPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP"
$AllowEncryptionOraclePath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters"
New-Item -Path $CredSspPath -Name "CredSSP" -Force
New-Item -Path $ParametersPath -Name "Parameters" -Force
New-ItemProperty -Path $AllowEncryptionOraclePath -Name "AllowEncryptionOracle" -PropertyType DWORD -Value "2" -Force
Write-Host "If everything went fine, please reboot the system for the changes to take effect."
Sleep 5

Le script doit être lancé en administrateur ; une fois les clefs déployées, il est nécessaire de redémarrer la station qui devrait pouvoir se connecter sans le message d'erreur plus haut, ce qui ne dispense évidemment pas d'une campagne de patch ! 😉

Vous pouvez trouver une version commentée du script sur le serveur de fichiers en cliquant sur ce lien. 💾