> Tech > Détecter ce qui ne va pas

Détecter ce qui ne va pas

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

Une fois établi que l'ordinateur est opérationnel, l'application de console à  distance entre en jeu. J'ai déclenché le client Terminal Services, que j'avais auparavant installé sur un ordinateur de mon lieu de vacances. Si vous ne pouvez pas installer ou utiliser le client Terminal Services dédié - vous êtes peut-être

Détecter ce qui ne va pas

sur un site client – vous pouvez
installer sur votre serveur le
contrôle ActiveX de Microsoft. Il vous
permet d’établir une session Terminal
Services à  partir de toute machine
Windows sur laquelle Microsoft IE
(Internet Explorer) est installé. Pour télécharger
le contrôle ActiveX, allez à 
http://www.microsoft.com/windows
2000/downloads/recommended/tsac/
default.asp.

Une fois établie la session de
console à  distance, vous pouvez utiliser
la panoplie habituelle d’outils de
dépannage: la même que si vous étiez
devant la machine. Je commence généralement
l’opération de dépannage en
utilisant l’Event Viewer pour détecter
la présence d’événements d’avertissement
ou d’information pouvant
m’éclairer sur ce qui ne va pas.
Exchange journalise la plupart de ces
événements intéressants, y compris les
divers types d’erreurs et de défaillances,
dans le journal d’événements
Application. En appliquant un
filtre avec la commande View, Filter,
vous ne verrez que les événements
d’avertissement ou d’erreur. L’élimination
par filtrage des événements
de routine contribue à  accélérer la détection
du point de défaillance. Avec
un peu de pratique, vous serez capable
d’examiner un ID d’événement et de
reconnaître le problème. Habituezvous
à  explorer la Knowledge Base de
Microsoft dès que vous rencontrez un
ID d’événement insolite. Beaucoup
d’événements courants sont décrits dans la Knowledge Base alors qu’ils
sont passés sous silence dans la documentation
d’Exchange.

Vous pouvez pratiquer deux autres
astuces à  partir de la ligne de commande,
soit par une session de console
à  distance, soit par Telnet, pour aider à 
corriger un problème :

• Les commandes Net Start et Net Stop
vous permettent de démarrer et d’arrêter
chacun des services. Comme
Win2K et NT comprennent tous
deux les dépendances des services,
vous pouvez simplement arrêter le
service System Attendant
(MSEchangeSA) pour « tuer » tous les
services Exchange. Pour exécuter
Net Stop en mode sans assistance, tapez
« net stop msexchangesa /y »
et regardez vos services se fermer en
bon ordre.

• La commande Nltest du Microsoft
Windows 2000 Server Resource Kit a
une fonction d’arrêt pratique permettant
d’essayer d’arrêter un serveur
réticent depuis la ligne de commande
d’une autre machine. Parfois,
un serveur que l’on ne parvient pas à 
arrêter depuis la console obéira à  la
demande d’arrêt formulée par
Nltest. Pour forcer un arrêt avec
Nltest, il faut deux commutateurs :
« nltest /server:<server name> /shutdown:<‘server hung’> »
Le commutateur /server indique le
serveur cible à  Nltest et le commutateur
/shutdown permet d’indiquer une
raison (« serveur planté », par exemple)
qui apparaîtra dans le journal d’événements.

Comme mon serveur Exchange
n’avait journalisé aucun message
d’événement intéressant, je n’ai pas pu
savoir immédiatement ce qui n’allait
pas. Le fait que les utilisateurs POP et
IMAP n’aient pas pu non plus se
connecter constituait un indice. Les
services étaient opérationnels mais,
comme Exchange 2000 utilise des DLL qu’IIS charge pour gérer le trafic POP3
et IMAP4, je n’ai pas pu me porter garant
de la bonne santé du Store. J’ai
commencé à  supposer que mon serveur
avait du mal à  atteindre un serveur
GC (Global Catalog), parce que
les requêtes de connexion pour POP et
IMAP échouaient immédiatement. (Je
n’ai qu’un domaine, donc le serveur
GC et le DC (domain controller) sont
la même machine, bien que j’aie deux
ordinateurs GC/DC.) Une manifestation
rapide de Dsadiag, l’un des outils
d’assistance de Win2K, m’a permis de
détecter une partie du problème : mon
serveur Exchange voulait parler au GC
nommé thunderstorm, que j’avais arrêté
en attendant un nouvel adaptateur
Fibre Channel. Le moyen le plus rapide
de régler le problème aurait été d’arrêter
et de redémarrer le Store, en l’obligeant
à  trouver un autre GC. Cette méthode
est à  proscrire en plein milieu
d’une journée de travail, mais j’ai
pensé que je pouvais l’utiliser sans
danger à  un moment non critique.
Cependant, quand j’ai essayé d’arrêter
et de redémarrer le Store, il s’est
« planté », ce qui est toujours un signe
qu’il manque quelque chose.

Téléchargez cette ressource

Guide inmac wstore pour l’équipement IT de l’entreprise

Guide inmac wstore pour l’équipement IT de l’entreprise

Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.

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