none
Hote Hyper-v perd connexion au domaine RRS feed

  • Discussion générale

  • Bonjour,

    J'ai depuis pas mal de temps des problèmes de partage de fichiers, rds etc... je cherche depuis pas mal de temps, épuise les fichiers logs.Je m'étais orienté, par rapport au message d'erreur des rds à un problème de décalage d'heure sur le domaine, mais tout semble correct à ce niveau là.

    Ces problèmes interviennent environ 1 fois par semaine, pour résoudre les soucis je suis obligé de redémarrer l'hôte hyper-v ainsi que toutes les machines virtuelles.

    Juste avant d'avoir les problèmes, j'ai ces erreur dans les logs du serveur hyper-v

    Event id 1054 GroupPolicy - The processing of the grouppolicy failed.Windows could not obtain the name of a domain controller. This could be caused by a name resolution failure.Verify your DNS is configured and working correctly.

    Event id 5719 NETLOGON - This computer was not able to setup a secure session with a domain controller in domain (my domain).  There are currently no logon servers available to service this request.

    Je m'oriente vers un problème sur mon serveur physique, qui engendrerait des problèmes sur mes VMs. Est ce cohérent ? comme si la carte réseau physique ne fonctionnait plus. Et mes vms et mon hote perdaient le lien avec le controleur de domaine ?

    Est ce un problème connu ?

    Sinon vers quoi m'orienter dans mes recherches

    J'ai le problème depuis quelques mois, tout fonctionnait bien avant.

    merci

    jeudi 10 septembre 2020 12:58

