Bonjour à tous, mon nom est John Clyburn et je suis un consultant senior en MCS. J’ai récemment rencontré un problème de connexion à un partage sur un serveur Hyper-V configuré à l’aide des scripts PowerShell SDNExpress. J’ai travaillé sur le Software Defined Networking (SDNv2). J’ai principalement travaillé avec Windows Server 2019 et VMM 2019, en déployant la solution à l’aide de VMM SDN Express à partir du site GitHub. Pour en savoir plus sur cette solution, voir le lien suivant : SDNExpress.

J’aimerais partager ceci avec tout le monde en espérant que cela vous fera gagner du temps si jamais vous rencontrez ce problème lors d’un dépannage.

PROBLÈME :
J’ai utilisé les scripts SDNExpress pour configurer le contrôleur réseau sur certains serveurs Hyper-V. Quelques jours plus tard, lors de la tentative de connexion à un partage sur l’un des serveurs Windows 2019 Hyper-V, elle échoue avec le message d’erreur suivant :

Windows ne peut pas accéder à <servername><sharename>
Code d’erreur : 0x80070035
Le chemin réseau n’a pas été trouvé.

image001.png

NOTE en aucun cas je ne dis que les scripts SDNExpress causent ce problème. Je ne fais que partager mon expérience. Cela pourrait très bien tomber dans le domaine d’un hiccup. Une des choses que le script PowerShell SDNExpress fait est d’appliquer automatiquement un commutateur logique aux NICs sur les serveurs Hyper-V que vous configurez. Pour une raison quelconque, c’est à ce moment que le problème a été introduit.

Informations supplémentaires sur ma configuration
Il y avait deux adaptateurs ethernet/NIC sur l’hôte Hyper-V configuré via un commutateur logique à l’aide de SCVMM 2019. La première NIC (MGMT) est utilisée pour la gestion et l’adresse IP est définie de manière statique et est enregistrée dans le DNS. Par conséquent, elle est utilisée pour résoudre le nom du serveur. La deuxième NIC (VMs) est utilisée pour le trafic VM et est définie via DHCP et n’est pas enregistrée dans le DNS.

Lorsque l’on tente de se connecter au partage du serveur en utilisant le NetBIOS, le FQDN (enregistré dans le DNS) ou le numéro IP de la NIC MGMT, la connexion échoue.

Lorsque l’on tente de se connecter au partage du serveur en utilisant le numéro IP ethernet/NIC des VMs, la connexion fonctionne. (C’était un indice)

SOLUTION:
Sur la NIC de gestion (MGMT) dans les Connexions réseau, les éléments suivants n’étaient PAS définis dans les propriétés:
– Client pour les réseaux Microsoft
– Partage de fichiers et d’imprimantes pour les réseaux Microsoft

Avant:

image002.png

APRES:

image003.png

Le réglage de ces deux éléments a résolu mon problème. D’une manière ou d’une autre, lors de la création des adaptateurs virtuels, ces options ont été désélectionnées.

Et c’est tout. Les étapes ci-dessus m’ont permis de résoudre le message d’erreur « Windows ne peut pas accéder… ». J’espère que ce post vous fera gagner du temps si jamais vous rencontrez ces erreurs.

Catégories : Articles

0 commentaire

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *