Description du problème
Sur certaines stations de travail, l’ouverture d’une session nécessitait plus de 1 heure.
Ce problème se posait aléatoirement.
Analyse du problème
Le problème provenait d’une défaillance du service WINMGMT (Infrastructure de gestion liée au passage du SP1 sur le serveur SCCM 2012 :
https://social.technet.microsoft.com/Forums/en-US/84972757-8b82-44ff-95a7-8ccdfaf3d0ba/upgrade-to-system-center-configuration-manager-sp1-caused-wmi-dcom-http-errors?forum=configmanagergeneral
La taille du répertoire %windir%System32WbemRepository était de plus de 1,5 Go sur certaines machines.
SCCM bloque l’arrêt de WMI ce qui bloquait la procédure de réparation automatique du service WINMGMT.
Le log suivant apparaissait sur les machines posant problème :
<em>Nom du journal :Application</em>
<em> Source : Microsoft-Windows-WMI</em>
<em> Date : 17/10/2014 09:58:51</em>
<em> ID de l’événement :65</em>
<em> Catégorie de la tâche :Aucun</em>
<em> Niveau : Avertissement</em>
<em> Mots clés : Classique</em>
<em> Utilisateur : N/A</em>
<em> Ordinateur : MSREPORT95.msreport.local</em>
<em> Description :</em>
<em> Le service WMI (Windows Management Instrumentation) commence la restauration du référentiel WMI</em>Correction du problème
Pour corriger le problème, il est nécessaire :
- De reconstruire le répertoire C:WindowsSystem32wbemRepository des stations de travail qui ont l’erreur Microsoft-Windows-WMI ID 65 en appliquant la procédure suivante :
- http://blogs.technet.com/b/askperf/archive/2009/04/13/wmi-rebuilding-the-wmi-repository.aspx
- De réparer le client SCCM sur les stations de travail pour que SCCM ajoute les classes WMI qui ont été supprimés à l’aide du script ci-dessous ou d’une réparation manuelle du client SCCM : https://gallery.technet.microsoft.com/SCCM-Client-Utility-WMI-ec270313
Correctifs à déployer
Nous vous invitons à déployer aussi les correctifs suivants :
- Pour corriger les problèmes de corruption WMI : http://support.microsoft.com/kb/2617858/en-us
- Pour corriger les problèmes de lenteur d’ouverture de session à cause d’un bug dans les GPO de Préférences : http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285
Comment diagnostiquer les autres problèmes d’ouverture de session lente
Etape 1 : Faire un premier état des lieux
Le but est de déterminer les changements qui ont été effectués depuis l’apparition de problème.
- Vérifier le bon fonctionnement du réseau. Je vous invite à utiliser la commande suivante : Ping IP_DC –l 56000 –t.
- Vérifier que vous n’avez pas de problème de perte de paquets.
- Vérifier le bon fonctionnement de votre annuaire Active Directory en lançant la commande : DCDIAG /V /E > c:Dcdiag.txt.
- Sur les stations de travail qui rencontrent des problèmes de lenteur d’ouverture de session, lancer la commande SET pour afficher le contrôleur de domaine utilisé pour ouvrir la session. Vérifier que votre sous réseau IP est bien rattaché à un site Active Directory dans la console Sites et Services Active Directory. Valider aussi que vous utilisez bien le contrôleur de domaine légitime.
- Sur les stations de travail qui rencontrent des problèmes de lenteur d’ouverture de session, lancer un jeu de stratégie résultant (console rsop.msc) pour lister toutes les paramètres de GPO / scripts qui s’appliquent aux machines et aux utilisateurs. Essayer à cette étape de déterminer si des paramètres GPO / scripts ont été modifiées depuis l’apparition du problème.
- Désactiver TCP Offline Engine sur quelques machines qui ont déjà rencontrées le problème. C’est particulièrement vrai sur les anciennes générations de machines. Voir :
- Analyser les observateurs d’événements (journal Application et Système) d’une station de travail. Filtrer l’affichage que sur les erreurs, événements critique et avertissement pour gagner du temps.
Etape 2 : Créer un environnement de tests
Si vous n’avez pas pu identifier l’origine des problèmes, sur un échantillon de machine qui ont déjà rencontrés le problème, effectuer les actions suivantes :
- Définissez une configuration simplifiée de scripts / GPO. Ne mettre que les paramètres nécessaires comme le proxy ou les paramètres pour lancer correctement vos applications.
- Configurer les utilisateurs pour utiliser un profil local (si utilisation d’un profil itinérant) et désactiver les fichiers hors connexions et si possible la redirection de dossiers.
- Nous vous invitons à lire cet article http://msreport.free.fr/?p=436.
- Déployer sur ces machines Windows 7 les 2 correctifs suivants :
- Simplifier la configuration de votre antivirus. Vérifier que toutes les exclusions antivirus sont bien configurées comme indiqué dans cet article :
- Désactiver la fonctionnalité Fast Logon en activant le paramètre de GPO suivant : Computer Configuration | Policies | Administratives Templates | System | Logon | Always wait for the network at computer startup and logon.
- Pour plus d’informations sur la fonctionnalité « Fast Logon », je vous invite à lire l’article suivant :
- Désactiver le pare feu sur ces machines. Vérifier que vous autoriser bien le trafic nécessaire pour la communication avec vos contrôleurs de domaine.
- Désactiver l’UAC. Pour rappel, sous Windows 8.1, pour désactiver complètement l’UAC, il faut désactiver l’UAC par stratégie de groupe en désactivant le paramètre « Exécuter les comptes d’administrateurs en mode d’approbation d’administrateur ».
- Laisser tourner environ 1 semaine et demander aux utilisateurs d’ouvrir / fermer leur session tous les jours. Ces derniers doivent consigner dans un fichier Excel la durée d’ouverture / fermeture de session tous les jours.
- Analyser systématiquement les observateurs d’événements Application et Système sur les stations de travail et le contrôleur de domaine utilisé pour ouvrir la session (commande SET). IL faut rapidement comprendre si le problème provient de la configuration des contrôleurs de domaine ou des stations de travail.
Etape 3 : Passage en mode avancé
Si vous n’arrivez toujours pas à trouver l’origine du problème, je vous invite à lire très attentivement ces 3 excellents articles.
L’article ci-dessous est une véritable base de connaissance sur les causes possible de lenteur à l’ouverture de sessions :
http://social.technet.microsoft.com/wiki/contents/articles/10130.root-causes-for-slow-boots-and-logons-sbsl.aspx
Les deux autres articles expliquent comment mettre en place les logs avancés dans le système pour trouver l’origine des problèmes de lenteur d’ouverture de session :