Outils et techniques de dépannage des connexions de client MAPI, problèmes de connexion avec OUTLOOK 2003

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.