Consejos útiles

Solución de problemas de conexiones HTTP RPC

Pin
Send
Share
Send
Send


Como sabe, Outlook 2007/2010 puede conectarse al servidor de Microsoft Exchange utilizando los protocolos MAPI y HTTPS. El primero está diseñado para funcionar dentro de la red corporativa, el segundo para conexiones remotas. Outlook selecciona el protocolo de conexión del ancho de banda del canal, y la medición no se realiza realmente, y la configuración se toma del adaptador de red, si la velocidad es inferior a 128K, la conexión se considera lenta y la conexión se establecerá a través de HTTPS. También si se pierde la conexión al servidor a través de MAPI, Outlook intentará establecer una conexión a través de HTTPS. Y si el servidor está configurado para la autenticación básica, pueden aparecer ventanas de entrada de contraseña, lo que es muy molesto para los usuarios.

¿Cómo evitar esto? Normalmente, Outlook se configura mediante políticas de grupo mediante la "Plantilla de política de grupo de Outlook 2010". Pero la configuración de Outlook en cualquier lugar es muy pobre y no se puede cambiar la lógica del trabajo de Outlook con una plantilla estándar. Microsoft ofrece la siguiente solución.

Debe aplicar plantillas administrativas adicionales a las políticas que se describen a continuación.

En principio, no tiene sentido usar HTTPS dentro de la red corporativa, solo la configuración del servidor se vuelve más complicada y pueden aparecer ventanas de autorización.

Verificación de prerrequisitos

Para establecer conexiones RPC a través de HTTP, se deben cumplir una serie de requisitos previos, y el proceso de diagnóstico primero debe verificar que se cumplan estas condiciones. El primero de ellos es que Outlook 2003 y Windows XP Service Pack 2 (SP2) o XP SP1 deben instalarse en el equipo cliente con el programa de corrección correspondiente, 331320, que elimina los problemas con los retrasos del cliente. Este programa se describe con más detalle en el artículo de Microsoft "Outlook 2003 funciona lentamente o deja de responder cuando está conectado a Exchange Server 2003 a través de HTTP" en http://support.microsoft.com/?kb>

Para verificar que la máquina tenga la versión correcta del programa de corrección, puede verificar la versión del archivo rpcrt4.dll en el directorio \% windir% system32 en la computadora cliente. Debería encontrar el archivo rpcrt4.dll en el Explorador de Windows, haga clic derecho sobre él y seleccione Propiedades. En el cuadro de diálogo Propiedades, haga clic en la pestaña Versión y seleccione Versión del archivo en la lista Nombre del elemento. Se requiere la versión 5.1.2600.1142 o posterior.

El segundo requisito previo: el servidor proxy RPC debe ejecutarse en Windows Server 2003, así como los controladores de dominio (DC) o los servidores del Catálogo global (GC) que el servidor proxy RPC utiliza para autenticar la conexión del cliente. Cualquier servidor GC al que se pueda redirigir al usuario también debería funcionar con Windows 2003. El servidor interno de Exchange (back-end) y cualquier otro servidor de Exchange (por ejemplo, servidores de carpetas públicas) también deberían funcionar en Windows 2003 y Exchange 2003. Por lo tanto La regla más simple es aprovechar Windows 2003 y Exchange 2003 en toda su infraestructura.

Verificación del tipo de conexión

El propósito del método RPC sobre HTTP es simplificar la organización de las conexiones entre Outlook 2003 y Exchange 2003 para el usuario final. Esto significa que el usuario no debe notar la diferencia entre la conexión RPC sobre MAPI y la conexión RPC sobre HTTP. Por lo tanto, si Outlook 2003 no puede establecer una conexión RPC a través de HTTP, el programa cambia automáticamente a TCP / IP e intenta establecer una conexión RPC a través de MAPI.

Este método es conveniente cuando se opera Exchange en modo normal, pero puede ser un obstáculo molesto cuando intenta organizar el acceso RPC por HTTP. El proceso de cambio de protocolo es completamente invisible y no está claro si la conexión RPC a través de HTTP está activada o después de su falla, la conexión RPC a través de MAPI está activada.

