Dentro de SharePointSolución de problemas de integración de mensajería

Pav Cherny

Descarga de código disponible en: SharePoint2008_08.exe(416 KB)

Contenido

Enfoque general de solución de problemas
Arquitectura de mensajería de SharePoint
Obtención de información de diagnóstico
Transferencia de mensajes salientes
Transferencia de mensajes entrantes
Administración de directorios
Conclusión

En un entorno de SharePoint bien diseñado, los trabajadores de la información no tienen que cambiar sus hábitos de comunicación ni sus rutinas de trabajo para poder colaborar. SharePoint puede entregar documentos e información adicional, como alertas y avisos, directamente en sus buzones, en lugar de comprobar manualmente los sitios de colaboración de forma continua.

Los usuarios también pueden participar en flujos de trabajo respondiendo a estos mensajes o enviando nuevos elementos como mensajes de correo electrónico para documentar las bibliotecas y las listas.

Sin embargo, la integración de SharePoint® en un entorno de mensajería seguro supone desafíos y deja un espacio abierto para que los componentes que no pertenecen a SharePoint repercutan en la colaboración basada en SharePoint. El desafío es aislar y eliminar de manera eficaz las causas principales de los problemas en el entorno integrado allí donde sucedan.

En esta columna, analizo la integración de mensajería de SharePoint en función de una estrategia probada de solución de problemas que proporciona resultados rápidos. La idea es localizar de manera eficaz el punto problemático y luego acercarse con pasos para la solución de problemas más detallados y orientados.

En una organización grande, esta investigación por fases quizás signifique pasar el caso a otro especialista después de un análisis inicial, especialmente si el problema está relacionado con componentes que no pertenecen a SharePoint. Por otra parte, en organizaciones pequeñas y medianas, no es raro que un solo administrador de TI tenga que solucionar problemas de todos los sistemas directamente implicados, lo que resalta aún más la necesidad de usar enfoques estructurados.

Para que esta columna siga orientada a la práctica, uso un entorno de pruebas con Active Directory®, Exchange Server 2007 y WSS 3.0. Las instrucciones detalladas para crear este entorno de pruebas así como las herramientas de solución de problemas que se tratan en esta columna se encuentran en el material complementario, disponible en la sección Descargas de código del sitio web de TechNet Magazine.

Enfoque general de solución de problemas

La solución de problemas de integración de mensajería de SharePoint requiere un enfoque muy estructurado, quizás aún más que en otros escenarios de interoperabilidad. Hay varios factores que complican este intento.

Obviamente se debe tratar con tecnologías complejas, y mientras se lucha con los problemas de transferencia de mensajes, las conversiones de formato de mensajes, los aspectos de seguridad y los problemas de administración de directorios, se encontrará con que algunos mensajes de error de SharePoint pueden ser confusos. Los grupos de noticias de Internet están colmados de temas de discusión y sugerencias no resueltas que pueden llevarle por un camino equivocado, por ejemplo ejecutar todas las aplicaciones web bajo la identidad del grupo de aplicaciones de la administración central de SharePoint para lograr que la integración de mensajería funcione.

Pero también hay aspectos positivos. SharePoint es muy flexible. De hecho, puede ofrecer información detallada sobre solución de problemas si se sabe dónde consultar. Con unos cuantos scripts básicos se puede mejorar mucho la eficacia de la solución de problemas.

El primer objetivo de la solución de problemas es comprender el problema particular que se está tratado. Se debe identificar dónde reside el problema y qué componentes implica. También se podría reproducir el problema en configuraciones del sistema diferentes y estudiar los archivos de registro basados en texto y los registros de eventos de Windows®. Pero esto puede ser complicado dado que algunos problemas sólo ocurren esporádicamente. Además, cuanto mejor se logre reproducir un problema, más rápido se podrá identificar y eliminar su causa principal. Otro objetivo importante, que a menudo se pasa por alto, es documentar todos los cambios de configuración y correcciones y garantizar que se aplican en todos los sistemas relevantes del entorno, por ejemplo en todos los servidores front-end de una granja de servidores web.

Arquitectura de mensajería de SharePoint

Siempre que se enfrenta con un problema relacionado con la integración de mensajería, se recomienda en primer lugar tomar una taza de café o de té y, a continuación, revisar la arquitectura de integración de mensajería de SharePoint antes de entrar en la solución de problemas. De lo contrario quizás termine corrigiendo un problema o componente equivocado. Por ejemplo, un error "Acceso denegado", que le impide crear un objeto de contacto en Active Directory no es necesariamente un indicador de que necesita corregir permisos de acceso en Active Directory, como verá más adelante.

