> Tech > Etape 2 : Dépanner les problèmes centraux en vérifiant l’infrastructure

Etape 2 : Dépanner les problèmes centraux en vérifiant l’infrastructure

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Supposons que le Group Policy Results Wizard révèle une défaillance du traitement central (c’est-à-dire que l’état du composant Group Policy Infrastructure était Failed). Ce genre de défaillance révèle souvent un problème d’infrastructure lié au client ou au DC (domain controller) à partir duquel l’information de stratégie est lue. A noter

Etape 2 : Dépanner les problèmes centraux en vérifiant l’infrastructure

que le terme « client », dans ce contexte, peut représenter un serveur ou une station de travail. Les problèmes de traitement central peuvent avoir plusieurs sources. Commencez par les vérifications suivantes :

• Le service d’aide TCP/IP NetBIOS est-il actif sur la machine client ? Il est indispensable pour un bon traitement de la stratégie de groupe. Pour vérifier ce point, soit tapez
net start

à une invite de commande pour obtenir la liste de tous les services actifs, soit allez dans le groupe de programmes Administrative Tools sur le menu Start et sélectionnez le snap-in Microsoft Management Console (MMC) Services pour vérifier que le service a été activé.
• DSN est-il bien configuré sur le client de telle sorte que le système résolve correctement les DC ?
• ICMP est-il validé sur votre réseau ? Le client et le DC doivent pouvoir utiliser ICMP pour la détection sur ligne lente avant que le traitement des stratégies de groupe puisse se produire. Si ICMP n’est pas validé, tout le traitement de la stratégie de groupe échouera.
• Le client peut-il accéder à la copie du GPO qui est stockée dans Sysvol sur le DC avec lequel le client communique ? Dans la négative, le traitement de la stratégie de groupe échouera. Vous pouvez utiliser gpotool.exe – l’un des outils Microsoft Windows 2000 Resource Kit – pour consulter tous les DC présents dans un domaine et déterminer si une réplique de Sysvol liée au stockage des stratégies de groupe est désynchronisée. Une réplique de Sysvol désynchronisée indique généralement un problème de réplication de FRS. L’article Microsoft « How To Troubleshoot the File Replication Service in Windows Server 2003 »  est un bon point de départ pour dépanner les problèmes FRS sur Windows 2003. L’outil de supervision et de dépannage Ultrasound FRS peut aussi aider à identifier et à corriger les problèmes de réplication de FRS.

Vous pouvez aussi recueillir des indices sur les problèmes de traitement central, en consultant le journal d’événements Application de l’ordinateur client, pour y rechercher des événements qui ont Userenv comme source d’événement. De tels événements concernent généralement le traitement central et contiennent parfois des informations sur des erreurs spécifiques survenues pendant le traitement. Dans ce cas, il serait bon d’utiliser le modèle gpolog.adm pour valider la journalisation d’événements Application détaillée.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010