Comment ça marcheDépannage d’erreurs RPC

Zubair Alexander

Si vous avez déjà eu l’occasion de travailler avec des plates-formes Windows Server, vous avez sans doute eu l’occasion de voir des erreurs d’appel de procédure distante (RPC) à un moment ou un autre. Ces erreurs vous informent que le serveur RPC est indisponible ou qu’il n’y a plus de points de terminaison disponibles, à moins qu’ils ne fournissent un autre avertissement énigmatique. Si ces messages vous déroutent, cet article vous intéressera. Je vais

examiner des erreurs courantes, diverses techniques utilisables pour identifier les erreurs RPC que vous voyez et aborder certaines solutions pour résoudre des problèmes spécifiques. Mais avant que je ne parle des erreurs RPC et de solutions spécifiques, étudions les bases terminologiques de RPC.

Qu’est-ce que RPC ?

RPC est une méthode de communication interprocessus (IPC) utilisée par des clients et des serveurs pour communiquer ensemble. Plus simplement RPC est utilisé par des programmes, généralement sur un ordinateur client, pour exécuter un programme sur un serveur. Par exemple, des clients Microsoft® Outlook® communiquent avec Microsoft Exchange Server à l’aide de RPC. L’ordinateur client envoie un message au serveur avec certains arguments. Le serveur répond au client avec un message qui contient les résultats du programme exécuté.

Le point de terminaison fait partie intégrante de ce processus : le nom, le port ou le groupe de ports sur un ordinateur contrôlé par un serveur pour les requêtes client entrantes. Plus précisément, il s’agit d’une adresse spécifique au réseau d’un processus de serveur qui est utilisé pour les RPC.

L’Endpoint Mapper, qui fait partie du sous-système RPC, est chargé de répondre aux requêtes des clients pour résoudre des points de terminaison dynamiques. Dans certaines situations, l’Endpoint Mapper est également chargé d’attribuer des points de terminaison aux serveurs de façon dynamique.

Le service Localisateur est un autre composant important de RPC. Il gère une liste de services et serveurs RPC sur le réseau. Un client Windows® se connecte au contrôleur de domaine sur les ports Server Message Block (SMB) (TCP 139 et 445) et recherche des services ou serveurs RPC par le biais du service Localisateur.

La plupart des services Windows intégrés communiquent entre eux via RPC. Par exemple, les services de certificats, DCOM, FRS, MSMQ, MAPI et le service de réplication Active Directory® se servent de RPC pour la communication. Donc, si le service RPC ne fonctionne pas convenablement sur un réseau, il se peut que vous rencontriez un certain nombre de problèmes de communication.

Erreurs RPC

Examinons à présent certaines des erreurs que vous pouvez rencontrer en cas de panne du service RPC. (Cette liste n’est en aucun cas exhaustive.)

Lorsque le service de réplication de fichier (FRS) tombe en panne, il peut s’agir d’une erreur redoutée d’indisponibilité de RPC. Si vous essayez de mapper un lecteur, vous pouvez obtenir une erreur d’accès refusé. Lorsque vous utilisez Utilisateurs et ordinateurs Active Directory, vous pouvez voir l’erreur indiquant que le domaine spécifié n’existe pas ou n’a pu être contacté. En vous connectant au domaine, vous pouvez obtenir une erreur indiquant que le système ne peut pas vous connecter à ce domaine parce que le compte d’ordinateur système dans son domaine principal est manquant ou le mot de passe sur ce compte est inexact.

Lorsque le client Microsoft Outlook essaye de communiquer avec Exchange Server, les défaillances RPC peuvent indiquer au client une erreur trompeuse, en lui signalant par exemple que ses informations de connexion sont inexactes ou qu’Outlook n’a pas pu ouvrir de session.

En plus de ces erreurs, lorsque le service RPC n’est pas disponible, vous pouvez rencontrer d’autres problèmes. Par exemple, il se peut que vous ne puissiez pas accéder au domaine dans Favoris réseau ou ouvrir le composant logiciel enfichable Stratégie de groupe.

Il s’agit là de quelques exemples de situations dans lesquelles vous ne vous attendiez sans doute pas à ce que RPC crée des problèmes. Il y a de nombreux autres exemples et, dès que vous travaillez avec des processus à distance, les problèmes de RPC peuvent être la cause initiale de vos difficultés. Donc comment s’en assurer et, surtout, comment dépister l’erreur précise ? Voyons cela.

