Solución de problemas de replicación de carpetas públicas – Parte 3: solución de problemas de eliminación de réplicas y problemas comunes
Artículo original publicado el lunes, 28 de noviembre de 2011
Entrada original en el blog estadounidense: 24 de enero de 2006
Esta es la tercera entrada del blog acerca de cómo solucionar problemas de replicación de carpetas públicas. En la primera entrada, explicamos cómo solucionar problemas de replicación de cambios nuevos. La segunda entrada del blog describía cómo solucionar problemas de replicación de datos existentes. Esta entrada de la serie se ocupará de cómo solucionar problemas de eliminación de réplicas y problemas comunes. Para obtener información más completa, consulte todo el material al que se hace referencia.
Solución de problemas de eliminación de réplicas
Ha eliminado un servidor antiguo de la lista de réplicas en todas sus carpetas. Sin embargo, al ir a las Instancias de carpetas públicas del antiguo almacén en ESM, sigue viendo un conjunto de carpetas. Se debe a un problema en el proceso de eliminación de réplicas. En la versión Exchange 2003 SP2 de ESM, si intenta eliminar un almacén público en este estado, ESM mostrará el siguiente diálogo:
“No se puede eliminar este almacén de carpetas públicas porque contiene réplicas de carpetas. Para evitar perder datos, haga clic con el botón secundario en el almacén de carpetas públicas y utilice Mover réplicas para mover las réplicas a otro servidor. Es posible que se tarden varias horas en replicar el contenido en el nuevo servidor y quitar las réplicas locales.”
Cuando se quita un almacén de la lista de réplicas de una carpeta, ese almacén no elimina los datos inmediatamente. Lo que hace es emitir una solicitud de estado 0x20 especial a todas las demás réplicas. Esta solicitud se denomina Solicitud en estado pendiente de eliminación de réplicas (RDPSR, por sus siglas en inglés), y no se puede distinguir de las solicitudes de estado normales que hay en el registro de aplicaciones. Las RDPSR contienen una marca que indica que la réplica está pendiente de eliminar. Cuando los demás almacenes reciben esta 0x20, responden con una 0x10 especial, denominada Confirmación de eliminación de réplica pendiente (RDPA). La RDPA indica que se pueden eliminar esos datos, pero los demás almacenes solo envían esta 0x10 si tienen ya todos los CN que tiene la réplica pendiente de eliminar. La réplica se eliminará solamente cuando el almacén haya recibido una 0x10 que indique que alguien más tiene los datos.
Por eso, si elimina el almacén antes de que estén vacías las Instancias de carpetas públicas, probablemente perderá algún dato. Solo ESM 2003 SP2 impedirá que lo haga: en las versiones anteriores, tendrá que comprobar manualmente las Instancias de carpetas públicas para saber si es adecuado eliminar el almacén. Debe comprobar siempre las Instancias de carpetas públicas antes de eliminar un almacén público y, cuando ESM 2003 SP2 le advierte sobre esto, no debe pasarlo por alto; deberá solucionar los problemas del proceso de eliminación de réplicas.
Tenga en cuenta que, en las versiones anteriores a Exchange 2003 SP2, cuando se quita un servidor de la lista de réplicas, solo se envía la RDPSR una vez. Si nadie responde, verá que la carpeta permanece indefinidamente en las Instancias de carpetas públicas, salvo que vuelva a agregar el almacén a la lista de réplicas y lo quite de nuevo, de modo que se envíe otra RDPSR. En 2003 SP2, este comportamiento cambia y el almacén vuelve a intentarlo cada hora hasta que recibe una RDPA de alguien.
Solución de problemas
Se solucionan casi igual que el proceso de reposición.
1. ¿Envió una 0x20 la réplica pendiente de eliminación?
No lo sabrá a menos que ya tuviera activado el registro cuando quitó la réplica. Por suerte, puede, simplemente, volver a agregar la réplica y quitarla de nuevo. A continuación, busque la 0x20 en el registro de la aplicación.
2. ¿Llegó la 0x20 a las demás réplicas?
Ahora ya conoce el proceso. Consulte los registros de aplicación de las demás réplicas para saber si recibieron la 0x20.
3. ¿Respondió alguna otra réplica con una 0x10?
Esta es, probablemente, la parte en la que acabará centrándose. Si alguna réplica recibió la 0x20 de la réplica pendiente de eliminación, pero no respondió con una 0x10, significa que la réplica pendiente de eliminar contiene datos que no tiene la otra réplica. Sabe que recibió una 0x20 de esa réplica, de modo que ella ya conoce los datos que faltan. Por lo tanto, lo normal sería ver una solicitud de reposición de esa carpeta cada 24–48 horas. Consulte el registro de la aplicación y solucione los problemas exactamente igual que en el proceso de reposición normal que se describió anteriormente.
4. ¿Recibió la 0x10 la réplica pendiente de eliminar?
Cuando la otra réplica tenga todos los datos, esa réplica debe responder con una 0x10. Cuando la réplica pendiente de eliminar reciba esa 0x10, podrá, por fin, eliminar los datos. Sin embargo, esto no significa que vaya a pasar inmediatamente. Si algún cliente está usando esa réplica, se eliminará más tarde durante el mantenimiento en línea. Si lo desea, puede desmontar y volver a montar el almacén para desconectar los clientes y agilizar este proceso.
Problemas comunes
Puede encontrarse con que un servidor haya enviado algún tipo de mensaje de replicación a otro servidor, pero el servidor receptor no haya registrado el mensaje entrante en el registro de aplicaciones. Sin embargo, el seguimiento de mensajes indica que se entregó localmente al almacén de ese servidor. Este comportamiento suele indicar que existe un problema con la tabla de estado de replicación o bien un problema de permisos en el servidor virtual SMTP.
Empecemos por lo más sencillo. Los problemas que hacen que el servidor receptor ignore un mensaje de replicación entrante son problemas con la tabla de replicación de estado, o tabla ReplState. Los problemas con la tabla ReplState también pueden hacer que el servidor no emita solicitudes de reposición (0x8) de algunas carpetas, de modo que esta información se aplica también a ese caso. Cada almacén público usa su tabla ReplState para llevar un seguimiento del estado de replicación de todas las carpetas replicadas. La tabla contiene varias filas por cada carpeta: una fila por cada réplica. Es posible que las filas de la tabla ReplState pierdan su sincronización con la lista de réplicas, y que tengan más o menos filas de las que deben. A veces, para sincronizarlas, basta con realizar un cambio como, por ejemplo, quitar un servidor de la lista de réplicas, aplicar el cambio y volver a agregarlo inmediatamente; pero no siempre funciona. Por suerte, se agregó una prueba de ReplState a isinteg. Consulte KB889331 si tiene Exchange 2003, o KB892485 si tiene Exchange 2000. Si tiene los archivos isinteg.exe y store.exe actualizados, puede usar isinteg para corregir el problema de la tabla ReplState. Si solo ejecuta la prueba ReplState, esto suele tardar bastante poco (menos de un minuto, incluso con almacenes públicos de gran tamaño). Una vez ejecutado isinteg, es posible que, aun así, tenga que volver y cambiar la carpeta para que la tabla ReplState se sincronice con la lista de réplicas. Después de sincronizarse, el servidor debería ser capaz de procesar los mensajes de replicación entrantes, o debería empezar a emitir solicitudes de reposición con normalidad.
El otro problema habitual que hace que se ignoren los mensajes de replicación entrantes es un problema específico de Exchange 2003. Los servidores Exchange 2003 requieren que el servidor remitente tenga el derecho de Enviar como en el servidor virtual SMTP receptor. Es decir, si ServidorA tiene Exchange 2003, y ServidorB está enviando un mensaje de replicación de carpetas públicas a ServidorA, ServidorB debe tener Enviar como en el servidor virtual SMTP de ServidorA. Si no lo tiene, ServidorA no procesará el mensaje de replicación entrante. Este permiso se suele conceder a través de los grupos Servidores de dominio de Exchange. Si el derecho de Enviar como es lo que provoca el problema, no se recibirá ningún mensaje de replicación entrante que provenga de ese servidor. La forma más sencilla de identificar este problema es utilizar el seguimiento de red registrado mientras se transfiere un mensaje de replicación de un servidor a otro. La conversación debería ser como sigue:
ServidorA: 220 ServidorA.microsoft.com Microsoft ESMTP MAIL Service...
ServidorB: EHLO ServidorB.microsoft.com
ServidorA: 250-ServidorA.microsoft.com Hello
250-TURN
250-SIZE
250-ETRN
250-PIPELINE
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-X-EXCH50
250 OK
La parte importante de todo esto es que ServidorA debe anunciar las opciones GSSAPI NTLM LOGIN. Si no las ve en la respuesta de ServidorA al EHLO, suele ser porque se ha desactivado la Autenticación de Windows integrada en el servidor virtual SMTP. Esto se menciona en el paso 1 de KB843106 y el paso 3 de KB842273. Si aparecen estos verbos de autenticación, debería ver cómo ServidorB intenta usarlos:
ServidorB: X-EXPS GSSAPI
ServidorA: 334 GSSAPI supported
ServidorB: <conjunto de datos codificados en base64>
ServidorA: 334 <más código en base64>
ServidorB: CRLF
ServidorA: 235 2.7.0 Authentication successful.
Si la autenticación no se realiza correctamente, es posible que tenga algún problema con kerberos o con la cuenta de equipo de ServidorB. A continuación, los servidores transmitirán la información de estado del vínculo. Después de esto, conseguirán transferir el correo electrónico:
ServidorB: MAIL FROM:<ServidorB-IS@microsoft.com>
ServidorA: 250 2.1.0 ServidorB-IS@microsoft.com....Sender OK
ServidorB: RCPT TO:<ServidorA-IS@microsoft.com> NOTIFY=NEVER
ServidorA: 250 2.1.5 ServidorA-IS@microsoft.com
ServidorB: XEXCH50 2404 2
ServidorA: 354 Send binary data
Lo importante es esta última respuesta al verbo XEXCH50. Si la respuesta es "354 Send binary data", todo es correcto, al menos, por lo que respecta a los permisos para el servidor virtual SMTP. Si no se anunciaron las opciones de inicio de sesión de GSSAPI NTLM, o si hubo algún error en el intento de autenticación, lo normal es que ServidorA responda "504 Need to authenticate". Si esos pasos se realizaron correctamente, pero ServidorA sigue diciendo "504 Need to authenticate" en lugar de "354 Send binary data", significa que ServidorB no tiene el derecho de Enviar como en el servidor virtual SMTP de ServidorA. Hay varias formas de que esto ocurra. En primer lugar, cuando delega derechos como Administrador total de Exchange en ESM, ese usuario o grupo hereda una denegación del derecho de Enviar como. Por lo tanto, si se usa ESM para delegar derechos de administración a la cuenta de equipo, el grupo Servidores de dominio de Exchange o algún otro grupo que contenga los servidores de Exchange, se interrumpirá la replicación de carpetas públicas. Otra posibilidad es que la cuenta de equipo no esté en el grupo Servidores de dominio de Exchange, que es como suele tener el derecho de Enviar como. Tendrá que evaluar los permisos del servidor virtual SMTP y averiguar por qué la cuenta de equipo del servidor remitente no tiene los derechos adecuados. Consulte KB843106 y KB842273 para obtener información más detallada sobre el problema "504 Need to authenticate".
Conclusión
Puede que, al leer este documento, se haya dado cuenta de que SP2 para Exchange 2003 contiene varias mejoras importantes para evitar problemas de replicación y ayudar a solucionarlos. Los entornos con varios almacenes públicos pueden encontrar muchas ventajas en SP2, especialmente, a la hora de mover réplicas de un servidor a otro, y agregar y quitar almacenes públicos.
Espero que haya resultado útil. ¡Gracias a Dave Whitney por revisar todo esto!
Esta entrada de blog es una traducción. Encontrará el artículo original aquí: Public Folder Replication Troubleshooting – Part 3: Troubleshooting Replica Deletion and Common Problems