Existe una técnica simple mediante la cual un usuario de una computadora cliente con Outlook 2003 puede determinar cómo conectarse al servidor de Exchange. Mientras mantiene presionada la tecla Ctrl, debe hacer clic con el botón derecho en el icono de Outlook en el panel del sistema y seleccionar Estado de conexión. Aparece el cuadro de diálogo Estado de la conexión, que indica el tipo de conexión que se está utilizando actualmente.

Para configurar una conexión RPC a través de HTTP, puede deshabilitar el cambio automático de protocolo. Para hacer esto, debe editar el registro en el equipo cliente con Outlook 2003. En la sección HKEY_CURRENT_ USERSoftwareMicrosoftOffice11.0RPC, cree el parámetro DisableRpcTcpFallback y configúrelo en el valor DWORD 1 para bloquear la conmutación RPC / TCP. Después de asegurarse de que el sistema funciona correctamente, debe habilitar el conmutador estableciendo el parámetro DisableRpcTcpFallback en 0.

Comprobando la configuración del cliente

Microsoft ha lanzado dos versiones de RPC a través de HTTP - Versión 1 y Versión 2 - con varias capacidades. Outlook 2003 usa RPC sobre HTTP Versión 2, que requiere que el cliente trabaje con Secure Sockets Layer (SSL) y la conexión es autenticada por un servidor proxy RPC. Por lo tanto, debe verificar la configuración del perfil del cliente MAPI, que debe configurarse para usar SSL, e identificar correctamente el servidor proxy RPC.

Para verificar la configuración, abra Outlook 2003. En el menú Herramientas, seleccione el elemento Cuentas de correo electrónico. Después de asegurarse de que Ver o cambiar las cuentas de correo electrónico existentes esté seleccionado, haga clic en el botón Siguiente. Luego, debe seleccionar la cuenta adecuada y hacer clic en los botones Cambiar, Más configuraciones. Aparece el cuadro de diálogo Microsoft Exchange Server en el que debe ir a la pestaña Conexión y seleccionar la casilla de verificación Conectar a mi buzón de Exchange usando HTTP.

Luego haga clic en Configuración de proxy de Exchange para abrir el cuadro de diálogo que se muestra en la pantalla 1. Esto debe verificarse Autenticar mutuamente la sesión cuando se conecta con SSL. Al marcar la casilla, debe agregar el prefijo msstd: al nombre del servidor proxy RPC en el campo Nombre principal para el servidor proxy.

Pantalla 1. Verificación de la configuración del cliente

Tenga en cuenta que el primer punto de contacto para el cliente de Outlook puede ser un servidor proxy HTTP local, por ejemplo, Microsoft Internet Security and Acceleration (ISA) Server 2000. En este caso, asegúrese de que este servidor (y no el servidor proxy RPC) aparezca en el cuadro de diálogo Ventana de configuración de proxy de Exchange. Además, debe asegurarse de que el servidor proxy HTTP local enrute correctamente las conexiones al servidor proxy RPC. Para ISA Server 2000, puede verificar las conexiones examinando los archivos de registro.

Debajo del campo Nombre principal para el servidor proxy está la casilla En redes rápidas, conéctese usando HTTP primero, luego conéctese usando TCP / IP ("En redes rápidas, primero establezca una conexión usando HTTP, luego intente conectarse usando TCP / IP") y la casilla de verificación Encendido lento redes, conéctese usando HTTP primero, luego conéctese usando TCP / IP ("En redes lentas, primero establezca una conexión usando HTTP, luego conéctese usando TCP / IP"). Por defecto, estas casillas de verificación están establecidas para los interruptores descritos anteriormente. Las conexiones lentas son aquellas con una velocidad de transferencia de datos de no más de 115 Kbps.