Dépannage

Si vous pensez que le service RPC entraîne des problèmes, il y a plusieurs outils que vous pouvez utiliser pour diagnostiquer les problèmes.

Repadmin est l’un de ces outils. Ce programme est habituellement utilisé pour contrôler et dépanner des problèmes de réplication d’Active Directory, mais il peut également être utilisé pour dépanner des problèmes d’Endpoint Mapper RPC. Pour l’exécuter, à l’invite de commande, tapez repadmin /bind. Si vous avez des problèmes de RPC, vous risquez de voir s’afficher un message vous signalant qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper. Il s’agit là d’un premier indice que le problème est lié à RPC.

Vous pouvez aussi utiliser l’outil de diagnostic du contrôleur de domaine (DCDiag), un programme de ligne de commande qui permet de diagnostiquer les problèmes de contrôleurs de domaines. Si vous voyez une erreur indiquant un état 1722 qui signifie que le serveur RPC est indisponible, vous savez que vous avez un problème de RPC que l’outil de diagnostic du contrôleur de domaine vient juste de dévoiler.

Parfois, lorsque vous utilisez Ntdsutil (un outil de ligne de commande qui sert à gérer Active Directory et à exécuter de nombreuses tâches de maintenance), vous pouvez rencontrer des erreurs RPC si vous essayez de vous connecter au serveur. L’une des erreurs les plus courantes se traduit généralement par un message vous informant qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper. Ceci est un nouvel indice que le service RPC rencontre sans doute des problèmes. Avec l’outil Gpotool, qui vérifie la cohérence des objets de la stratégie de groupe sur les contrôleurs de domaines, vous obtiendrez des erreurs similaires si RPC est responsable.

Le fichier Dcpromo.log qui est généré lorsque vous promouvez un serveur Windows 2000 Server ou Windows Server® 2003 en tant que contrôleur de domaine à l’aide de l’outil Dcpromo peut également révéler des problèmes de RPC. Par exemple, si la promotion échoue, examinez le journal. Il se trouve dans le dossier %windir%\debug. Les erreurs répertoriées vous indiqueront que le service d’annuaire n’a pas répliqué la partition ou créé l’objet. Un code d’erreur se trouvera à la fin du message. Voici un exemple du type de message d’erreur que vous pourriez voir dans le fichier Dcpromo.log :

 
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)

Notez le code d’erreur 1722, qui survient quatre fois dans ce message et indique que le serveur RPC est indisponible. La figure 1 répertorie certains codes d’erreurs et leurs descriptions, mais vous en trouverez plusieurs autres à l’adresse msdn2.microsoft.com/ms681386.

Figure 1 Codes d’erreur et leurs descriptions

Résolution des erreurs RPC

À présent que vous avez vu comment détecter certaines des erreurs RPC, examinons quelques solutions.

Les clients Microsoft se connectent à l’Endpoint Mapper RPC sur le port 135. Ensuite, l’Endpoint Mapper indique au client le port d’écoute pour le service demandé. Les numéros de ports sont attribués de façon dynamique et sont compris entre 1024 et 65 535. Lorsque vous voyez des erreurs, par exemple 1753, cela vous indique qu’il n’y a plus de points de terminaison disponibles sur l’Endpoint Mapper, ce qui signifie que l’Endpoint Mapper RPC n’a pas pu utiliser un port supérieur à 1024 pour un service. J’explorerai ce sujet plus profondément un peu plus tard.

La première chose à faire est de vérifier l’état du service RPC sur le serveur. En fonction du type de rôle du serveur, le RPC et le service Localisateur RPC doivent avoir l’état répertorié à la figure 2. Si l’un des deux services n’est pas configuré comme illustré dans la figure, essayez d’ajuster l’état, redémarrez votre serveur, puis faites un test pour voir si votre problème est résolu.

Figure 2 État du service RPC

Assurez-vous que votre client peut envoyer une requête ping au serveur qui rencontre des problèmes de connectivité. Par exemple, si vous avez du mal à communiquer avec un serveur appelé DC1 dont l’adresse IP est 192.168.1.200, utilisez la commande suivante à l’invite de commande pour vérifier que le DNS résout correctement l’hôte DC1 :

Ping –a 192.168.1.200

Veillez à utiliser le commutateur -a avec l’adresse IP et non le nom d’hôte.

