par Kieran McCorry - Mis en ligne le 15/03/06- Publié en Janvier 2005
Vous pouvez accéder de différentes façons aux boîtes aux lettres Exchange Server 2003. Dans le cas d’un accès traditionnel par client MAPI (Messaging API) au moyen de Microsoft Office Outlook 2003, vous pouvez soit opter pour le mode en ligne classique, soit utiliser les connexions RPC via HTTP. Il est également possible de se connecter via Outlook Web Access (OWA) ou un périphérique de poche. Enfin, vous pouvez choisir de n’établir aucune connexion et de travailler en mode de mise en cache.
Pour vous connecter à votre boîte aux lettres Exchange, vous vous contentez généralement de démarrer votre client. Toutefois, des modifications de l’environnement empêchent parfois le bon déroulement de cette procédure. Certains outils et techniques de dépannage sont à votre disposition pour vous aider à résoudre les problèmes de connexion des clients MAPI. Cet article présente les techniques de dépannage des problèmes de connexion avec le mode en ligne classique d’Outlook. Elles font appel aux outils servant à contrôler la présence de problèmes au niveau du réseau, au niveau protocole et au niveau application. Au cours d’un prochain article, je décrirai les outils et techniques de dépannage permettant de résoudre les problèmes liés aux connexions RPC via HTTP
Outils et techniques de dépannage des connexions de client MAPI, problèmes de connexion avec OUTLOOK 2003
![Outils et techniques de dépannage des connexions de client MAPI, problèmes de connexion avec OUTLOOK 2003 Outils et techniques de dépannage des connexions de client MAPI, problèmes de connexion avec OUTLOOK 2003](https://www.itpro.fr/wp-content/uploads/2014/10/e660906718a7d18291606ea2e6fb20cd.jpg)
Lorsque vous démarrez Outlook en mode classique, le contenu de votre boîte aux lettres doit s’afficher immédiatement après l’authentification du client. (Le processus d’authentification peut ne pas être évident si vous utilisez l’authentification intégrée de Windows et si vos informations d’identification sont déjà mises en cache sur le client.) Si la boîte aux lettres n’est pas visible, vous devez d’abord déterminer si vous disposez d’une connexion entre le client Outlook et le serveur Exchange.
Pour cela, la première étape consiste à vérifier si votre client possède une adresse réseau. Utilisez la commande
ipconfig /all
à partir de la fenêtre d’invite de commandes afin de contrôler la configuration réseau du client. Cette commande permet de collecter des informations sur l’adresse TCP/IP affectée au client ainsi que sur la passerelle par défaut, les serveurs DNS et les serveurs WINS. En cas de problème lié à l’adresse TCP/IP, il sera peut-être nécessaire de reconfigurer vos paramètres réseau ou de vous assurer que les serveurs DHCP utilisés fonctionnent correctement.
Si tout est normal au niveau de la configuration réseau du client, vous devez vérifier s’il est possible d’établir une connexion réseau entre le client et le serveur Exchange. La méthode la plus simple consiste à utiliser la commande Ping. A partir de la fenêtre d’invite de commandes de Windows, exécutez la commande suivante
ping AdresseIP
où AdresseIP est l’adresse TCP/IP de votre serveur Exchange. Ayez à l’esprit qu’un pare-feu (firewall) intercalé entre le client et le serveur bloquera les requêtes d’écho ICMP (Internet Control Message Protocol) utilisées par la commande Ping. Par conséquent, l’échec de cette commande n’est pas forcément synonyme d’un problème de réseau.
Vous pouvez poursuivre le dépannage de la connexion réseau au moyen de la commande Tracert. Dans la fenêtre d’invite de commandes de Windows, utilisez la syntaxe suivante tracert AdresseIP
Il est également possible de remplacer l’adresse TCP/IP par le nom du serveur Exchange. La figure 1 illustre un exemple de sortie retournée par cette commande. En cas de coupure du réseau entre le client et le serveur, le résultat de la commande Tracert peut vous aider à localiser la défaillance.
Notez également que cette commande, au même titre que la commande Ping, utilise les requêtes d’écho ICMP. Même si la connexion au serveur Exchange est possible, Tracert présente une utilité. Vous pouvez rechercher des valeurs de latence particulièrement élevées sur le trajet de la connexion entre votre client et le serveur. Des latences supérieures à 500 millisecondes (ms) méritent un examen approfondi de l’administrateur réseau.
Par défaut, le client Outlook essaie d’abord de contacter le serveur RPC Endpoint Mapper sur le port 135 du serveur Exchange afin de convenir d’un ensemble de ports MAPI éphémères (ou provisoires) situés dans la plage 1024 à 65 535 et via lesquels le client et le serveur pourront établir leur session. Pour déterminer l’existence d’un problème au niveau d’un des ports MAPI provisoires, vous pouvez exécuter la commande Netstat sur le client ou le serveur, avec la syntaxe suivante
netstat -a
Ce faisant, vous pouvez connaître les ports réseau en cours d’utilisation pour les communications. Il est également possible d’exécuter cette commande sur les clients sans problème de connectivité, afin de confirmer que les connexions peuvent être établies sur une gamme de ports spécifiques. Des changements au niveau de firewalls ou de réseaux locaux virtuels (VLAN) sont susceptibles d’empêcher les connexions dans cette plage de ports MAPI. Autrement dit, si des problèmes de connexion surviennent de manière soudaine, demandez à votre administrateur réseau si des changements sont intervenus récemment. Les clients peuvent également accéder à des serveurs de catalogue global (GC) pour des références de liste d’adresses globale (GAL). Par conséquent, tout changement au niveau des serveurs GC peut également empêcher les accès. Pour plus d’informations sur la modification de la plage de ports MAPI en vue d’employer des valeurs statiques spécifiques, consultez l’article Microsoft « Exchange 2000 and Exchange 2003 Static Port Mappings » (http://support.microsoft.com/?kbid= 270836 ).
En règle générale, les problèmes de résolution de noms constituent la principale cause des incidents de connexion des clients Outlook. Assurez-vous que les noms abrégés ou les noms de domaine entièrement qualifiés (FQDN) employés dans votre profil MAPI sont résolus vers l’adresse TCP/IP appropriée. Pour vérifier que la résolution du nom de votre serveur Exchange (nom abrégé ou FQDN) s’effectue correctement au niveau de DNS, vous pouvez vous servir de la commande Nslookup. Dans la fenêtre d’invite de commandes de Windows, utilisez la syntaxe suivante nslookup NomMonHôte où NomMonHôte est le nom du serveur cible dont vous souhaitez confirmer la connectivité. Vous pouvez également employer la commande Nslookup pour vérifier que le nom du serveur Exchange est résolu correctement au niveau du fichier HOSTS ou LMHOSTS dans le dossier \%systemroot%\ system32\drivers\etc.
Bien que ces techniques et outils de dépannage soient présentés ici dans le contexte des connexions de client MAPI, leurs domaines d’utilisation sont nettement plus étendus. En règle générale, vous pouvez les employer pour dépanner n’importe quel type de problème de connexion client.
Téléchargez cette ressource
![Guide des Solutions Cloud & Services Managés Simplifiés](https://www.itpro.fr/wp-content/uploads/2024/05/TOP-5-des-Services-Manages-Simplifies-2024-IT-Experts.jpg)
Guide des Solutions Cloud & Services Managés Simplifiés
Comment capitaliser sur son existant tout en bénéficiant, dès à présent, des promesses de flexibilité et de scalabilité du cloud ? Découvrez les bonnes pratiques pour répondre aux défis de simplification du Cloud dans ce nouveau TOP 5.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Impact de l’IA générative sur le lieu de travail
- Red Sift : une proposition clé pour sécuriser le patrimoine numérique
- Cloud Temple : le cloud de confiance de référence du marché français et européen
- Fusion d’identités avec Binary Tree Directory Sync Pro
- Contrôler et optimiser les dépenses informatiques dans le contexte macroéconomique actuel
![Revue Smart DSI](https://www.itpro.fr/wp-content/uploads/2024/07/SMART-DSI-Numero-34-Juin-2024.jpg)