En todo caso, es esencial entender la función de cada componente que participa en la integración de mensajería y la interacción mutua de los componentes individuales. Si observa la figura 1 verá los componentes importantes en un escenario de conectividad SharePoint-Exchange, que trataremos con todo detalle en las secciones siguientes.

Figura 1Arquitectura de integración de mensajería de SharePoint (haga clic en la imagen para ampliarla)

Obtención de información de diagnóstico

Una de las herramientas más importantes de solución de problemas es la información de diagnóstico confiable. El clásico de todos los tiempos es el registro de eventos de Windows. Entre otras cosas, con Administración central de SharePoint se puede controlar el nivel de detalle con el que SharePoint escribe en el registro de eventos de Windows de los servidores web (en la página Operaciones, en Crear registros e informes, hacer clic en Registro de diagnósticos). Se puede especificar el evento menos crítico que desea incorporar al registro de eventos y al registro de seguimiento. El registro de seguimiento (ubicado de forma predeterminada en %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) es muy útil si se busca información de bajo nivel, pero se puede llenar muy rápido, por lo que esta característica se debe usar con moderación.

Otra manera de obtener información de diagnóstico es habilitar la depuración de la aplicación web afectada, por medio de la configuración del archivo web.config correspondiente, tal y como se describe en el material complementario, en Web Application Config.pdf. SharePoint muestra información de seguimiento detallada directamente en la interfaz de usuario. Una ventaja de este enfoque es que se puede ver la información de errores pertinente sin tener que analizar megabytes de datos de seguimiento. Una desventaja es que se debe cambiar la configuración del sistema de la aplicación web. No se olvide de realizar copias de seguridad del archivo web.config original y de restaurar después la configuración original cuando haya terminado de solucionar los problemas.

También se puede configurar el servicio SMTP para escribir información de procesamiento detallada en el archivo de registro del protocolo SMTP (en Administrador de IIS, en la ficha General, seleccionar la casilla Habilitar registro). Asegúrese de instalar el módulo Registro ODBC junto con la característica Servicio SMTP tal y como se describe en SharePoint Messaging Integration.pdf que se encuentra en el material complementario, incluso si no planea usar Registro ODBC. De otro modo, el servicio SMTP no escribirá el archivo de registro del protocolo. De forma predeterminada, el archivo de registro del protocolo SMTP se encuentra en %SystemRoot%\System32\LogFiles\SmtpSvc1. Es un archivo de texto que permite analizar con todo detalle la comunicación SMTP y determinar si un mensaje sale del servidor de SharePoint.

También puede habilitar el registro del protocolo en el servidor de transporte de concentradores que se comunica con el servicio SMTP, en la configuración de Conector de envío y Conector de recepción (consulte SharePoint Messaging Integration.pdf). Puede usar muchas otras herramientas para seguir la ruta que toman los mensajes en un entorno de Exchange Server 2007 a través de servidores de transporte de concentradores y servidores de buzón, tales como Seguimiento de mensajes, Visor de colas y Seguimiento de conductos. Si desea obtener información detallada acerca de solución de problemas en el flujo de correo en Exchange Server 2007, consulte el tema "Problemas de transporte y de flujo de correo" en go.microsoft.com/fwlink/?LinkID=120145.

En controladores de dominio de Active Directory, se puede recopilar información detallada sobre solución de problemas si se habilita el registro de diagnóstico para Acceso al directorio y otras categorías, configurando las entradas del registro correspondientes en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Un valor de 0x0 en una categoría significa que sólo se registran eventos críticos mientras que un valor de 0x5 significa todos los eventos, incluida la información de depuración. El uso de un nivel de registro mayor que 0x3 puede degradar el rendimiento del servidor y llenar rápidamente el registro de eventos de Windows. Durante el funcionamiento normal, todos los valores se deben establecer en 0x0.

La recopilación de información de diagnóstico detallada en servidores SharePoint, Exchange y Active Directory en una situación de solución de problemas puede ayudar a encontrar de manera rápida y confiable el foco del problema. También son útiles herramientas de solución de problemas adicionales, tales como herramientas de TCP/IP (ping, tracert, telnet, etc.) y Monitor de red, ya que la mayor parte de las comunicaciones entre estos sistemas se llevan a cabo a través de la red de equipos. Microsoft® Network Monitor 3.1se encuentra disponible en go.microsoft.com/fwlink/?LinkId=120143.

