Solución de problemas relacionados con la replicación de carpetas públicas – Parte 1: Solución de problemas de replicación de nuevos cambios
Artículo original publicado el lunes, 28 de noviembre de 2011
Publicado originalmente en el blog de Estados Unidos: 17 de enero de 2006
Nota: Esta entrada de blog es la primera de una serie denominada Solución de problemas relacionados con las carpetas públicas. Asegúrese de consultar también las partes 2, 3 y 4 de la serie.
Introducción
El propósito de esta serie de entradas de blog es ofrecer una guía para la solución de problemas de replicación de carpetas públicas. A pesar de que estas entradas no indican de manera exacta cómo resolver cada uno de los posibles problemas de replicación, sí muestran cómo aislar esos problemas para poder centrarse en el punto de error. Dicho de otro modo, la finalidad de esta entrada es guiarle desde una descripción de problema como “El contenido de mi antiguo servidor no se está replicando en mi servidor nuevo” a una descripción mucho más concreta como “Mi antiguo servidor no responde a las solicitudes de estado de mi nuevo servidor y, por lo tanto, el nuevo servidor no sabe que falta datos y no intenta llevar a cabo una reposición. Esto significa que el problema se encuentra realmente en el antiguo servidor”. En esta entrada también se mostrará cómo identificar algunos de los problemas más comunes de replicación. Antes de entrar en detalles, me gustaría describir de forma general mi enfoque hacia estos problemas.
La mejor herramienta para solucionar problemas de replicación de carpetas públicas es el registro de aplicaciones. Para aislar un problema de replicación, es necesario realizar un seguimiento de los eventos de replicación del registro a fin de ver exactamente dónde se interrumpe el proceso. Normalmente, se debe elevar al máximo el registro de diagnóstico en mensajes de replicación de entrada y de salida como punto de inicio para la solución de problemas. Cada vez que un almacén envía o recibe un mensaje de replicación, registra un evento a ese efecto (asumiendo que el registro esté activado). Los diversos tipos de mensajes de replicación se pueden diferenciar por el 'Tipo' mostrado en la descripción del evento. Yo prefiero centrarme en el tipo antes que en el Id. por varios motivos:
- Los Id. de eventos varían entre las versiones de Exchange. Por ejemplo, en Exchange 5.5 una solicitud de reposición de salida era un 3014. En Exchange 2000 y 2003 es un 3016.
- Los Id. de eventos de entrada y salida son diferentes para cada tipo. Un mensaje de jerarquía de salida es un 3018, mientras que un mensaje de jerarquía de entrada es un 3028.
- Las solicitudes y los mensajes de estado usan los mismos Id. de evento, incluso aunque sean dos tipos de mensajes diferentes. De este modo, no es posible distinguirlos únicamente a partir del Id.
Centrarse en el tipo es más fácil, ya que se puede correlacionar estos Id. de eventos examinando el registro de aplicaciones. Solo hay 7 tipos y se puede ver si el mensaje es de salida o de entrada observando la categoría del evento. Si nos centramos en los tipos en vez de en los Id. de eventos, todo lo que se necesita recordar es:
Jerarquía - 0x2
Contenido - 0x4
Solicitud de reposición - 0x8
Respuesta de reposición - 0x80000002 (para jerarquía) o 0x80000004 (para contenido)
Estado - 0x10
Solicitud de estado - 0x20
Tenga en cuenta también que el registro de errores de replicación rara vez es útil. Incluso si la replicación está funcionando de modo normal, la mayoría de servidores generarán un gran número de eventos de error de replicación, como el evento Id. 3093 que indica que se produjo un error al leer una propiedad. En la mayoría de casos la propiedad no tiene efecto sobre la replicación y el error se puede ignorar. Yo recomiendo dejar el registro de errores de replicación en ninguno a menos que esté buscando algo específico como el problema descrito en esta entrada anterior del blog.
Solucionar la replicación de nuevos cambios
Para solucionar la replicación de carpetas públicas, primero es necesario conocer con el flujo de mensajes normal que se espera cuando la replicación está funcionando. Sabiendo eso, se puede identificar el punto de error cuando surge un problema. Antes de centrarnos en cómo solucionar la replicación de nuevos cambios, vamos a describir cuál es el comportamiento esperado.
Replicación de jerarquía
La replicación de nuevos cambios en la jerarquía se produce siempre que se crea o elimina una carpeta, o cuando se modifican las propiedades de una carpeta pública como, por ejemplo, lista de réplicas, permisos de cliente, descripción, nota administrativa o límites de almacenamiento. Tenga presente que aquí no se incluyen las direcciones de correo ni la carpeta habilitada para correo. Las direcciones de correo están almacenadas en el objeto directorio de Active Directory, por lo que su modificación no tiene como resultado una replicación de jerarquía. Solo la modificación de las propiedades almacenadas en el almacén público producirá una replicación de jerarquía.
Cada 15 minutos (de forma predeterminada), el almacén difunde cualquier cambio que se haya producido en las propiedades de carpeta mediante uno o más mensajes de replicación de jerarquía. Con el registro elevado al máximo en la replicación saliente, verá un evento como este en el servidor en el cual se modificó la jerarquía:
Tipo de evento: Información
Origen de evento: Almacén público MSExchangeIS
Categoría de evento: Mensajes de replicación salientes
Id. de evento: 3018
Descripción:
Se emitió un mensaje de replicación saliente.
Tipo: 0x2
Id. de mensaje: <91ACCD0758385549A56A10971798985572D5@bilongexch1.bilong.test>
Base de datos "First Storage Group\Public Folder Store (BILONGEXCH1)"
CN mín.: 1-72CF, CN máx.: 1-72D3
RFI: 1
1) FID: 1-6994, PFID: 1-1, Desplazamiento: 28
IPM_SUBTREE\NewFolder
Observe el tipo ("Tipo: 0x2") al principio de la descripción, que lo identifica como un mensaje de replicación de jerarquía.
Desde el servidor que lo origina se envía un mensaje de replicación de jerarquía al resto de almacenes públicos. No existe el concepto de topología para la replicación de nuevos cambios. Todos los cambios de jerarquía se envían directamente desde el servidor en el que se realizaron dichos cambios a los demás servidores que disponen de un almacén público asociado con la misma jerarquía. En caso de que procesen correctamente el mensaje de replicación entrante, el resto de servidores deberán registrar un evento de entrada cuyo tipo sea 0x2.
Replicación de contenido
La replicación de contenido se produce siempre que un mensaje se crea, se elimina o se modifican sus propiedades. De forma predeterminada, el almacén difunde los cambios de contenido de una carpeta cada 15 minutos, como en el caso de la jerarquía. No obstante, ese intervalo se puede modificar cambiando la programación de replicación en esa carpeta. Un mensaje de replicación de contenido se identifica mediante el tipo 0x4 en la descripción del evento. De nuevo, no hay concepto de topología para la difusión de nuevos cambios. Cuando el contenido de una carpeta cambian en cualquier réplica determinada, esa réplica enviará un mensaje 0x4 directamente al resto de réplicas de la carpeta. Y una vez más, cada servidor que reciba el mensaje deberá registrar un evento 0x4 entrante cuando procese correctamente el mensaje de entrada.
Pasos para la solución
Los anteriores son los escenarios más básicos para la replicación. Cuando los nuevos cambios de jerarquía o de contenido no llegan de un servidor a otro, la solución es muy sencilla.
1. ¿El servidor generó un mensaje de replicación saliente?
Si modificó una carpeta o le agregó contenido a una carpeta de un servidor determinado, pero ese contenido no llegó a otro servidor, la primera pregunta que debería hacerse es si el servidor de destino difundió los cambios. A la hora de solucionar problemas, es importante saber frente a qué servidor se está trabajando cuando se realizan cambios. Hay varias formas de hacerlo. En el Administrador del sistema de Exchange se puede hacer clic con el botón secundario en el nodo de carpetas públicas y elegir "Conectar a" para señalar a un almacén en concreto. La mayoría de ocasiones el Administrador del sistema de Exchange efectuará los cambios en el almacén especificado, pero hay que tener en cuenta una excepción: permisos de cliente. Antes de Exchange 2003 Sp2, si se modificaban los permisos de cliente a través del Administrador del sistema de Exchange, éste intentaba llevar a cabo los cambios frente un almacén que alojaba una réplica de la carpeta, incluso si no era necesario porque los permisos se almacenaban como una propiedad de la carpeta en la jerarquía. Con la versión 2003 Sp2 del Administrador del sistema de Exchange, esto cambió y ahora se realiza el cambio en la jerarquía a la que se ha señalado. Cuando se prueba la replicación de jerarquía haciendo cambios a través del Administrador del sistema de Exchange, se debe evitar usar los permisos en la prueba ya que puede ser difícil predecir frente a qué almacén se realizará el cambio, a menos que se ejecute el Administrador del sistema de Exchange desde 2003 Sp2. Si se usa Outlook y se quiere comprobar qué réplica de carpeta se está alcanzado, se puede usar MFCMAPI o una herramienta similar para ver la propiedad PR_REPLICA_SERVER de la carpeta. Esto le indicará el nombre del servidor que usa Outlook para acceder al contenido de esa carpeta.
Si la programación de replicación es Siempre en la carpeta en cuestión (lo cual es siempre true para la jerarquía) y no ve un 0x2 o un 0x4 de salida en los próximos 15 minutos, entonces significa que hay un problema en el servidor de origen. Si el servidor no difunde contenido o jerarquía de salida, es posible que el agente de replicación no haya podido iniciarse. Uno de los escenarios comunes se describe en KB272999. Lo importante aquí es el evento 3079:
Id. de evento: 3079
Origen: MSExchangeIS Público
Tipo: Error
Categoría: Errores de replicación
Descripción:
Error 0x3f0 de subproceso de replicación inesperado.
EcGetReplMsg
EcReplStartup
FReplAgent
Esto se registrará incluso sin ninguna elevación de registro adicional cuando se monte el almacén público. Si el 3079 incluye la función "EcReplStartup", significa que el agente de replicación no se pudo iniciar y que no se difundirán nuevos cambios hasta que se corrija el problema y se monte de nuevo el almacén.
La replicación de jerarquía también es vulnerable a determinados problemas de permisos cuando los almacenes públicos de Exchange 5.5 están presentes en la organización. Si un servidor Exchange 2000 o 2003 envía un mensaje de replicación de jerarquía a un servidor Exchange 5.5, debe producir una propiedad ptagACLData (los permisos de estilo 5.5 basados en legacyExchangeDN) desde la propiedad ptagNTSD (los permisos de estilo 2000 basados en SID). Esto significa que se debe convertir cada SID en un legacyExchangeDN. Esta conversión de SID a legacyExchangeDN puede fallar por diferentes motivos. Por ejemplo, si un SID se resuelve a más de un usuario, se puede generar un evento como este:
Id. de evento: 9528
Categoría: General
Origen: MSExchangeIS
Tipo: Error
Descripción:
Se encontró el SID S-1-5-21-408248388-469072634-37170099-1391 en 2 usuarios en el DS, el almacén no puede asignar este SID a un usuario único.
Los usuarios implicados son:
/DC=com/DC=company/CN=Users/CN=User1
/DC=com/DC=company/CN=Users/CN=User2
Como el SID no se puede convertir en un legacyExchangeDN, el almacén no podrá generar un mensaje de difusión de jerarquía saliente.
2. ¿El mensaje iba dirigido al servidor que no recibió el cambio?
Si el servidor de origen generó el mensaje de salida, el paso siguiente es asegurarse de que iba dirigido al servidor que no recibió los datos. La manera más fácil de comprobar esto es realizar un seguimiento del mensaje. En el seguimiento, se puede rastrear simplemente el Id. del mensaje que se indicó en el evento de replicación saliente. En la ventana del historial de mensajes, la línea Para: estará visible. Si el almacén que no recibió los cambios no aparece enumerado aquí, entonces hay que centrarse de nuevo en el servidor de origen. ¿Se ve ese servidor en la organización? ¿Ese servidor contiene direcciones de correo en su objeto de almacén público? ¿El servidor de origen ve ese almacén en la lista de réplica de la carpeta en cuestión?
3. ¿El mensaje llegó al servidor de destino?
Una vez que se haya comprobado que el mensaje iba dirigido al servidor de destino, la siguiente pregunta es “¿llegó hasta allí el mensaje?”. La respuesta se puede averiguar con el seguimiento de mensajes. Si el seguimiento dice que el mensaje se entregó en el almacén, pero no se ve ningún evento de replicación entrante que reconozca el mensaje, consulte la sección “Problemas comunes” de la última entrada de esta serie.
En la siguiente entrada del blog: Solución de problemas de replicación de datos existentes.
Esta entrada de blog es una traducción. Puede consultar el artículo original en Public Folder Replication Troubleshooting – Part 1: Troubleshooting the Replication of New Changes