Après avoir implanté une agence distante connectée au siège social via T1, nous avons rencontré une difficulté avec des utilisateurs d'Exchange 2003 au point distant. Toute la journée, ils reçoivent des messages indiquant que le serveur Exchange a perdu la connectivité, de sorte qu'Outlook met leur connexion en état « offline ».
Les utilisateurs conservent la connectivité Internet par l'intermédiaire du siège social et peuvent accéder à leurs dossiers mappés sur le même serveur en utilisant Exchange : ils ne peuvent simplement pas revenir dans leurs sessions Exchange. Le serveur ne journalise aucun message inhabituel et les utilisateurs locaux ne sont pas touchés par ce problème.
R : Les problèmes tels que celui que vous signalez ne sont pas si rares. Ils s’expliquent par le fait que Microsoft Exchange est particulièrement sensible aux problèmes de communication.
Les symptômes que vous constatez sont dus à trois causes principales : (1) un intervalle de timeout client trop court, (2) l’engorgement inattendu du réseau et (3) des erreurs sur la ligne de communication non détectées. Pour pousser l’analyse et déceler la vraie cause, procédez comme suit.
Premièrement, procurez-vous un outil appelé rpcping qui simule une requête RPC (Remote Procedure Call) du client au serveur. Exchange utilise RPC pour toutes ses communications client/serveur, donc il est essentiel de vérifier le bon fonctionnement de RPC. Quand la défaillance se produit, essayez d’exécuter rpcping à partir du client défaillant vers l’adresse IP du serveur. Si rpcping échoue, il s’agit d’un problème de communication. S’il réussit, il s’agit probablement d’un intervalle de timeout insuffisant.
Pour spécifier la valeur de timeout client d’Exchange, il n’existe pas de règle simple et rapide. Le paramétrage par défaut suppose que le client et le serveur sont sur le même LAN haute vitesse. Cependant, les utilisateurs éloignés pourraient constater des délais plus longs, par suite de congestion intermittente de la liaison ou d’erreurs. Pour accéder au paramètre timeout d’Outlook, sélectionnez Tools, EmailAccounts, More Settings et General. Doublez la valeur et observez la performance pendant un jour ou deux. Vous devrez peut-être poursuivre cette expérience pendant quelques jours avant de trouver le meilleur paramétrage.
Si le rpcping échoue, vous êtes confronté à une vraie panne de réseau. Commencez par vérifier l’engorgement de la liaison en inspectant les compteurs de débit sur votre routeur WAN. Un outil de supervision SNMP gratuit, comme MRTG (http://people.ee.ethz.ch/~oetiker/webtools.mrtg) vous permettra de suivre le trafic WAN au fil du temps. Examinez aussi les compteurs d’erreurs dans les routeurs WAN aux deux extrémités de la liaison WAN, pour vous assurer que des erreurs de données n’entraînent pas une perte de données. Si vous constatez des erreurs excessives, essayez de les résoudre avec le concours de votre fournisseur de connectivité WAN.
Téléchargez cette ressource
État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
