> Tech > Dépannage des problèmes au niveau protocole

Dépannage des problèmes au niveau protocole

Tech - Par iTPro - Publié le 24 juin 2010
email

Un client Outlook communique avec un serveur Exchange au moyen d’appels de procédure distante (RPC) sur MAPI via une liaison réseau. Même si la vérification de la connectivité réseau de base est positive, elle n’apporte pas la garantie d’un transfert approprié des appels RPC entre le client et le serveur

Exchange.

Une méthode rapide pour déterminer si les appels RPC sont bien transférés du client au serveur consiste à accéder au profil MAPI dans l’applet Mail (Courrier) du Panneau de configuration (Control Panel). A ce niveau, ressaisissez le nom du serveur, puis cliquez sur Check Name (Vérification du nom). Cette fonction envoie une requête RPC du client vers le serveur Exchange afin de valider les informations de votre boîte aux lettres. Si la requête aboutit, les zones de nom de serveur et de nom d’utilisateur seront soulignés et le bouton Check Name sera grisé, autant de signes manifestes indiquant qu’une connexion RPC à votre serveur Exchange est possible.

Si le test de vérification du nom échoue, soit l’appel de procédure distante ne parvient pas au serveur Exchange (peut-être en raison d’un périphérique réseau, par exemple un firewall ou un routeur bloquant les paquets RPC entre le client et le serveur), soit les services Exchange ne répondent à la requête RPC (le serveur n’est peut-être pas en mesure d’accéder à un catalogue global pour traiter la requête Check Name). Pour exclure la première cause, adressez-vous à votre administrateur réseau, afin de confirmer que les appels RPC ne sont pas bloqués par un firewall ou un serveur proxy, tel que Microsoft ISA (Internet Security and Acceleration) Server 2000. Si tout est normal à ce niveau, vérifiez que les services Exchange sont en cours d’exécution sur le serveur. Dans le menu Start (Démarrer), sélectionnez Settings (Paramètres), Control Panel (Panneau de configuration) et vérifiez si, au minimum, les services Exchange System Attendant (Surveillance du système Microsoft Exchange) et Information Store (Banque d’informations) sont actifs. Dans le journal des événements de votre serveur Exchange, vous devez également rechercher la présence d’erreurs manifestes, notamment concernant un échec du démarrage de serveurs Exchange. Si les services sont actifs et si aucune erreur n’est journalisée, vous devez vous servir d’utilitaires de diagnostic afin de vérifier que les appels RPC parviennent réellement au serveur Exchange.

Pour valider la connectivité RPC, vous pouvez employer l’utilitaire Rping, disponible dans le Kit de ressources techniques Microsoft Windows Server 2003 ou le Kit de ressources techniques Microsoft Windows 2000 Server. Rping est constitué de deux composants : rpings.exe, qui s’exécute sur le serveur Exchange, et rpingc.exe, qui s’exécute sur le client. Les deux composants résident dans le répertoire \Program Files\Windows Resource Kits\Tools du serveur sur lequel vous avez installé le kit. Copiez rpings.exe vers l’emplacement de votre choix sur le serveur Exchange. Ce composant agit comme un point de termination RPC et fonctionne en permanence une fois que vous avez exécuté la commande suivante :

rpings.exe -p
MonProtocole

où MonProtocole est IPX/SPX, NAMEDPIPES, NETBIOS, TCPIP
ou VINES, selon le protocole employé pour connecter votre client Outlook au serveur Exchange. (Bien que cette commande soit présentée ici sur plusieurs lignes, elle sera entrée sur une seule ligne dans la fenêtre d’invite de commandes de Windows.) TCPIP est le protocole spécifié le plus fréquemment.

Une fois rpings.exe lancé sur le serveur, vous devez exécuter une copie de rpingc.exe sur le client. Cette deuxième version comporte une interface utilisateur graphique, illustrée à la figure 2. Vous devez entrer dans la zone de texte Exchange Server le nom qui pourra être résolu sur le serveur Exchange. Vous avez aussi la possibilité de préciser le protocole que vous souhaitez employer et si vous souhaitez valider les connexions uniquement vers le point de terminaison Rping ou vers des points de terminaison Exchange spécifiques, tels que les fonctions Store ou Admin (à savoir la Surveillance du système Microsoft Exchange).