Si tout fonctionne, vous devriez obtenir une réponse de DC1 ressemblant à la réponse ping de la figure 3. Notez qu’au lieu de résoudre simplement l’adresse IP 192.168.1.200, la commande ping a également résolu le nom d’hôte dc1.contoso.com. Ceci confirme que la résolution de nom DNS fonctionne correctement et que la résolution de l’hôte dc1.contoso.com se fait exactement comme prévu.

Figure 3 Réponse ping

C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms

Assurez-vous également que le registre sur votre client Windows XP ou Windows 2000 contient au moins les quatre ClientProtocols répertoriés dans le volet de droite de la figure 4.

Figure 4** ClientProtocols RPC répertoriés dans le registre **

Si certaines entrées sont manquantes, ajoutez une nouvelle valeur de chaîne avec le nom et le type de données illustrés à la figure 4. Il y a, par défaut, une cinquième entrée appelée ncacn_nb_tcp, qui est utilisée pour identifier NetBIOS sur TCP comme famille de protocole pour le point de terminaison. En fonction de votre configuration, il se peut que cette entrée ne soit pas répertoriée sous ClientProtocols, auquel cas vous pouvez l’ajouter manuellement pour voir si elle résout les erreurs RPC.

Notez les clés répertoriées sous le dossier Rpc dans le volet gauche de la figure, à savoir ClientProtocols, NameService, NetBios et SecurityService. Si vous voyez une clé appelée Internet qui n’a pas de valeur, essayez de la supprimer et redémarrez votre ordinateur. Ceci aidera peut être à résoudre votre problème. Comme toujours, cependant, faites preuve de prudence lorsque vous modifiez le registre Windows.

Comme mentionné plus haut, RPC peut utiliser des ports compris entre 1024 et 65 535, donc vous devez vous assurer que ces ports ne sont pas bloqués par un pare-feu. La façon la plus simple de vous assurer qu’un port est ouvert consiste à utiliser l’outil Port Query. Il y a deux versions de cet outil : Une version ligne de commande (PortQry) et une version interface graphique (PortQueryUI).

PortQry peut être téléchargé dans le centre de téléchargement Microsoft. Pour plus d’informations, consultez l’article « Description de l’utilitaire de ligne de commande Portqry.exe ». Vous y trouverez de brèves descriptions de rapports d’états et d’exemples de commandes de PortQry à utiliser pour résoudre des problèmes. N’oubliez pas que vous pouvez aussi utiliser la version interface graphique, qui est beaucoup plus simple et peut être téléchargée à l’adresse go.microsoft.com/fwlink/?LinkId=73740.

Si vous utilisez Port Query, veillez à l’exécuter sur un ordinateur qui ne rencontre pas d’erreurs RPC et exécutez-le sur un ordinateur qui a des problèmes de RPC. Ainsi, si vous souhaitez vérifier que le port 135 (utilisé par le RPC Endpoint Mapper) est ouvert, utilisez PortQry à l’invite de commande comme ceci :

portqry -n [servername] -e 135

Que vous ayez utilisé PortQuery ou PortQueryUI, vous obtiendriez les résultats, comme ceci :

Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING

La dernière ligne montre que le port 135 est ouvert. Autrement, la dernière ligne aurait indiqué NOT LISTENING.

Pour vérifier une plage de ports, entrez la plage de numéros de port séparés par des virgules, comme ceci : « 135,1024-5000 ».

Autres solutions

Si vous avez testé toutes les astuces citées jusqu’à présent et que le problème n’est toujours pas résolu, il existe d’autres options. En fonction des problèmes spécifiques de votre environnement, vous pouvez essayer une des modifications du registre suivantes. (Attendez ! Avant de modifier le registre, vous devez vous assurer que vous avez sauvegardé votre système, en particulier le registre, pour que vous puissiez rétablir votre ordinateur à son état précédent si les choses tournent mal.)

L’une de ces options consiste à ajuster MaxUserPort pour spécifier le numéro de port le plus élevé que TCP peut attribuer lorsqu’une application demande un port d’utilisateur disponible au système. Par défaut, Windows Server 2003 définit la valeur MaxUserPort sur 5 000, ce qui signifie qu’il utilise 5 000 comme le numéro de port le plus élevé, même si l’entrée n’existe pas. En fonction de votre configuration, il se peut que cette entrée ne figure pas dans le registre, auquel cas vous pouvez l’ajouter dans l’emplacement indiqué à la figure 5.