Además de configurar el perfil MAPI del cliente, debe asegurarse de que el cliente Outlook 2003 pueda establecer una conexión SSL con el servidor proxy RPC. Puede hacerlo abriendo Microsoft Internet Explorer (IE) y estableciendo una conexión https: // RpcProxyServer / RPC, donde RpcProxyServer es el nombre del servidor proxy RPC. Error HTTP 403.2 Prohibido: el mensaje de error de acceso de lectura denegado significa que se ha establecido la conexión al Directorio virtual RPC en Microsoft IIS en el servidor proxy RPC. El mensaje de error se muestra porque, aunque el cliente tiene los permisos necesarios para conectarse al Directorio virtual RPC, no tiene suficientes permisos de lectura en este directorio.

Comprobando la configuración del servidor

El artículo "Acceso remoto a Exchange 2003 a través de canales HTTP" describe la configuración básica del servidor para el acceso RPC a través de HTTP, por lo que no la repetiré. En su lugar, veremos los problemas del servidor principal que interfieren con el funcionamiento correcto de las conexiones RPC a través de http.

  • Valor de parámetro ValidPorts no válido. El parámetro ValidPorts en la sección de servidor proxy RPC HKEY_LOCAL_MACHINESOFTWAREM de Microsoft RpcRpcProxy debe especificar todos los servidores de Exchange, controladores de dominio y servidores GC con los que se comunica el servidor proxy RPC. Si el script RPCHTTP_Setup.vbs, que se puede obtener de los Servicios de soporte técnico de Microsoft (PSS), se usa para organizar las conexiones RPC a través de HTTP, entonces todos los nombres de host y puerto deben ser correctos. Sin embargo, si no se utilizó RPCHTTP_Setup.vbs, entonces debe verificar los nombres de host y puerto. Además, debe asegurarse de que el servidor proxy RPC proporcione la traducción de todos los nombres especificados en el elemento ValidPorts y de que el certificado proporcionado por el servidor proxy RPC sea válido.
  • Servidor interno de Exchange configurado incorrectamente. La configuración de registro necesaria para el servidor interno de Exchange se configura automáticamente durante la instalación de Exchange 2003, por lo que no debería haber problemas con la configuración. Pero la configuración del puerto del servidor interno de Exchange debe ser coherente con la configuración del puerto del elemento proxy ValidPorts RPC. Además, debe recordar que ha aparecido una nueva propiedad en Exchange 2003 SP1 que le permite configurar el servidor de Exchange como un servidor proxy RPC. Este servidor multipropósito se llama servidor externo RPC-HTTP. Por lo tanto, si hay un servidor proxy RPC separado, se debe seleccionar el parámetro del servidor de fondo RPC-HTTP (y no el parámetro del servidor de front-end RPC-HTTP). El acceso a la nueva propiedad se puede obtener a través del Administrador del sistema de Exchange (ESM). Simplemente haga clic derecho en el servidor de Exchange, seleccione Propiedades y haga clic en la pestaña RPC-HTTP.
  • Configuración incorrecta de controladores de dominio o servidores GC. Si el servidor proxy RPC establece conexiones con cualquier servidor DC o GC, entonces el parámetro Secuencias de protocolo de interfaz NSPI debe agregarse manualmente a la sección de registro HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters de controladores de dominio o servidores GC. Este parámetro adicional a menudo es una fuente de errores, por lo que debe verificar su corrección en cada servidor DC y GC. Además, debe asegurarse de que la configuración del puerto de los servidores GC sea correcta y coherente con la configuración del puerto en el servidor proxy ValidPorts RPC.

Si no se estableció la conexión y no hay errores en la configuración del servidor, puede intentar reiniciar el servidor. Reiniciar es un truco primitivo, pero a veces ayuda.

Comprobación de conexión

Debe asegurarse de que la comunicación entre el servidor proxy RPC, el servidor interno de Exchange y los servidores GC sea posible. La herramienta más poderosa para diagnosticar conexiones RPC a través de HTTP es la utilidad RPC Ping del Kit de recursos de Microsoft Windows Server 2003. Outlook 2003 también tiene características de rastreo RPC que pueden ayudarlo a solucionar problemas de canales de comunicación.

