FuncionamientoSolución de problemas de errores de RPC

Zubair Alexander

Si ha trabajado con plataformas Windows Server a lo largo de los años, existe la posibilidad de que haya visto errores de llamadas a procedimiento remoto (RPC) una u otra vez. Se indica que el servidor RPC no está disponible, o que no hay más extremos disponibles o se ofrecen algunas otras advertencias enigmáticas. Si se confunde con estos mensajes, siga leyendo. Analizaré

algunos errores comunes, distintas técnicas que puede usar para identificar los errores de RPC que surgen y trataré algunas soluciones para resolver problemas específicos. Pero antes de hablar acerca de errores de RPC específicos y sus soluciones, hablemos un poco sobre la terminología RPC.

¿Qué es RPC?

RPC es un método de comunicación entre procesos (IPC) que los clientes y servidores usan para comunicarse entre sí. Simplemente, RPC lo usan los programas, normalmente en un equipo cliente, para ejecutar un programa en un equipo servidor. Por ejemplo, los clientes Microsoft® Outlook® se comunican con Microsoft Exchange Server mediante RPC. El equipo cliente envía un mensaje al equipo servidor con ciertos argumentos. El servidor responde al cliente con un mensaje que contiene los resultados del programa ejecutado.

En este proceso es esencial el extremo, el nombre, el puerto o el grupo de puertos de un equipo supervisado por un servidor para solicitudes entrantes de clientes. Más concretamente, se trata de una dirección específica de red de un proceso de servidor que se usa para RPC.

El Endpoint Mapper, que forma parte del subsistema RPC, es responsable de responder a las solicitudes de los clientes para resolver extremos dinámicos. En algunas situaciones, el Endpoint Mapper también es responsable de asignar dinámicamente extremos a los servidores.

Otro componente RPC importante es el servicio de ubicación, que mantiene una lista de servicios y servidores RPC en la red. Un cliente Windows® se conecta al controlador de dominio a través de puertos que usan el bloque de mensaje de servidor (SMB) (TCP 139 y 445) y buscan servicios o servidores RPC a través del servicio de ubicación.

La mayoría de los servicios integrados de Windows se comunican entre sí mediante RPC. Por ejemplo, los servicios de certificados, DCOM, FRS, MSMQ, MAPI y el servicio de réplica de Active Directory® usan RPC para la comunicación. Por lo tanto, si el servicio RPC no funciona correctamente en una red, puede experimentar muchos problemas de comunicación.

Errores de RPC

Ahora examinemos algunos de los errores que puede encontrar cuando falla el servicio RPC. (Esta no constituye en absoluto una lista completa).

Cuando falla el servicio de réplica de archivos (FRS), es posible que se trata del temido error "RPC no disponible". Si intenta asignar una unidad de disco, es posible que reciba el error "Acceso denegado". Cuando usa usuarios y equipos de Active Directory, es posible que aparezca el error que indica, "El dominio especificado no existe o no se pudo poner en contacto con él". Al iniciar una sesión en el dominio, puede obtener un error que afirma, "El sistema no puede iniciar sesión en este dominio porque falta la cuenta de equipo del sistema en su dominio principal o la contraseña en esa cuenta es incorrecta".

Cuando los clientes de Microsoft Outlook intentan comunicarse con Exchange Server, los errores de RPC pueden mostrar al cliente un error engañoso tal como, "Su información de inicio de sesión es incorrecta" u "Outlook no pudo iniciar sesión".

Además de estos errores, cuando el servicio RPC no está disponible, puede experimentar otros problemas. Por ejemplo, quizás no pueda examinar el dominio en Mis sitios de red o que pueda abrir el complemento Directiva de grupo.

Estas son sólo algunas de las ocasiones en las que quizás no esperaba que RPC genere problemas. Hay muchas más situaciones, y cuando esté trabajando con procesos remotos, los problemas de RPC pueden ser la raíz de sus dificultades. Así que, ¿cómo lo sabe con seguridad y, lo que es más importante, cómo encuentra el error preciso? Lo podemos averiguar.