Figure 5** Paramètre MaxUserPort dans le registre **

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000

Lorsque vous modifiez le registre, vous devez être conscient des autres effets secondaires potentiels, ce qui n’est pas toujours facile. La modification de cette entrée peut avoir un effet sur Microsoft Exchange Server si la valeur est définie en dessous de 50 000. Si Exchange Server Best Practices Analyzer (BPA) se rend compte que la valeur de la clé de registre MaxUserPort est inférieure à 50 000, il affiche un avertissement. Microsoft vous recommande de définir la valeur sur 60 000 pour éviter d’obtenir des avertissements de proxy NSPI (Name Service Provider Interface), tels que l’événement 9040. Pour plus d’informations, consultez le document Microsoft « La valeur MaxUserPort est trop faible ».

Vous pouvez également ajuster TcpMaxDataRetransmissions. Les paquets TCP attendent un accusé de réception de la part de la cible. Si aucun accusé ne leur parvient avant l’expiration du minuteur, les paquets sont retransmis, jusqu’aux heures de TcpMaxDataRetransmissions. La valeur par défaut pour ce paramètre est de 5 mais vous pouvez essayer une valeur de 4, ou même 3. N’utilisez pas une valeur inférieure à 3.

Si l’entrée de registre TcpMaxDataRetransmissions n’existe pas, vous pouvez l’ajouter au registre dans l’emplacement suivant, comme ceci :

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

Pour plus d’informations sur TcpMaxDataRetransmissions, consultez l’article 170359 de la base de connaissances Microsoft, « Comment modifier le délai TCP/IP de retransmission maximale ».

TcpTimedWaitDelay est une autre valeur de registre avec laquelle vous pouvez aussi faire des essais. Si un client utilise trop de ports, il est tout à fait possible qu’il vienne à manquer de ports avant que TCP/IP ne libère des connexions fermées. C’est parce que TCP/IP ne libère pas la connexion avant que deux MSL (Maximum Segment Lives) ne passent (c’est ce qu’on appelle un état Time-Wait). De plus, puisque chaque MSL est définie sur 120 secondes et que TCP/IP ne libère pas la connexion tant que deux MSL ne sont pas passés, il faut au moins 240 secondes (4 minutes) pour que TCP/IP libère une connexion fermée. Notez que ce problème connu dans Windows NT® a été corrigé avec un Service Pack ; par conséquent, il y a peu de chance que vous rencontriez ce problème maintenant. Cependant, Microsoft recommande d’ajuster ce paramètre comme l’une des solutions possibles pour résoudre les erreurs de RFC Endpoint Mapper, comme expliqué dans l’article de la base de connaissances « Comment faire pour corriger les erreurs du mappeur de point final RPC ».

TcpTimedWaitDelay est ajouté au registre dans l’emplacement suivant :

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

Pour plus d’informations sur TcpTimedWaitDelay, consultez l’article de la base de connaissances « Clients Windows NT à court de ports ». Bien que l’article ne recommande pas de nombres spécifiques, vous pourriez essayer de réduire TcpTimedWaitDelay à 60 (secondes) en décimal, ce qui correspond à 3c en hexadécimal.

Conclusion

Les erreurs RPC peuvent être la cause initiale de nombreuses erreurs de communication sur votre réseau. Heureusement, il existe plusieurs façons créatives de résoudre ces problèmes insaisissables. Certains des outils que j’ai suggérés ici sont intégrés, les autres sont disponibles dans le Kit de ressources Windows Server. Un grand nombre de ces outils sont répertoriés à la figure 6. Vous pouvez utiliser ces outils pour détecter la cause et l’emplacement des erreurs RPC, puis utiliser une des techniques répertoriées dans cet article pour résoudre les erreurs.

Figure 6 Outils de dépannage RPC

Zubair Alexander, MCSE, MCT et Microsoft MVP, possède SeattlePro Enterprises, une entreprise de formation et de consultation informatiques. Son expérience l’a amené à toucher à tous les aspects de l’éducation informatique : auteur, professeur d’université, consultant, ingénieur réseau, orateur public, architecte de sécurité, administrateur systèmes, éditeur technique et formateur. Vous pouvez contacter Zubair à l’adresse alexander@techgalaxy.net.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.