2016-05-31 5 views
0

J'ai un problème très étrange.ADSI échoue avec l'erreur 8007203a après la migration en direct du cluster de basculement Hyper-V

Nous avons un cluster de basculement Hyper-V, où certaines machines virtuelles clientes commencent à montrer des problèmes spécifiques après une migration en direct.

Dans chaque cas, la migration en direct fonctionne principalement, mais après sa migration, nous ne pouvons plus nous connecter à certains logiciels (notre produit WinGate). La poignée de main SSPI réussit, nous pouvons RDP à l'image, donc ce n'est pas en réseau.

Mais ADSI ne parvient pas à ouvrir un objet de recherche pour récupérer un objet utilisateur et renvoie l'erreur 8007203A.

Étant donné que la mise en réseau fonctionne, SSPI fonctionne, évidemment la connectivité de domaine fonctionne dans une certaine mesure, mais l'échec ADSI est très perplexe.

Est-ce que quelqu'un d'autre a déjà vu ça? Je pense que c'est probablement un bug dans Windows, mais nous le voyons depuis plus de 18 mois maintenant - depuis que nous avons mis en place le cluster.

P.s. tous les hôtes et les machines virtuelles sont complètement corrigés. P.p.s. tous les MAC MAC sont corrigés.

+0

Une autre chose que je viens de remarquer. Toutes les machines qui montrent ce problème sont à double hébergement (2 NIC), et dans l'état de problème, l'adaptateur interne sur chacun montre comme un réseau inconnu. Cela peut être un problème de pare-feu provoqué par le redémarrage des cartes réseau. Je dois désactiver l'adaptateur externe avant de pouvoir redémarrer l'adaptateur interne avec succès (il est alors détecté comme un adaptateur de domaine). – Adrien

Répondre

0

OK, on ​​dirait que j'ai trouvé la réponse.

Le problème est que NLA a reclassé l'adaptateur de réseau de domaine après une migration en direct et l'a définie sur un réseau non identifié. Cela a ensuite donné un coup de pied dans le pare-feu pour bloquer ADSI.

grâce à this blog J'ai été en mesure de forcer NLA à afficher l'adaptateur en tant qu'adaptateur de domaine (en ajoutant un suffixe DNS de domaine à l'adaptateur) et le problème est résolu. J'espère que ceci aide quelqu'un d'autre!

+0

a parlé trop tôt. Je suis sûr que c'est le problème NLA, je dois désactiver l'adaptateur externe après une migration en direct avant de rebondir l'interne pour qu'il découvre que c'est un réseau de domaine. Si l'adaptateur externe est activé, il ne parvient toujours pas à identifier l'adaptateur interne. On dirait qu'une sorte de problème de diffusion sort des deux adaptateurs. J'ai vu des messages disant qu'ils ont le problème dans l'autre sens (adaptateur externe découvert comme interne), probablement lié à l'ordre de liaison, et quelle adresse IP est considérée comme l'ordinateur. – Adrien