Solución de problemas

Si sospecha que tiene problemas con el servicio RPC, hay varias herramientas que puede usar para diagnosticar los problemas.

Una opción es la herramienta Repadmin. Este programa suele usarse para supervisar y solucionar problemas de réplica de Active Directory, pero también se puede usar para solucionar problemas con el Endpoint Mapper de RPC. Para ejecutarlo, en el símbolo del sistema, escriba repadmin /bind. Si tiene problemas de RPC, quizás vea un mensaje similar a éste: "No hay más extremos disponibles desde el Endpoint Mapper". Ese es su primer indicio que el problema está relacionado con RPC.

Otra opción es usar la herramienta de diagnóstico de controlador de dominio (DCDiag), un programa de línea de comandos que permite diagnosticar los problemas con controladores de dominio. Si ve el error "El estado es 1722: el servidor RPC no está disponible", sabe que tiene un problema de RPC que la herramienta de diagnóstico de controlador de dominio acaba de descubrir.

A veces, cuando usa Ntdsutil (una herramienta de línea de comandos usada para administrar Active Directory y realizar numerosas tareas de mantenimiento) es posible que surjan errores de RPC si intenta conectarse al servidor. Probablemente verá uno de los errores más comunes tal como "No hay más extremos disponibles desde el Endpoint Mapper". Nuevamente, este es un indicio que quizás haya problemas con el servicio RPC. La herramienta Gpotool, que comprueba la coherencia de los objetos de directiva de grupo en controladores de dominio, también le dará errores semejantes si RPC es el responsable.

El registro Dcpromo.log, que se genera cuando promueve Windows 2000 Server o Windows Server® 2003 como controlador de dominio mediante la herramienta Dcpromo, también puede revelar problemas con RPC. Por ejemplo, si la promoción falla, examine el registro. Se encuentra en la carpeta %windir%\debug. Los errores enumerados indican algo como que el servicio de directorio falló al replicar la partición o falló al crear el objeto. Al final del mensaje habrá un código de error. Aquí se muestra un ejemplo del tipo de mensaje de error que quizás vea en 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)

Observe el código de error 1722, que ocurre cuatro veces en este mensaje e indica que el servidor RPC no está disponible. La figura 1 enumera algunos códigos de error y sus descripciones, pero encontrará muchos más en msdn2.microsoft.com/ms681386.

Figure 1 Códigos de error y sus descripciones

Resolución de errores de RPC

Ahora que ha visto cómo se pueden detectar algunos de los errores de RPC, analicemos algunas de las soluciones.

Los clientes de Microsoft se conectan al Endpoint Mapper de RPC en el puerto 135. A continuación, el Endpoint Mapper le dice al cliente en qué puerto se busca un servicio solicitado. Los números de puerto se asignan dinámicamente y pueden ser cualquier valor entre 1024 y 65.535. Cuando ve errores, tal como 1753, que le dicen que no hay más extremos disponibles desde el Endpoint Mapper, esto significa que el Endpoint Mapper de RPC no pudo usar un puerto mayor que 1024 para un servicio. Analizaré este tema con mayor profundidad más adelante.

Lo primero que debe hacer es comprobar el estado del servicio RPC en el servidor. Según el tipo de función de servidor, el servicio RPC y el servicio de ubicación de RPC deberían tener el estado que se muestra en la figura 2. Si cualquiera de los dos servicios no está configurado como se muestra en la figura, intente ajustar el estado, rearranque el servidor y, a continuación, realice una prueba para ver si se resuelve el problema.

Figure 2 Estado del servicio RPC

Compruebe que el cliente puede hacer ping correctamente al servidor que tiene problemas de conectividad. Por ejemplo, si tiene problemas para comunicarse con un servidor llamado DC1 cuya dirección IP es 192.168.1.200, use el siguiente comando en el símbolo del sistema para comprobar que el DNS resuelve correctamente el host DC1:

Ping –a 192.168.1.200

Asegúrese de usar el parámetro -a con la dirección IP, no con el nombre de host.

