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
Guide des solutions de cloud & services managés simplifiés
A la fois cloud provider et ESN, le groupe ACESI s’appuie sur les technologies VMware pour apporter toute la richesse du cloud dans des environnements hybrides. Découvrez, dans ce guide thématique, les bonnes pratiques pour répondre aux défis de simplification du Cloud.