RPC Ping. RPC Ping es una herramienta compleja con muchas claves y calificadores, con la que puede averiguar si las solicitudes RPC logran un objetivo específico (por ejemplo, un servidor) a través de una conexión HTTP especificada. Para obtener información útil sobre RPC Ping, consulte el artículo de Microsoft "Cómo usar la utilidad RPC Ping para solucionar problemas de conectividad con el intercambio por la función de Internet en Outlook 2003" (http://support.microsoft.com/?kb>

Usando RPC Ping, puede ejecutar varias pruebas. En particular, confirme que el cliente de Outlook puede establecer una conexión RPC a través de HTTP con el servidor proxy RPC. Para hacer esto, use el comando

El comando se imprime en varias líneas, pero en la ventana de comandos se debe ingresar en una. Lo mismo se aplica a los otros comandos de varias líneas en este artículo. El equipo es complejo, así que considere cada uno de sus argumentos.

  • El argumento -t especifica una de las tres secuencias de protocolo: ncacn_http, ncacn_ip_tcp o ncacn_np. Para conexiones RPC sobre HTTP, se debe especificar ncacn_http.
  • El argumento -s especifica el servidor interno de Exchange, ExchangeServer es el nombre del servidor.
  • El argumento -o RpcProxy = indica el servidor proxy RPC, ProxyServer es el nombre del servidor.
  • El argumento -P especifica la cuenta utilizada para autenticar el servidor proxy RPC. Puede proporcionar la información necesaria en uno de dos formatos: "nombre de usuario, dominio, *" (si no se requiere una contraseña) o "nombre de usuario, dominio, contraseña" (si se requiere una contraseña), donde nombre de usuario es el nombre de usuario, dominio es el nombre de dominio y contraseña - contraseña de usuario.
  • El argumento -I especifica la cuenta que se usa para autenticar con el servidor de Exchange. El formato "nombre de usuario, dominio, *" o "nombre de usuario, dominio, contraseña" también se utiliza para transmitir la información necesaria.
  • El argumento -H especifica el esquema de autenticación del servidor proxy RPC. Puede especificar 1 para el tipo de autenticación NT LAN Manager (NTLM) o 2 para el tipo Básico. En este ejemplo, indiqué 1 porque probé una conexión de red con NTLM.
  • El argumento -u especifica el proveedor de soporte de seguridad (SSP). Puede especificar 9 (Negociar), 10 (NTLM), 14 (Canal seguro) o 16 (Kerberos). Como utilicé el esquema de autenticación NTLM, se seleccionó 10 para este argumento.
  • El argumento -a especifica el nivel de autenticación que se utiliza para conectarse al servidor proxy RPC. Los valores posibles son conectar, llamar, pkt, integridad o privacidad. En este ejemplo, se especifica el valor connect, ya que probé la conexión al servicio.
  • El argumento -F especifica si se deben usar banderas de autenticación RPC externas a través de HTTP. Puede especificar 2 (sin bandera SSL) o 3 (use la bandera SSL). En este ejemplo, he especificado 3, porque se usa la conexión SSL.
  • El argumento -v indica el modo de registro. Puede seleccionar el modo mínimo (1), el modo normal (2) o el registro completo (3). Recomiendo el modo completo, ya que puede recopilar la mayor cantidad de información.
  • El argumento -E restringe la prueba de comunicación solo al servidor proxy RPC. Tenga en cuenta que el argumento -e también existe, por lo que el caso es significativo.
  • El argumento -R especifica el servidor proxy HTTP local, HttpProxy es el nombre del servidor. Si no se utilizará el servidor proxy HTTP local, debe especificar ninguno en lugar del nombre del servidor.

La Figura 2 muestra un ejemplo de ejecución de este comando. Tenga en cuenta el mensaje de error

Error 12029 devuelto en WinHttpSendRequest. Ping falló. Indica que el canal de comunicación entre el cliente Outlook 2003 y el servidor proxy RPC está defectuoso. El artículo "Cómo usar la utilidad RPC Ping para solucionar problemas de conectividad con la función Exchange a través de Internet en Outlook 2003" proporciona una tabla que enumera los mensajes de error RPC Ping y las posibles causas de estos errores.

Si el mensaje Pinging completado correctamente aparece en la pantalla después de ejecutar este comando, el servidor proxy RPC respondió a la solicitud y la conexión entre el cliente y el servidor proxy RPC está bien. En este caso, debe verificar inmediatamente la conexión entre el servidor proxy RPC y el servidor interno de Exchange. Para realizar la prueba, debe usar el comando

Tenga en cuenta la ausencia del interruptor -E. Falta la clave, porque la prueba de comunicación no debe limitarse al servidor proxy RPC.

Pantalla 2. Un ejemplo del funcionamiento del comando RPC Ping

Para enrutar RPC Ping a un punto final de Exchange Store, use el comando

El modificador -f apareció en el comando. Indica una interfaz de prueba de eco, donde Uuid es el Identificador Único Universal (UUID) y Ver es el número de versión de la interfaz. Los UUID proporcionan conexiones de otras fuentes. En este caso, el UUID es a4f1db00-ca47-1067-b31f-00dd010662d. Si no se especifica ningún número de versión, RPC Ping usa la versión 1.0.

RPC Ping es una poderosa herramienta de diagnóstico con una sintaxis de comando muy compleja. Si aprende a usar correctamente las teclas necesarias, trabajar con RPC Ping es bastante simple, y al usar la utilidad puede obtener mucha información útil sobre las causas de los problemas.

Seguimiento RPC de Outlook 2003. Para activar las funciones básicas del seguimiento RPC de Outlook 2003, abra Outlook 2003 y seleccione el elemento Opciones en el menú Herramientas. En la pestaña Otros, haga clic en el botón Opciones avanzadas y seleccione la casilla de verificación Habilitar el registro de correo (solución de problemas). Luego debe cerrar Outlook 2003, esperar aproximadamente un minuto y volver a abrir el programa. A partir de ahora, Outlook 2003 generará eventos y los escribirá en el registro de la aplicación en la computadora cliente.

Puede ampliar las funciones de rastreo RPC creando varias configuraciones de registro y reemplazando algunas DLL en la computadora cliente. En el registro, debe crear los elementos RpcTraceEnable, RpcStackTrace, RpcDumpToFile y RpcOutputDir en la sección HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0OutlookRPC. En el directorio Program FilesCommon FilesSystemMSMAPI1033, reemplace los archivos emsmdb32.dll, emsabp32.dll, emsui32.dll y msmapi32.dll con versiones especiales de estas DLL. Para obtener más información sobre estos cambios, consulte PSS.

Culpables típicos

RPC sobre HTTP que funciona como un protocolo de transporte entre Outlook 2003 y Exchange 2003 es un proceso complejo. Básicamente, las dificultades están ocultas para el usuario, pero el proceso no siempre transcurre sin problemas. En las primeras etapas de implementación, surgen problemas debido a errores de configuración relativamente simples. La información incorrecta del servidor, la configuración de registro no válida y los nombres no convertibles son causas comunes de mal funcionamiento. Los problemas que surgen en un sistema en ejecución son más difíciles de diagnosticar. En tales circunstancias, los problemas surgen con mayor frecuencia debido a la falla de los componentes de la infraestructura. Un análisis de las causas típicas de mal funcionamiento discutido en este artículo ayudará a simplificar y acelerar la resolución de problemas.

Kieran McCorry ([email protected] ) - Consultor en jefe, HP Consulting and Integration Technology Group, opera en Irlanda. Es coautor de Microsoft Exchange 2000 Infrastructure Design (Digital Press).

Comparta material con colegas y amigos.

Pin
Send
Share
Send
Send