Si todo funciona bien, debería obtener una respuesta de DC1 semejante a la respuesta de ping de la figura 3. Observe que en vez de resolver simplemente la dirección IP 192.168.1.200, Ping también resolvió el nombre de host dc1.contoso.com. Esto confirma que esa resolución de nombres DNS funciona correctamente y resuelve el host dc1.contoso.com exactamente como se esperaba.

Figure 3 Respuesta del 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

También debe asegurar que el registro en su cliente Windows XP o Windows 2000 contiene por lo menos los cuatro ClientProtocols que se muestran en el panel derecho de la figura 4.

Figura 4** ClientProtocols de RPC mostrados en el Registro **

Si falta cualquiera de las entradas, agregue un nuevo valor de cadena con el nombre y tipo de datos que se muestran en la figura 4. De forma predeterminada, hay una quinta entrada llamada ncacn_nb_tcp, que se usa para identificar NetBIOS sobre TCP como la familia de protocolo para el extremo. Según la configuración, quizás no se incluya esa entrada en una lista bajo ClientProtocols; puede agregarla manualmente para ver si resuelve los errores de RPC.

Observe las claves incluidas en una lista bajo la carpeta Rpc en el panel izquierdo de la figura, concretamente ClientProtocols, NameService, NetBIOS y SecurityService. Si logra ver una clave llamada Internet que no tiene valores, intente quitar la clave y reiniciar el equipo. Quizás esto ayude a resolver el problema. No obstante, como siempre, asegúrese de prestar atención cuando modifica el Registro de Windows.

Como mencioné anteriormente, RPC puede usar puertos entre 1024 y 65.535, así que necesita asegurarse de que estos puertos no estén bloqueados por un firewall. La manera más sencilla de asegurarse de que un puerto está abierto es usar la herramienta Port Query. Esta herramienta viene en dos versiones: una versión de línea de comandos (PortQry) y una versión GUI (PortQueryUI).

PortQry está disponible para la descarga en el Centro de descarga de Microsoft. Para obtener información adicional, consulte el artículo "Descripción de la utilidad de línea de comandos Portqry.exe". Allí encontrará breves descripciones de informes de estado de PortQry y ejemplos de comandos usados para resolver problemas. Tenga presente que también puede usar la versión GUI, que es mucho más sencilla y que se puede descargar desde la dirección go.microsoft.com/fwlink/?LinkId=73740.

Cuando usa Port Query, debe asegurarse de ejecutarlo en un equipo que no experimenta errores de RPC y ejecutarlo hacia un equipo que tiene problemas con RPC. Por ejemplo, si quiere comprobar que el puerto 135, que usa el Endpoint Mapper de RPC, está abierto, use PortQry en el símbolo del sistema de la siguiente manera:

portqry -n [servername] -e 135

Si usa PortQuery o PortQueryUI, obtendrá resultados similares a los siguientes:

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 última línea muestra que el puerto 135 está abierto. De lo contrario, la última línea habría indicado NOT LISTENING.

Para comprobar un intervalo de puertos, escriba el rango de números de puerto delimitados por comas, como por ejemplo: "135,1024-5000".

Soluciones adicionales

Si ha intentado todos los trucos descritos hasta ahora y el problema todavía no está resuelto, hay algunas opciones adicionales disponibles. En función de los problemas específicos en su entorno, quizás desee intentar con alguna de las siguientes modificaciones al Registro. ¡Espere! Antes de realizar cualquier cambio al Registro, es importante haber realizado copias de seguridad del sistema, especialmente el Registro. De este modo, si se produce errores tendrá la capacidad de restaurar el equipo a su estado anterior.

Una opción es ajustar MaxUserPort para especificar el mayor número de puerto que TCP puede asignar cuando una aplicación solicita al sistema un puerto de usuario disponible. De forma predeterminada, Windows Server 2003 establece el valor de MaxUserPort en 5000, lo que significa que usa 5000 como el mayor número de puerto, incluso si la entrada no existe. En función de la configuración, quizás no tiene esta entrada en el registro, en cuyo caso puede agregarla a la ubicación que se muestra en la figura 5.

