Problèmes intermittents de résolution DNS

Sur ~140 PC, quelques PC (aucun modèle déterminé) sont systématiquement incapables de résoudre le nom de domaine AD DS pendant le démarrage et, par intermittence, de résoudre les noms DNS AD DS après le démarrage. Ce problème peut être résolu temporairement en redémarrant le service Windows. DNS Client / dnscache et/ou redémarrer le PC jusqu'à ce qu'il fonctionne.

Mes progrès en matière de diagnostic :

1. Une fois la résolution en place, les deux contrôleurs de domaine sont joignables (vérifiés de plusieurs façons) et la stratégie de groupe s'applique mais certaines stratégies nécessitent un redémarrage, d'où ce problème.
2. La configuration DNS de la carte réseau (serveurs, etc.) est correcte.
3. Commande nltest /DSQUERYDNS sorties I_NetLogonControl failed: Status = 50 0x32 ERROR_NOT_SUPPORTED .
4. Commande Test-ComputerSecureChannel sorties True .
5. Mise à jour du dispositif de réseau Realtek PCIe GBE Family Controller Le passage du pilote de périphérique de la version 7.86.508.2014 / 08/05/2014 à la version 7.107.323.2017 / 23/03/2017 n'a pas fait de différence.
6. \\<%logonServer%>\NETLOGON\ est accessible.
7. Permettre une politique locale Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon n'a pas fait de différence.
8. Aucun trafic n'est bloqué par le pare-feu pendant le redémarrage.

Pour autant que je sache, cela n'a commencé à se produire que depuis la migration du site sur un nouveau réseau VLAN restreint. Je ne peux donc m'empêcher de soupçonner l'UTM Sophos XG 210, mais cela n'a pas de sens, car si le problème était lié au pare-feu / routage, je m'attendrais à ce qu'il soit beaucoup plus cohérent et répandu.

Mise à jour 2017/07/07 16:26

Mes progrès en matière de diagnostic :

9. La mise à jour du firmware de Sophos XG de la version 16.05.3 MR-3 à la version 16.05.5 MR-5 n'a pas résolu le problème.
10. La création d'une règle de pare-feu réseau autorisant l'utilisation du réseau local vers n'importe qui, de l'adresse IP du PC vers n'importe qui et de n'importe quel port ou service n'a pas résolu le problème.
11. La désactivation d'IPv6 sur la carte réseau et le redémarrage n'ont pas résolu le problème.
12. Exécution d'une commande élevée netsh int ip reset reset.log et le redémarrage n'a pas résolu le problème.
13. La connexion à l'aide d'un profil d'utilisateur local fraîchement généré n'a pas résolu le problème.

Mise à jour 2017/07/12 11:23

Le problème a changé sur le PC de test que j'utilise. Après le démarrage, l'envoi d'une requête au nom de domaine AD et à tout nom d'hôte de serveur résout et transmet avec succès les données suivantes mais RSoP signale toujours que l'infrastructure de stratégie de groupe côté ordinateur (et non côté utilisateur) n'a pas réussi à s'appliquer parce que The specified domain either does not exist or could not be contacted .

Mes progrès en matière de diagnostic :

14. En reconfigurant la configuration de la carte réseau presque exactement de la même manière (adresse IP, masque de sous-réseau, passerelle par défaut et serveurs DNS) de manière statique, plutôt que dynamique, j'ai résolu de manière cohérente le problème de stratégie de groupe au démarrage, côté ordinateur, sur deux des PC concernés. Je vais laisser cette configuration statique en place pendant quelques jours pour voir si elle résout également le problème de résolution DNS intermittent.

Mise à jour 2017/07/13 13:28

Le problème intermittent de résolution DNS est réapparu.

Mes progrès en matière de diagnostic :

15. Pinging de FQDNs avec trailing . n'ont pas fait de différence.
16. Reconfiguration de la NIC : réglage de la exact La même configuration (adresse IP, masque de sous-réseau, passerelle par défaut, serveurs DNS et suffixe DNS spécifique à la connexion) a résolu le problème de manière statique, bien que probablement temporaire.
17. J'ai posté un adaptateur V7 USB3-to-Ethernet pour tester s'il s'agit d'une incompatibilité entre le NIC embarqué et les commutateurs ou autre. Résultats demain.

Mise à jour 2017/08/03 14:51 :

Plus de 10 heures de diagnostics plus tard, la cause fondamentale semble être l'agent RMM de MAX RemoteManagement / MSP Remote Management (probablement le sous-composant Advanced Monitoring Agent Network Management) car nous l'avons désinstallé sur quelques PC affectés le 2017/07/25 et les problèmes ne se sont pas reproduits depuis.