Pour valider l’enregistrement approprié des services Exchange auprès du sous-système RPC, vous pouvez faire appel à l’utilitaire Rpcdump du Kit de ressources techniques. Cet utilitaire interroge le service Endpoint Mapper (mappeur de point final) sur le serveur Exchange et affiche les services (points de terminaison) disponibles pour les connexions RPC. Si les services sont accessibles, vous savez que le problème est lié à une connexion client spécifique et non à l’ensemble des clients. Vous pouvez exécuter Rpcdump localement sur le serveur Exchange ou à distance à partir d’un client. Pour l’exécution en local, vous pouvez utiliser la commande avec la syntaxe suivante

rpcdump /s MonServeur /i /v

où le commutateur /s demande à l’utilitaire d’interroger le serveur spécifié par MonServeur. Ce dernier peut correspondre au nom abrégé ou au FQDN. Le commutateur /i indique à l’utilitaire d’effectuer un ping sur les services afin de tester leur réponse. Le commutateur /v spécifie le mode documenté.

Rpcdump peut générer une sortie conséquente, d’où l’intérêt de pouvoir la diriger vers un fichier texte afin de faciliter l’analyse.

La figure 3 montre un exemple de sortie Rpcdump à partir de mon serveur Exchange. Si vous exécutez cet utilitaire sur votre serveur, la sortie énumérera un certain nombre de services Exchange, parmi lesquels :

  • Exchange Server STORE ADMIN Interface
  • Microsoft Information Store
  • Exchange 2003 Server STOREEMSMDB Interface
  • MS Exchange MTA ‘Mta’ Interface
  • MS Exchange MTA ‘Qadmin’ Interface
  • MS Exchange System Attendant Cluster Interface
  • MS Exchange System Attendant Public Interface
  • MS Exchange System Attendant Private Interface
  • MS Exchange Directory RFR Interface

Si les services Exchange s’exécutent sans aucune journalisation d’erreurs et si le serveur Exchange reçoit des requêtes RPC de votre client, mais que vous ne pouvez toujours pas vous connecter, une vérification supplémentaire s’impose sur le serveur. Celui-ci doit, d’une façon ou d’une autre, avoir été reconfiguré afin d’empêcher les connexions MAPI à partir de versions Outlook spécifiques. Pour confirmer ou infirmer l’existence de ce problème, vous devez examiner la valeur de l’entrée Disable MAPI Clients dans la sousclé de registre HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\MSExchangeIS\ParametersSyste m. Si elle est définie, cette valeur précisera une gamme de versions de client MAPI qui ne pourront bénéficier de droits de connexion à la Banque d’informations Exchange (Store).

(Lorsqu’ils essaieront de se connecter, les clients recevront le message d’erreur MAPI_E_LOGON_FAILED.) Les versions client désactivées sont représentées dans l’entrée Disable MAPI Clients sous forme de chaîne utilisant des virgules comme séparateur. Par exemple, la chaîne -5.0.2653.24, 11.0.4704.1-11.0.4704.4, 11.0.5604.0- désactive l’accès pour tous les clients MAPI ayant les numéros de version suivants :

  • jusqu’à 5.0.2653.24 (inclus)
  • de 11.0.4704.1 à 11.0.4704.4 (inclus)
  • 11.0.5604.0 et numéros ultérieurs (inclus)

Vous pouvez déterminer le numéro de version du client MAPI installé sur votre PC en cliquant avec le bouton droit de la souris sur le fichier emsmdb32.dll dans le répertoire \Program Files\Common Files\System\Mapi\1033, en sélectionnant Properties, puis en cliquant sur l’onglet Version. Il est à noter que l’emplacement du fichier sur votre PC peut différer légèrement, selon la version client utilisée, mais vous pouvez le trouver facilement en utilisant la fonction Search (Rechercher) du menu Start (Démarrer).

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010