Figura 5** Configuración de MaxUserPort en el Registro **

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

Al modificar el Registro, debe conocer cualquier otro efecto secundario posible, lo que no siempre es fácil. Modificar esta entrada puede afectar a Microsoft Exchange Server si el valor se establece debajo de 50.000. Si la herramienta Best Practices Analyzer (BPA) de Exchange Server encuentra que el valor de la clave de Registro MaxUserPort es menor que 50.000, muestra una advertencia. Microsoft recomienda establecer el valor en 60.000; de otro modo puede causar advertencias de proxy de la interfaz del proveedor de servicio de nombres (NSPI), tales como el evento 9040. Para obtener más información, consulte el documento de Microsoft "Valor de MaxUserPort demasiado bajo".

También puede ajustar TcpMaxDataRetransmissions. Los paquetes TCP esperan una confirmación del extremo receptor. Si no existe confirmación antes de que expire el temporizador, entonces los paquetes se retransmiten hasta TcpMaxDataRetransmissions veces. El valor predeterminado para este parámetro es 5 pero quizás desee intentar con un valor de 4 o incluso 3. No use un valor inferior a 3.

Si la entrada de Registro TcpMaxDataRetransmissions no existe, la puede agregar en la siguiente ubicación, tal como se indica a continuación:

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

Para obtener más información sobre TcpMaxDataRetransmissions, consulte el artículo de Microsoft Knowledge Base 170359, "Cómo modificar el tiempo de espera máximo de retransmisión de TCP/IP".

Otro valor de registro con el que quizás desee experimentar es TcpTimedWaitDelay. Si un cliente usa demasiados puertos, es bastante posible que se quede sin puertos antes de que TCP/IP libere las conexiones cerradas. Esto se debe a que TCP/IP no libera la conexión hasta que pasen dos vidas máximas de segmento (MSL); esto se conoce como estado de tiempo de espera. Más aún, dado que cada MSL se define en 120 segundos y TCP/IP no libera la conexión hasta que pasan dos MSL, TCP/IP emplea 240 segundos (4 minutos) para liberar una conexión cerrada. Tenga en cuenta que este fue un problema conocido en Windows NT® que se corrigió con un Service Pack; como resultado, es mucho menos probable que hoy experimente este problema. Sin embargo, Microsoft recomienda ajustar esta configuración como una de las soluciones posibles para resolver los errores del Endpoint Mapper de RPC, tal como se explica en el artículo de Microsoft Knowledge Base "Cómo solucionar problemas con los errores del Endpoint Mapper de RPC".

TcpTimedWaitDelay se agrega al Registro en la siguiente ubicación:

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

Para obtener más información acerca de TcpTimedWaitDelay, consulte el artículo de Microsoft Knowledge Base "Los clientes de Windows NT se quedan sin puertos". Aunque el artículo no recomienda ningún número específico, quizás puede intentar reducir TcpTimedWaitDelay a 60 (segundos) en decimal, que es 3c en hexadecimal.

Conclusión

Los errores de RPC pueden ser la raíz de numerosos errores de comunicación en la red. Por suerte, existen varias maneras creativas con las que se pueden solucionar estos problemas esquivos. Algunas de las herramientas que he sugerido aquí están integradas, mientras que otras se encuentran disponibles en el kit de recursos de Windows Server. Muchas se incluyen en la lista de la figura 6. Puede usar estas herramientas para detectar la causa y ubicación de los errores de RPC y, a continuación, usar alguna de las técnicas descritas en este artículo para resolver los errores.

Figure 6 Herramientas de solución de problemas de RPC

Zubair Alexander, MCSE, MCT y Microsoft MVP, es propietario de SeattlePro Enterprises, una compañía de aprendizaje y consultoría de TI. Su experiencia cubre el espectro completo de la educación de TI: autor, instructor universitario, consultor, ingeniero en redes, orador, arquitecto de seguridad, administrador de sistemas, editor técnico y entrenador. Puede ponerse en contacto con Zubair en la dirección alexander@techgalaxy.net.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.