Toutes les réponses

  • Bonjour,

    Pour pouvoir vous aider, il va falloir affiner le diagnostic.

    En effet, le fait de redémarrer l'hôte Hyper-V et les VM's réinitialise l'état de tous les services ce qui ne peut qu'engendrer une résolution du problème.

    Le message d'erreur Group Policy Event ID 1054 peut donner un indice sur le problème.

    Pour commencer, est-ce que vos postes se connectent avec vos différents serveurs par le biais du nom NetBios (ex: SERVEUR) ou FQDN (ex: serveur.domaine.local) ?
    Le mieux est de privilégier le FQDN car cela fait appel au DNS, ce qui est beaucoup plus fiable comme résolution denoms.

    Lors de la prochaine occurrence, lancez un diagnostic réseau depuis un poste de travail impacté :

    ipconfig /all
    ping {ip-passerelle}
    ping {ip-DNS1}
    ping {ip-DNS2}
    nslookup {FQDN-Domain}
    nslookup {FQDN-Serveur-de-fichiers}

    Renouvelez les commandes ping pour le FQDN du Serveur RDS par exemple, de l'Hyper-V etc et effectuez ceci depuis un autre poste, ou un serveur.

    Le but est de croiser le maximum d'information de connectivité pour déterminer ce qui cesse de fonctionner au moment de la panne.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    jeudi 10 septembre 2020 14:20
  • Bonjour Tony84700

    J'ai déjà rencontré par le passé ce type de pb. C'est l'event 5719 qui me met sur cette piste.Pb de décallage du démarrage du service Netlogon avec la pile réseau.

    J'ai trouvé ce lien qui pourra j'espère être utile.

    https://support.microsoft.com/fr-fr/help/938449/netlogon-event-id-5719-or-group-policy-event-1129-is-logged-when-you-s

    cordialement

    Olivier

    jeudi 10 septembre 2020 15:21
  • Merci j'essayerais de vérifier cela lors du prochain crash.Mais de mémoire, je pense avoir testé et la résolution dns fonctionnait bien.

    Pour étayer un peu, lorsque cela arrive, je ne peux plus manager mes VMS à partir de l’hôte.  J'ai des messages d'erreur, d'authentification.

    J'ai aussi dans le même temps des problèmes de réplication entre mes deux controleurs. Qui se résolvent dès redémarrage.

    J'ai eu ce problème samedi dernier, depuis aucun soucis, aucuns message dans les logs, le dcdiag est parfait. et la réplication des controleurs aussi.

    jeudi 10 septembre 2020 15:57
  • J'ai depuis pas mal de temps des problèmes de partage de fichiers, rds etc... je cherche depuis pas mal de temps, épuise les fichiers logs.Je m'étais orienté, par rapport au message d'erreur des rds à un problème de décalage d'heure sur le domaine, mais tout semble correct à ce niveau là.

    Le DC est virtuel  ? Déja eu des problèmes avec des DCs virtuel qui était configuré pour synchroniser l'horloge avec le host. Dans les logs on avait régulièrement deux évenement de temps, créant un décalage récupéré quelques minustes après par la synchro de l'AD, donc pas visible par après, sauf dans les logs.

    http://pbarth.fr/node/87

    jeudi 10 septembre 2020 16:10
    Modérateur
  • oui, virtuel, mais il est bien configuré pour synchroniser à extérieur, et la synchro est désactivée avec l'hôte

    Et même si la connexion en bureau à distance indique un décalage d'heure, l'heure est identique sur tous les serveurs. C'est pour cela que je penche à un problème de connexion avec le / les contrôleurs à un moment donné qui  fait planté l'ensemble.

    jeudi 10 septembre 2020 18:03
  • Pour étayer un peu, lorsque cela arrive, je ne peux plus manager mes VMS à partir de l’hôte.  J'ai des messages d'erreur, d'authentification.

    Hum... et en administrateur local, arrivez-vous à manager les VM's ?

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    vendredi 11 septembre 2020 05:51
  • @Philippe : J'avais également pensé à la sync heure sur les guest, mais il parlait également de pb sur l'hôte avec cet ID 5719. S'il a des pbs sur l'hôte, ça peut se répercuter sur les VMs au-dessus.

    tony84700 a écrit : [...Et même si la connexion en bureau à distance indique un décalage d'heure, l'heure est identique sur tous les serveurs. C'est pour cela que je penche à un problème de connexion avec le / les contrôleurs à un moment donné qui  fait planté l'ensemble...]

    ==> Ce n'est pas un pb de connexion avec les DCs mais un pb de ticket kerberos. Si une machine a plus de 5 min d'écart horaire avec un DC, bye le ticket ... et tous les services applicatifs qui s'appuient sur l'AD pour l'authentification, donc Kerkeros, bye aussi. Regardes les logs sur tes VMs, lors de leur démarrage. Laisse-les dans l'ordre tel qu'il est présenté (ne fait pas de tri), qui devrait être chronologique donc. Si a un moment cet ordre chrono est cassé, puis que peu de temps après les erreurs commencent, c'est que tu as identifié la cause : l'heure.

    J'avais ce cas sur des VMs (-7min quand un service spécifique démarrait), et plus rien ne fonctionnait après. Dans mon cas, c'était de Service qui correspond aux VMwaretools, et celui-ci était configuré pour sync les guests sur l'Hôte. L'esx avait un NTP commun avec le NTP externe du domaine AD des VMs, et cela n'aurait pas du produire d'effet négatif dans ce cas. Oui, mais cela ne se produisait que quand l'esx rebootait également. ESX démarre, service NTP démarre mais ne peut pas sync heure car carte réseau pas opérationnelle (donc on s'appuie sur l'heure locale qui naturellement est en décalage), les services de virtu et les VMs démarrent, se sync sur l'hôte et - 7 min. Quand on redémarrait seulement les VMs, aucun pb sur celle-ci. Ce qui n'a pas facilité le diagnostic et une 'tite bagarre entre le mec de la virtu et moi (il ne voulait pas supprimer la sync horaire hôte/guest ... parce que ça marche pour les machines Linux ... qui fonctionnent en mode autonome sic !).

    Dans un premier temps, j'ai fait supprimer la Sync Guest/hôte, et j'ai vérifié derrière. Ca a apporté un résultat, mais le mec de la virtu doutait toujours. Je me suis arraché les yeux à rechercher plusieurs dizaines de reboots des VMs lesquels avaient eu des pbs après. Il n'y avait eu des pbs que quand l'hôte était rebooté également et seulement dans ce cas.

    Dans ton cas, ton hôte Hyper-v indique au démarrage qu'il a eu des pbs pour joindre un DC au démarrage. Donc adieu le ticket kerkeros pour ton hôte. Pourquoi ? Parce le service Netlogon a tenté de joindre un DC alors que le réseau n'était pas encore monté. Le lien donné donne des pistes sur les clés à modifier. Et puis on peut le faire de manière secure en notant les valeurs desdites clés avant modif, pour un retour-arrière.

    cordialement

    Olivier

    vendredi 11 septembre 2020 06:06
  • Merci pour ta réponse

    Je pense effectivement que le problème est sur l'hôte et se répercute sur les vms.

    Par contre, j'ai du mal à comprendre pourquoi cela arrive d'un coup en pleine prod.

    Le lien noté plus haut, indique plutôt un problème au démarrage de la machine ce qui n'est pas le cas pour moi. cela se produit à n'importe quel moment. Et le redémarrage résout le problème.

    J'ai lu certains posts en anglais qui parlent de désactiver les gestions d'énergie des cartes réseau, et de mettre les vms en mode gestion énergie performances élevées.

    vendredi 11 septembre 2020 06:26
  • Salut à tous,

    cette nuit vers 2h du matin, plantage. Je m'en suis apercu en ayant recu un mail de la sauvegarde veeam qui n'arrivait pas à se connecter sur l'hote (erreur RPC)

    Sur l'hôte je retrouve en premier l'id 1054 plusieurs fois, puis après l'id 5719.

    Sur le DC, j'ai des erreurs de réplication avec mon second DC (la connexion n'est pas valide)

    Sur l’hôte, la résolution dns fonctionnait bien ce matin (avant redémarrage) et je pingais toujours l'ensemble des serveurs virtuels.

    Je ne comprends pas pourquoi, cela arrive d'un coup, quasiment 1 semaine après l'autre crash

    samedi 12 septembre 2020 04:57
  • Bonjour, En avez-vous profité pour vérifier si vous pouviez administrer les VM’s en vous logguant en Administrateur local sur l’hôte ? Cela permettrait de pouvoir vous connecter sur les VM’s lors d’une nouvelle occurrence pour pouvoir faire des tests? En effet, la connectivité entre l’hôte est les VM’s est toujours OK, du coup on peut presque retirer l’hôte de la liste des coupables. Questions supplémentaires: - quels sont les DNS déclarés dans les cartes réseaux des différents serveurs ? - est-ce que tous les services sont UP sur les DC au moment où le problème survient ?

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    samedi 12 septembre 2020 06:14
  • Bonjour,

    le problème vient de se reproduire, en pleine prod (donc ce n'est pas un problème qui revient à période fixe)

    Je me suis logué en admin local, et je ne peux pas manager les machines virtuelles.

    Que cela signifie t'il ?

    Par contre, j'ai un second hôte avec quelques machines virtuelles, et sur celui ci pareil, je ne peux pas manager les VM, ni en admin du domaine, ni en admin local.

    Je vois dans les logs de mon second contrôleur, les erreurs groupPolicy id 1054, netlogon 5719, ainsi qu'un time-service id 50 indiquant une différence supérieure à 5000millisecondes.

    Je n'ai aucun messages dans les logs sur mon premier contrôleur (avec les rôles fsmo)

    Après reboot de l'hôte hébergeant le second contrôleur, retour à la normale sur celui ci.

    Toujours impossible de manager les vm sur le premier hôte. Un redémarrage va être nécessaire.

    • Modifié Tony84700 vendredi 18 septembre 2020 12:54
    vendredi 18 septembre 2020 11:36
  • Bonjour Tony84700

    On en revient toujours au même point. Regarde ce lien : https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/netlogon-event-id-5719-or-group-policy-event-1129

    Cause

    This issue may occur for any of these reasons:

    • The Netlogon service starts before the network is ready. The network stack and adapter initialization often start at about the same time. Some network adapters and switches have link arbitration and MAC address uniqueness checks that take longer to complete than the wait time that is set for Netlogon to detect network connectivity.

    Ton hôte n'arrive pas à s'authentifier, du coup pas de ticket Kerberos, et tous les services qui s'appuient sur l'AD tombent.

    Mais il me semble bien déjà avoir donné cette piste plus haut, non ?

    cordialement

    Olivier

    vendredi 18 septembre 2020 14:05
  • Je suis d'accord, mais comme j'avais répondu, je ne vois pas le lien, car cela ne se produit pas au démarrage de la carte réseau (ni de l'ordinateur) cela se passe en pleine prod, les serveurs étant déjà démarrés depuis longtemps.

    De plus, sur les deux hôtes en même temps. Le problème vient d'ailleurs pour moi..

    vendredi 18 septembre 2020 15:02