Transferencia de mensajes salientes

Recursos

• Sitio web de productos y tecnologías de SharePoint
• Centro tecnológico de Windows SharePoint Services
• Centro de desarrollo de Windows SharePoint Services
• Blog del equipo de productos y tecnologías de Microsoft SharePoint

Equipado con registros de eventos, registros de seguimiento, registros de protocolos, registros de seguimiento de mensajes y seguimientos de red, estoy listo para realizar la solución de problemas de integración de mensajería de SharePoint. Comencemos con la parte sencilla: la transferencia de mensajes salientes. SharePoint es compatible con la transferencia de mensajes salientes en distintas configuraciones y no necesita un servicio SMTP local en los servidores web. Sin embargo, en un escenario completo de integración de mensajería, la configuración recomendada usa el servicio SMTP local. La figura 2 muestra los componentes clave en el escenario.

Figura 2 Transferencia de mensajes salientes (haga clic en la imagen para ampliarla)

Este escenario de mensajería consta de cuatro etapas: SharePoint debe transferir el mensaje al servicio SMTP, el servicio SMTP debe procesar el mensaje, el servidor de transporte de concentradores debe recibir el mensaje y Exchange Server 2007 debe transferir el mensaje al destino final.

Si SharePoint no puede transferir el mensaje al servicio SMTP, normalmente se recibirá un error en la interfaz de usuario, por ejemplo que no es posible enviar una notificación por correo electrónico. La causa podría ser que el servicio SMTP no esté en ejecución. O quizás el registro del protocolo SMTP indica que el servicio SMTP rechazó el intento de envío con un código de error 550 (No se ha completado la acción solicitada: buzón no disponible), lo que indica que el problema se encuentra en el servicio SMTP.

Para comprobar que no es un problema de SharePoint, se puede usar un script básico (consulte SMTP.vbs en el material complementario) para enviar a través de SMTP un mensaje de prueba con la misma información de emisor y destinatario. El script no se ejecutará correctamente si es un problema del servicio SMTP. De hecho, quizás este script ofrezca pistas valiosas de la causa principal del problema que desafortunadamente SharePoint no divulga ni siquiera con la depuración habilitada, como se muestra en la figura 3.

Figura 3 No se puede retransmitir mensajes (haga clic en la imagen para ampliarla)

Al conceder los permisos de retransmisión del servidor web en la configuración del servicio SMTP y reiniciar el servicio, se podrá resolver el problema de envío de mensajes de SharePoint. Ahora el mensaje puede alcanzar el servicio SMTP, y la siguiente pregunta importante es si el servicio SMTP puede enrutar el mensaje al servidor de transporte de concentradores.

Si el mensaje se queda en la carpeta de cola, significa que el servicio SMTP no puede ponerse en contacto con el servidor de transporte de concentradores. Esto se debe a que el servicio de transporte de Microsoft Exchange no está en ejecución o debido a un problema de comunicación de red o de configuración. Mediante el cliente Telnet, se puede comprobar rápida y fácilmente si es posible conectarse al puerto de destino de un conector de recepción configurado para la comunicación interna.

Este no es necesariamente el puerto TCP 25. De hecho, si el servicio SMTP usa este puerto, quizás los mensajes se transfieran al conector de recepción predeterminado para servidores de transporte de concentradores, configurado para bloquear envíos de mensajes anónimos. En este caso, verá un archivo de mensaje en la carpeta de entrega. (El servicio de temporizador de Windows SharePoint Services debe estar detenido; de lo contrario, el mensaje desaparece después de algunos segundos). El archivo de mensaje es una notificación de estado de entrega que indica que el mensaje ha sido rechazado con: "Código de diagnóstico: smtp; 530 5.7.1. El cliente no se autenticó".

Para resolver este problema, debe crear un conector de recepción dedicado para los servidores de SharePoint. Como los servidores de SharePoint son sistemas internos, elija la opción de autenticación Protegido externamente. De este modo, no necesita conceder derechos extendidos a la cuenta de inicio de sesión anónimo. Además, considere el uso de IPsec para proteger la comunicación entre servidores de SharePoint y el servidor de transporte de concentradores.

