Les 6 étapes vers un diagnostic réussi

Si l’on étudie les méthodes utilisées par les dépanneurs chevronnés, on sera peut-être surpris de voir avec quelle précision leur procédé de résolution des problèmes calque ces étapes (ou vice versa). De nombreux domaines, comme la médecine ou l’engineering, utilisent des variantes de ce procédé. Suivez les précisément, résultat bluffant 

Etape 1 : Identifier ce qui ne va pas. Identifier correctement le problème est un must : si l’on ne sait pas ce qui ne va pas, on a très peu de chances de résoudre le problème. L’interview aide à mener cette étape à bien.

Etape 2 : établir les limites du problème. Savoir jusqu’où s’étend le problème peut conduire à  la bonne solution en un minimum de temps. Dans ce cas encore, l’interview est utile. Après plus ample examen, on peut s’apercevoir que ce problème ressemble à un de ceux que l’on a résolus de par le passé. On peut également rechercher les symptômes du problème sur TechNet ou sur sa base de connaissances favorite. On peut également s’apercevoir que ce problème ressemble exactement à  un problème documenté dans un article Microsoft. (Bien sûr, le fait de quitter et de relancer Outlook, ou de rebooter le PC client, pour voir si cela résout le problème, est toujours utile.)

Etape 3 : choisir les solutions potentielles. Lister les possibles causes fondamentales du problème identifiées aux étapes 1 et 2. Lister également au moins un test de diagnostic (✔c’est-à-dire un test pour déterminer si cette cause est vraiment responsable) et une solution potentielle (✔c’est-à-dire une action susceptible de solutionner le problème) pour chaque cause. Affecter des priorités à  cette liste en fonction des causes les plus probables. L’objectif de cette étape est d’identifier les solutions potentielles, non de les tester.

Etape 4 : commencer à  tester ses solutions. Maintenant que l’on dispose d’une liste des causes possibles avec leurs priorités, il faut commencer à  tester les solutions potentielles à  ces causes. Mais attention, comme le dit souvent le docteur,  » En priorité, ne pas faire de mal « . Avant de démarrer cette étape, il faut être sûr d’avoir de bonnes sauvegardes de la machine sur laquelle on travaille.

Etape 5 : S’assurer que le problème est résolu. Il existe une nuance subtile entre le fait de solutionner un problème et celui de le faire à peu prêt ou de déguiser ses symptômes. Idéalement, on voudrait solutionner un problème de façon permanente, mais parfois, ce n’est pas possible, ou on ne sait pas comment faire, ou bien encore on ne dispose pas du temps nécessaire pour ce faire, et on est tenté de l’occulter. Le moment est maintenant venu de décider si le problème est non-récurrent, s’il est susceptible de se reproduire, et ce qu’il serait possible de faire pour éviter qu’il se reproduise.

Etape 6 : tenir un journal. Garder une trace qui rappelle ce que semblait être le problème initial, ce qu’il était réellement, et la façon dont on l’a résolu. Les données de ce journal constituent un enregistrement inestimable
pour des références futures (voir étape 2), aussi bien que pour toute personne héritant du système de messagerie dont on assure la maintenance. Toutefois, il ne faut pas conserver ces informations sur la machine Exchange Server, sinon il
est possible qu’elles deviennent indisponibles quand on en a vraiment besoin.

Dans ce journal, il faudrait également inclure une liste de problèmes courants que les utilisateurs peuvent solutionner sans assistance, avec des instructions pour les résoudre.

Pour avoir quelques exemples courants, voici quelques  » UsualSuspects « 

Les clients mail sont la source d’une variété étonnante de problèmes, bien au delà  de ce que pourrais écrire en une année complète dans ma rubrique. Cependant, les problèmes suivants et leurs solutions constituent de bons
exemples du type de scénario liés au client auxquels il est probable d’être confronté. Outlook se met en erreur lorsqu’un utilisateur tente d’ouvrir un message donné. Ce problème indique généralement que le message est corrompu. On peut parfois le résoudre en supprimant le message ou en déplaçant la boite aux lettres sur un serveur différent. Si le message en question se trouve dans un PST (personal store), on peut essayer d’exécuter Scanpst,
ce qui peut éventuellement résoudre le problème. Dans certains cas (comme par exemple lorsqu’un message particulier provoque une erreur dans Outlook), il peut être nécessaire d’utiliser l’outil Mdbvu32, contenu dans le Microsoft BackOffice Resource Kit (BORK). Mdbvu32 permet d’isoler et de supprimer le message incriminé directement à  partir de la boite aux lettres côté serveur.

Les messages disparaissent après que l’utilisateur les aie lus. Toutes les fois que j’ai rencontré ce problème, c’était lié au fait que l’utilisateur avait paramétré son logiciel pour qu’il ne lui présente que les messages non-lus, puis avait oublié qu’il avait mis en place cette vue. En standard, Exchange Server ne supprime aucun courrier (bien qu’on puisse toujours aller voir le dossier des éléments supprimés pour vérifier que l’utilisateur l’a pas supprimé de messages sans s’en rendre compte).

Les temps de chargement sont inhabituellement longs sur le client. Des temps de chargement inhabituellement longs sont en général liés à  un ordre de liaison RPC (remote procedure call) incorrect, ou à  des problèmes de résolution
de noms. La base de connaissances de Microsoft est truffée d’articles sur la résolution de ces problèmes.