Si los mensajes dejan la carpeta de cola SMTP y los registros del protocolo SMTP en el servidor de SharePoint y el servidor de transporte de concentradores (consulte la carpeta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indican que la transferencia de mensajes se realizó correctamente, puede considerar que el trabajo se ha realizado, asumiendo que Exchange Server 2007 puede enrutar el mensaje al destino. Como mencionamos anteriormente, se deben usar las herramientas de solución de problemas de flujo de correo incluidas en Exchange Server 2007 para investigar los problemas que surgen si los mensajes no alcanzan los destinatarios de Exchange de destino. En esta etapa, tenga en cuenta que la información de destinatarios incorrecta, los filtros de correo no deseado y las restricciones del tamaño de los mensajes pueden evitar la entrega final.

Transferencia de mensajes entrantes

En la dirección opuesta, la transferencia de mensajes es un poco más complicada porque los problemas potenciales son más sutiles. Por ejemplo, la documentación de producto de SharePoint recomienda configurar los registros MX en DNS para dominios del correo electrónico de SharePoint, que en una organización de Exchange son una causa habitual de pérdida de enrutamiento de mensajes.

Exchange Server 2007 usa conectores de envío con espacios de direcciones asociados para transferir los mensajes. Esto podría provocar el enrutamiento de los mensajes de SharePoint a servidores de transporte perimetral para realizar la transferencia a través de Internet incluso si los servidores de SharePoint son internos. En lugar de eso, en la transferencia de mensajes interna use conectores de envío con espacios de direcciones detallados y en la configuración del conector especifique que los servidores de SharePoint ejecutan el servicio SMTP como host inteligentes (consulte SharePoint Messaging Integration.pdf en la descarga complementaria). El establecimiento de una topología de enrutamiento bien definida con servidores cabeza de puente dedicados ayuda a lograr una transferencia de mensajes segura de Exchange a SharePoint.

Para comprobar que los mensajes llegan a los servidores de SharePoint, detenga el servicio de temporizador de Windows SharePoint Services. Los mensajes se amontonarán en la carpeta de entrega porque el servicio de temporizador es el que procesa los mensajes y coloca los datos adjuntos de archivos en bibliotecas de documentos asociadas con las direcciones de correo electrónico del destinatario, como se indica en la figura 4. Si los mensajes no llegan a la carpeta de entrega, use el Visor de colas en el servidor de transporte de concentradores para ver si Exchange enruta correctamente los mensajes. A continuación, investigue los problemas de comunicación de red que podrían impedir la comunicación entre el servidor de transporte de concentradores y el servicio SMTP del servidor de SharePoint.

Figura 2 Transferencia de mensajes salientes (haga clic en la imagen para ampliarla)

Cuando reinicia el servicio del temporizador, debe ver que los elementos de mensaje desaparecen de la carpeta de entrega. Sin embargo, si los datos adjuntos de mensajes no terminan como documentos en las bibliotecas de destino, a pesar de que SharePoint indique un procesamiento correcto de los mensajes en el registro de eventos de Windows, significa que Exchange ha enviado los mensajes en formato RTF de Exchange. Para investigar este problema, detenga nuevamente el servicio de temporizador, envíe desde su cliente Outlook® otro mensaje con datos adjuntos y, a continuación, abra el mensaje en el Bloc de notas después de que llegue a la carpeta de entrega. Ahora busque la cadena "winmail.dat". Si la encuentra, significa que Exchange Server envía los mensajes en un formato incorrecto.

SharePoint requiere datos adjuntos de mensajes codificados en formato MIME o UUENCODE. Además, SharePoint no muestra los problemas de procesamiento relacionados con winmail.dat en el registro de eventos de Windows (consulte la figura 5). Simplemente, los datos adjuntos de archivos no aparecerán en la biblioteca de documentos. Use el Bloc de notas como herramienta de solución de problemas y elimine el problema del formato configurando en la Consola de administración de Exchange una definición de dominio remoto para el dominio del correo electrónico de SharePoint. En la ficha Formato del mensaje original enviado como datos adjuntos al informe del diario, en Formato de texto enriquecido de Exchange, seleccione No utilizar nunca.

Figura 5 Procesamiento de mensajes Winmail.dat (haga clic en la imagen para ampliarla)

Administración de directorios

Uno de los eventos más útiles del servicio de temporizador es el evento 6873, que indica que ocurrió un error al procesar un archivo de correo electrónico entrante debido a un alias desconocido. Esto sucede si un usuario de Exchange especifica una dirección de correo electrónico de SharePoint incorrecta al enviar los mensajes, tal como una biblioteca de documentos inexistente.

Este problema se puede mitigar configurando el servicio de administración de directorios en la configuración del correo electrónico entrante en la administración central de SharePoint para crear objetos de destinatario para bibliotecas de documentos habilitadas para correo electrónico en Active Directory. Entonces los usuarios de Exchange podrán seleccionar fácilmente de la libreta de direcciones estos objetos de destinatario que contienen la información de dirección correcta.

No obstante, observe que ahora aparecen problemas completamente nuevos por solucionar. En una configuración de sistema segura, se producirán errores en el servicio de administración de directorios basados en el principio de privilegio mínimo, porque esta característica eleva los requisitos de permisos en el servidor web. Además, la documentación del producto (por ejemplo technet.microsoft.com/library/cc262947.aspx) exagera un poco la situación al sugerir que debe conceder el derecho "Crear, eliminar y administrar cuentas de usuario" a la cuenta del grupo de aplicaciones de administración central en la unidad organizativa que especificó en los objetos de destinatario de SharePoint en Active Directory.

El servicio de administración de directorios crea objetos de contacto y grupo y, por lo tanto, la cuenta del grupo de aplicaciones de administración central requiere control total sobre los objetos de contacto y grupo de esta unidad organizativa, pero no requiere permisos administrativos para las cuentas de usuario. Si establece el servicio de administración de directorios en una granja de servidores web tal como se describe e intenta habilitar el correo electrónico en una biblioteca de documentos, es muy probable que obtenga el error "Acceso denegado".

La información de errores apunta a problemas de permisos de Active Directory, y los administradores de SharePoint asignan rápidamente control total para Todos en la unidad organizativa de SharePoint. Sin embargo, esta acción no sólo debilita la seguridad de Active Directory, sino que tampoco resuelve el problema.

Una solución de problemas estructurada requiere localizar en primer lugar el foco del problema y posteriormente aplicar cambios de configuración orientados. Si sigue este enfoque y comprueba el registro de eventos de Windows en el controlador de dominio y quizás si realiza un seguimiento de las comunicaciones de red con el Monitor de red, pueda averiguar que este problema sucede cuando SharePoint no tiene acceso a Active Directory. Por lo tanto, es improbable que esos cambios de configuración de Active Directory corrijan el problema. El problema se produce en el servidor de SharePoint.

Desafortunadamente es muy difícil obtener información más útil sobre este problema de permisos. SharePoint no registra ninguna información adicional en el registro de eventos de Windows. Sin embargo, si habilita la depuración de SharePoint, podrá ver la pila de llamadas (tal como se muestra en la figura 6), que sugiere que el servicio de administración de directorio usa el método CreateContact de un servicio web de SharePoint. El SDK de SharePoint le indicará que se trata del servicio web de integración de correo electrónico (<WSS_server>:<admin_port>/_vti_bin/SharePointEmailWS.asmx).

Figura 6 Resultados de depuración

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

Analicemos sharepointEmailWS.asmx en un explorador web para ver la lista de operaciones admitidas. Puede observar el método CreateContact, y si hace clic en el vínculo de CreateContact se mostrarán los mensajes SOAP que debe enviar a este servicio web si desea crear un contacto en Active Directory. Esto es útil porque ahora puede crear una herramienta de solución de problemas basada en scripts (consulte sharepointEmailWS.vbs en el material complementario) que funcione fuera de la interfaz de usuario de SharePoint, lo cual facilita la especificación de cuentas de usuario diferentes durante las ejecuciones de las pruebas. La figura 7 muestra la información devuelta si ejecuta este script con la cuenta del grupo de aplicaciones de administración central (a la izquierda) y con la cuenta del administrador de SharePoint (a la derecha).

Figura 7 Dos mensajes de error "Acceso denegado" diferentes (haga clic en la imagen para ampliarla)

¡Los mensajes de error son diferentes! Ambos mensajes establecen que se deniega el acceso, pero el error de la izquierda indica un problema de procesamiento y el de la derecha no lo hace. Así que, ¿cuál es la diferencia entre las cuentas del grupo de aplicaciones y la cuenta del administrador de SharePoint?

El administrador de SharePoint es un administrador local del servidor de SharePoint mientras que las cuentas del grupo de aplicaciones no lo son. Si se agregan las cuentas del grupo de aplicaciones de su aplicación web al grupo de administradores locales y se reinicia el servidor web, el problema se resolverá, aunque no son grandes noticias. Considero inaceptable la ejecución de cuentas del grupo de aplicaciones con privilegios administrativos en los servidores web de producción.

¿Por qué una cuenta del grupo de aplicaciones requiere estos permisos elevados? Una vez más, el script puede revelar la respuesta. Si concede permisos de administrador local a todos los usuarios del servidor web para realizar pruebas, encontrará que las cuentas del grupo de aplicaciones pueden usar el servicio web de integración de correo electrónico mientras que el acceso permanece denegado para todas las demás cuentas, incluidos los administradores de SharePoint. Esto significa que el servicio web de integración de correo electrónico usa la configuración del grupo de aplicaciones como base para las decisiones de control de acceso.

La configuración del grupo de aplicaciones forma parte de la metabase IIS (o del archivo applicationHost.config en IIS 7.0), y el acceso a la metabase está restringido a los administradores locales de forma predeterminada. Afortunadamente, es posible conceder acceso a la metabase a cuentas de usuarios que no son administradores con el Explorador de Metabase incluido en las herramientas del kit de recursos de IIS 6.0. En IIS 7.0, es aún más fácil conceder control total al archivo applicationHost.config; simplemente ejecute los siguientes comandos:

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

En resumen, para crear objetos de contacto en Active Directory, el grupo de aplicaciones de administración central requiere control total sobre los objetos de contacto y grupo en la unidad organizativa de destino. Y las cuentas del grupo de las aplicaciones web requieren acceso total a la metabase en los servidores de SharePoint de la granja de servidores web. Ahora está listo para crear objetos de contacto mediante la interfaz de usuario de SharePoint.

Pero espere: ¡hay mucho más! En Active Directory, la creación de objetos de destinatario es sólo la mitad de la historia de integración de directorios. La otra mitad es la generación de atributos de destinatario relacionados con Exchange y la actualización de libretas de direcciones basadas en el servidor. Por ejemplo, si actualiza la lista global de direcciones en el servidor Exchange mediante el comando Shell de administración de Exchange: Update-GlobalAddressList "Default Global Address List", podrá encontrar objetos de destinatario creados recientemente para bibliotecas de documentos de SharePoint en la libreta de direcciones de Outlook. Pero si se envían mensajes a estos destinatarios se obtendrán informes de entrega sin éxito debido a información de dirección incorrecta, como se ilustra en la figura 8.

Figura 8 Mensaje que no se puede entregar a una biblioteca de documentos (haga clic en la imagen para ampliarla)

La sigla IMCEAEX significa dirección encapsulada del conector de Internet Mail para Exchange. Indica una dirección encapsulada de destinatario que no pertenece a Exchange en un formato que el viejo conector de Internet Mail de Exchange puede controlar. Pero actualmente trabajamos con Exchange Server 2007 y conectores de envío basados en SMTP nativo.

El punto es que el servicio web de integración de correo electrónico de SharePoint no escribe los atributos de dirección que Exchange Server 2007 requiere para la transferencia de mensajes. Sólo escribe el nombre, apellido, nombre para mostrar y dirección de destino (y, opcionalmente, los atributos msExch­RequireAuthToSendTo). Pero no establece el sobrenombre de correo, el nombre distintivo (DN) del Exchange heredado ni las direcciones proxy, y no asocia el objeto de destinatario con una directiva de destinatarios de Exchange.

Para resolver este problema, use el cmdlet Get-Mailbox en el Shell de administración de Exchange para obtener todos los objetos de destinatario con una dirección de destino que señale al dominio del correo electrónico de SharePoint. Y canalice la salida al cmdlet Set-MailContact para activar las directivas de destinatarios de Exchange, de la siguiente manera:

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

Como alternativa, use la consola de administración de Exchange y seleccione la casilla "Actualizar direcciones automáticamente según directiva de direcciones" en las propiedades del objeto de contacto.

WSS 3.0 y MOSS 2007 admiten originalmente la integración de mensajería completa para habilitar alertas y notificaciones basadas en correo electrónico, flujos de trabajo y envíos de documentos. Aunque configurar los sistemas correctamente no es una tarea sencilla, la integración de mensajes puede aumentar la productividad del trabajador. Concretamente, debe asegurarse de que la transferencia de mensajes entrantes y salientes funciona correctamente. También debe estar seguro de que la integración de directorios funciona.

Los mensajes de error de SharePoint no siempre son intuitivos o informativos. No obstante, he mostrado algunas formas de llegar hasta el fondo de los problemas de integración, ubicar las causas principales y eliminar los problemas de forma confiable sin tener que arriesgar la seguridad en los servidores de SharePoint.

Pav Cherny es experto en TI y autor especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus publicaciones incluyen notas del producto, manuales de productos y libros centrados en operaciones de TI y administración de sistemas. Pav es Presidente de Biblioso Corporation, una empresa especializada en servicios de documentación y localización administrados.

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