Descripción de la replicación de carpetas públicas

 

Se aplica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Última modificación del tema: 2015-03-09

La replicación de carpetas públicas es el proceso por el cual el contenido y la jerarquía de carpetas públicas se replican entre varios servidores por motivos de eficiencia y tolerancia a errores. Cuando un único árbol de carpetas públicas usa varias bases de datos de carpetas públicas ubicadas en servidores diferentes, Microsoft Exchange usa la replicación de carpetas públicas para mantener las bases de datos sincronizadas. El contenido de las carpetas públicas solo existe en almacenes de Exchange que se han configurado para contener una replicación de una carpeta específica. Los datos de contenido y de jerarquía se replican por separado. Cada base de datos de carpetas públicas conserva una copia de la jerarquía, que incluye listas de las demás bases de datos de carpetas públicas que conservan réplicas del contenido de cada carpeta. Las réplicas de contenido solo existen en las bases de datos de carpetas públicas que especifique. Para obtener más información acerca de cómo configurar la replicación de carpetas públicas, consulte Configurar la replicación de carpetas públicas.

Nota

A diferencia de Exchange Server 2007, Exchange Server 2010 no permite usar la replicación continua para replicar carpetas públicas. En Exchange 2010, solo se puede usar la replicación continua para las bases de datos de buzones de correo. Se puede hospedar una base de datos de carpetas públicas en un grupo de disponibilidad de base de datos (DAG) dentro de un servidor de buzones de correo, pero se deben usar varias bases de datos de carpetas públicas y replicación de carpetas públicas para la redundancia de datos.

Las bases de datos de carpetas públicas replican dos tipos de información de carpetas públicas:

• Jerarquía   La replicación de la jerarquía se produce cuando se han modificado las propiedades de las carpetas y la información organizativa sobre las carpetas. Todas las bases de datos de carpetas públicas poseen una copia de la información de jerarquía. La modificación de la siguiente información sobre carpetas públicas da lugar a la replicación de la jerarquía:

  • Nombre de la carpeta

  • Lista de réplicas

  • Posición de la carpeta en el árbol de carpetas públicas (incluidas las carpetas principales y secundarias)

  • Permisos

    Nota

    La replicación de la jerarquía no se produce si cambia las direcciones de correo electrónico de una carpeta pública habilitada para correo. Las direcciones de correo electrónico se almacenan en el objeto de directorio de Active Directory. Sólo se producirá la replicación de la jerarquía si cambia las propiedades en la base de datos de almacenamiento público.

• Contenido   La replicación del contenido se produce cuando se envían mensajes a carpetas públicas o cuando se agregan datos. Por ejemplo, el envío de mensajes de correo electrónico a una carpeta pública habilitada para correo, o la adición de un formulario organizativo a una carpeta pública, da como resultado la replicación del contenido. Para replicar contenido, debe configurar una carpeta para que replique su contenido en una base de datos de carpetas públicas específica o una lista de bases de datos. Sólo se mantendrán copias del contenido en las bases de datos que especifique. La copia de la carpeta que incluye contenido se denomina replicación de contenido.

Contenido

Funcionamiento de la replicación de carpetas públicas

Mensajes de replicación

Solicitudes de reposición y mensajes de reposición

Ejemplos de ciclos de replicación

Procedimientos recomendados para la implementación de la replicación

¿Necesita tareas de administración relacionadas con las carpetas públicas? Consulte Administración de carpetas públicas.

Funcionamiento de la replicación de carpetas públicas

Cuando modifique una carpeta pública o su contenido, la base de datos de carpetas públicas que contiene la réplica de la carpeta pública que ha cambiado envía un mensaje de correo electrónico descriptivo a las otras bases de datos de carpetas públicas que hospedan una réplica de la carpeta pública. Para reducir el tráfico de la red, Exchange incluye información sobre varios cambios en un solo mensaje de correo electrónico. La cantidad de información que se incluye en estos mensajes depende del límite de tamaño que se establezca para los mensajes de replicación. Si un mensaje supera el límite de tamaño especificado, dicho mensaje se envía por separado. Exchange enruta estos mensajes de replicación de la misma manera que los demás mensajes de correo electrónico.

Si realiza en la jerarquía de carpetas públicas cambios que afecten a varias carpetas, es posible que el proceso de replicación necesite un ancho de banda de red considerable. Por ejemplo, para mover carpetas públicas de un servidor a otro, debe crear réplicas en el servidor al que desee mover las carpetas públicas, esperar a que se repliquen los cambios de jerarquía en el servidor original y después esperar a que se replique el contenido en las nuevas réplicas. Una vez sincronizadas las réplicas, debe quitarlas del servidor anterior. Incluso la eliminación de las réplicas del servidor anterior genera tráfico de red, ya que esta acción debe replicarse como un cambio en la jerarquía. Para obtener más información acerca de cómo estos cambios en la jerarquía de carpetas públicas pueden afectar al sistema, consulte "Solicitudes de estado y mensajes de estado" más adelante en este tema.

Proceso básico de replicación de la jerarquía y el contenido

La siguiente ilustración y el texto explicativo que sigue describen el proceso básico para replicar la jerarquía y el contenido de carpetas públicas.

Proceso de replicación básico

Los detalles del proceso son los siguientes:

1. Un usuario modifica la carpeta pública.

2. La base de datos de carpetas públicas local registra el cambio.

3. En el siguiente ciclo de replicación programado (que se determina según el intervalo de replicación establecido para la base de datos de carpetas públicas), la base de datos de carpetas públicas comprueba las propiedades de la carpeta para determinar qué otros servidores contienen una réplica de dicha carpeta. Si existen otras réplicas, la base de datos determina la información que se debe replicar en ellas. Esta información constituye la actualización de las réplicas.

   La replicación de carpetas públicas está basada en objetos. Si se modifica una propiedad de un objeto, se debe replicar el objeto completo. Dado que la base de datos que replica el cambio no puede dar por supuesto que todas las réplicas receptoras estarán actualizadas, debe replicar el objeto completo. Las implicaciones para los diferentes tipos de replicación son las siguientes:

   • Replicación de la jerarquía   La replicación de nuevos cambios en la jerarquía se produce cuando se crea o elimina una carpeta pública, o cuando se realiza un cambio en las propiedades de una carpeta pública (como un cambio en la lista de réplicas, los permisos de cliente, la descripción, la nota administrativa o los límites de almacenamiento).

   • Replicación del contenido   Si se expone un mensaje nuevo o se modifica uno existente, la actualización incluye el mensaje completo y sus propiedades.

4. La base de datos de carpetas públicas asigna un número de cambio a la actualización.

   Cuando una carpeta replica una actualización en otro servidor, se incluye el número de cambio con ella. A continuación, el servidor receptor usa el número de cambio para determinar si la actualización constituye un cambio nuevo y si faltan datos en el servidor.

5. La base de datos de carpetas públicas empaqueta las actualizaciones en un mensaje de replicación. Los números de cambio de todas las actualizaciones en el mensaje se denominan conjunto de números de cambio (CNSet*)*.

   Junto con las actualizaciones, la base de datos de carpetas públicas empaqueta información de las entradas de la carpeta que se encuentran en la tabla de estado de replicación, incluidos los CNSets que se aplicaron anteriormente a la réplica. Para obtener más información acerca de la tabla de estado de replicación, consulte "Tabla de estado de replicación" más adelante en este tema.

6. Para reducir el tráfico de correo, la base de datos de carpetas públicas empaqueta varias actualizaciones de jerarquía en un solo mensaje de replicación. Igualmente, la base de datos empaqueta varias actualizaciones de contenido para la misma carpeta en un solo mensaje de replicación. No obstante, la base de datos no puede empaquetar actualizaciones de jerarquía en el mismo mensaje de replicación que las actualizaciones de contenido, y cada mensaje de replicación de contenido solo contiene actualizaciones para una sola carpeta.

7. La base de datos de carpetas públicas dirige el mensaje de replicación a las demás bases de datos de carpetas públicas que hospedan réplicas de la carpeta actualizada. La base de datos envía el mensaje, junto con los demás mensajes que se hayan empaquetado desde el anterior ciclo de replicación.

   Para entregar mensajes de replicación, la base de datos de carpetas públicas usa los componentes internos de enrutamiento de Exchange. La base de datos no intenta dividir los mensajes de replicación según los detalles de topología. Si se modifica el contenido de una carpeta y ésta tiene otras cinco réplicas, la base de datos genera un solo mensaje de replicación y lo dirige a las cinco bases de datos que hospedan dichas réplicas. Los componentes de enrutamiento determinan cómo enrutar y entregar el mensaje.

8. La base de datos de carpetas públicas recibe el mensaje de replicación.

9. La base de datos de carpetas públicas receptora desempaqueta la información de estado y actualización del mensaje de replicación.

10. La base de datos compara los números de cambio de las nuevas actualizaciones con la lista de números de cambio que ya contiene y después identifica las actualizaciones que aún no había recibido.

11. La base de datos aplica las nuevas actualizaciones a las réplicas de carpeta adecuadas.

12. Para cada replicación actualizada, la base de datos actualiza la tabla de estado de replicación con los números de cambio de la actualización actual y la información de estado de carpeta del mensaje de replicación.

    Si la información de la tabla de estado de replicación indica que se han aplicado otros CNSets a otras réplicas de la carpeta, pero no a las de esta base de datos, la base de datos registra los CNSets que faltan en una ubicación denominada matriz de reposición y después se prepara para enviar una solicitud de reposición. Para obtener más información acerca de las solicitudes de reposición, consulte "Solicitudes de reposición y mensajes de reposición" más adelante en este tema.

Volver al principio

Mensajes de replicación

El proceso de replicación usa los atributos de Active Directory de las bases de datos de carpetas públicas en lugar de los atributos de Active Directory de las carpetas públicas individuales. Los atributos de Active Directory para las carpetas públicas individuales solo se usan para enviar mensajes de correo electrónico normales a las carpetas o desde ellas. Se configura y se mantiene automáticamente un objeto de base de datos de carpetas públicas que reside en el contenedor de configuración de Active Directory.

Los mensajes de replicación difieren de otros mensajes de correo electrónico en que Exchange los trata como mensajes del sistema. Esto quiere decir que los mensajes de replicación no están limitados por las restricciones que se aplican a los mensajes de correo electrónico de los usuarios (como restricciones de tamaño y entrega).

En la tabla siguiente, se enumeran los diferentes tipos de mensajes de replicación que Exchange usa.

Nota

Los valores que aparecen entre paréntesis en la siguiente tabla corresponden a la notación hexadecimal de los tipos de mensaje. Estas notaciones se emplean en eventos y registros. Puede usar el valor hexadecimal para solucionar problemas de replicación.

Tipos de mensajes de replicación de carpetas públicas y cuándo se usan

Tipo de mensaje*	Cuándo se usa
Jerarquía (0x2)	Replica los cambios en la jerarquía desde la base de datos de carpetas públicas local a todas las demás bases de datos de carpetas públicas que usen la misma jerarquía. Aunque Exchange administra los cambios en la jerarquía por separado de los cambios a las réplicas de contenido, trata la jerarquía como si fuera otra carpeta. En algunos mensajes de evento y otras operaciones, Exchange se refiere a la jerarquía como carpeta 1-1.
Contenido (0x4)	Replica cambios de contenido de una réplica a todas las demás réplicas de contenido de esa carpeta. Un mensaje de contenido solo incluye información aplicable a una sola carpeta.
Solicitud de reposición (0x8)	Solicita los datos que faltan en CNSets de otra base de datos. Esto incluye números de cambio de jerarquía y contenido.
Respuesta de reposición (0x80000002 o 0x80000004)	Envía los datos que faltan en CNSets a una base de datos que solicitó las actualizaciones que faltan.
Estado (0x10)	Envía el CNSet actual de una carpeta a una o más réplicas de esa carpeta. Esto incluye números de cambio de jerarquía y contenido.
Solicitud de estado (0x20)	Solicita que se repliquen CNSets o que se devuelvan mensajes de estado. Esto incluye números de cambio de jerarquía y contenido.

Tabla de estado de replicación

Todas las bases de datos de carpetas públicas mantienen una tabla de estado de replicación para controlar el estado de las réplicas en la base de datos. La tabla de estado de replicación almacena la siguiente información:

• Información básica necesaria para crear actualizaciones para cada réplica.

• Información sobre la última actualización de cada réplica que se originó en la base de datos local, incluido el número de cambio de la actualización.

• Grupos de actualizaciones que se han aplicado a todas las otras réplicas conocidas de la carpeta. Los números de cambio identifican las actualizaciones en cada grupo. El conjunto de números de cambio de todas las actualizaciones en un grupo se denomina CNSet. La información de actualización se pasa de una base de datos a otra como parte del proceso de replicación.

Las siguientes tablas proporcionan un ejemplo de cómo funcionan las tablas de estado de replicación. En este ejemplo, las bases de datos de carpetas públicas en el servidor A y el servidor B contienen réplicas de una carpeta llamada Proyectos. En cada servidor, la tabla de estado de replicación controla, no solo el estado de la réplica en ese servidor, sino también el estado de la réplica en el otro servidor. Con esta información, el servidor A determina si su réplica de la carpeta Proyectos está sincronizada con la réplica de la carpeta Proyectos en el servidor B. Asimismo, el servidor B puede controlar su estado en relación con el servidor A.

Datos de ejemplo de la tabla de estado de replicación para el servidor A

Réplica	Datos
Carpeta de proyectos en el servidor A (réplica local)	Última actualización enviada: A-100
Carpeta de proyectos en el servidor B	A-100 recibida B-50 recibida

Datos de ejemplo de la tabla de estado de replicación para el servidor B

Réplica	Datos
Carpeta de proyectos en el servidor A	A-100 recibida B-50 recibida
Carpeta de proyectos en el servidor B (réplica local)	Última actualización enviada: B-50

Al combinarse las listas de bases de datos de carpetas públicas que contienen réplicas de contenido con la información de la tabla de estado de replicación, cada base de datos de carpetas públicas puede determinar su grado de actualización en comparación con las otras bases de datos de carpetas públicas que usa el árbol de carpetas públicas.

Volver al principio

Solicitudes de reposición y mensajes de reposición

La reposición se produce cuando una base de datos de carpetas públicas determina que no ha recibido todas las actualizaciones de una carpeta replicada (o de la jerarquía) y por tanto debe recuperar las actualizaciones que faltan de otra base de datos de carpetas públicas.

Para simplificar el proceso de reposición, Exchange almacena información sobre las actualizaciones que faltan en la matriz de reposición.

Es posible que los siguientes eventos alerten a una base de datos de carpetas públicas de que se deben reponer las actualizaciones que faltan:

• La información de estado de un mensaje de replicación entrante indica que la réplica en la base de datos de carpetas públicas que envió el mensaje tiene actualizaciones que faltan en la base de datos receptora. La base de datos receptora identifica los números de cambio que faltan y los almacena en su matriz de reposición.

• Se inicia una base de datos de carpetas públicas por primera vez. La nueva base de datos envía solicitudes de estado para obtener información sobre las demás bases de datos de la jerarquía. Cuando llegan los mensajes de estado correspondientes, la base de datos rellena la tabla de estado de replicación y, si es necesario, la matriz de reposición. La matriz de reposición puede contener entradas para las réplicas de jerarquía y de contenido que la base de datos deba hospedar.

• Un mensaje de jerarquía entrante indica que se debe colocar una nueva réplica de contenido en la base de datos de carpetas públicas. La nueva base de datos envía solicitudes de estado para obtener información sobre el contenido que pueda estar disponible para esta réplica en las demás bases de datos de la jerarquía. Cuando llegan los mensajes de estado correspondientes, la base de datos rellena la tabla de estado de replicación y, si es necesario, la matriz de reposición.

La matriz de reposición almacena esta información durante un período de tiempo especificado (denominado tiempo de espera de reposición). Si las actualizaciones que faltan llegan en mensajes de replicación subsiguientes durante este período, se quitan de la matriz de reposición. La siguiente tabla indica los valores de tiempo de espera de reposición predeterminados, que depende de dónde se encuentren las actualizaciones que faltan y de si se solicitaron anteriormente.

Tiempos de espera predeterminados usados para solicitudes de reposición

Tipo de solicitud	El contenido existe en una base de datos en el sitio de Active Directory local	El contenido existe en una base de datos en un sitio de Active Directory remoto
Reposición inicial	6 horas	12 horas
Primer reintento de reposición	12 horas	24 horas
Siguientes reintentos de reposición	24 horas	48 horas

Si el tiempo de espera de reposición expira y las actualizaciones siguen faltando, Exchange crea una o varias solicitudes de reposición y determina qué servidores se usarán como orígenes de reposición.

Para elegir servidores para usarlos como origen de reposición, Exchange crea en primer lugar una lista de todos los servidores con réplicas de la carpeta y después ordena la lista según la siguiente secuencia de criterios:

1. Según el estado del servidor. Los servidores inactivos o no disponibles pasan al final de la lista.

2. Según el servidor de reposición preferido (si lo hay). Exchange comprueba el servidor de reposición preferido en el objeto de base de datos de carpetas públicas en Active Directory. Esta configuración no se suele usar. En la mayoría de los casos, el proceso de reposición opera de la manera más eficiente si Exchange elige un servidor de reposición automáticamente. La mayor parte de las implementaciones de Exchange no precisan un servidor de reposición preferido. El servicio técnico y el soporte al cliente de Microsoft pueden proporcionar un script que establece un servidor de reposición preferido si su implementación lo requiere.

3. Según el costo de transporte (de menor a mayor). Los servidores del mismo grupo de enrutamiento tienen prioridad sobre los servidores en sitios de Active Directory remotos.

4. Según la versión de Exchange (de más a menos reciente).

5. Según el número de cambios necesarios disponibles en el servidor (de mayor a menor). Los servidores que no contengan ninguno de los cambios que faltan se eliminan de la lista.

Si un servidor no contiene todos los cambios necesarios, Exchange elige el siguiente servidor en la lista ordenada y también envía una solicitud de reposición a ese servidor. Este proceso se repite hasta que se soliciten todos los cambios.

Si el servidor elegido no responde a la solicitud de reposición, la base de datos marca ese servidor como no disponible y repite el proceso de selección. Los servidores marcados como no disponibles descienden al final de la lista.

Solicitudes de estado y mensajes de estado

Además de la información de estado en cada mensaje de replicación, Exchange usa las solicitudes y los mensajes de estado para determinar si las carpetas públicas deben emitir solicitudes de reposición.

Una base de datos de carpetas públicas envía una solicitud de estado en las siguientes circunstancias:

• Se notifica a la base de datos un cambio en la lista de bases de datos que hospedan réplicas de una carpeta. Por ejemplo, si agrega una base de datos a la lista o la quita, Exchange replica este cambio mediante mensajes de actualización de jerarquía. En este caso, la base de datos envía una solicitud de estado que requiere que respondan todas las bases de datos que contengan una réplica de la carpeta.

• Se inicia una base de datos nueva por primera vez. En este caso, la base de datos solicita el estado de la jerarquía de carpetas públicas. La base de datos envía una solicitud de estado que requiere que respondan todas las bases de datos usadas por el árbol de carpetas públicas.

• Una base de datos que se ha restaurado mediante Copia de seguridad de Windows Server se inicia por primera vez después de completarse la restauración. En este caso, la base de datos solicita el estado de la jerarquía de carpetas públicas y de todas las carpetas para las que la base de datos incluya réplicas de contenido. Esta solicitud de estado enumera dos o tres bases de datos como bases de datos de las que se precisa respuesta. Se necesitan respuestas de las bases de datos usadas por esta jerarquía y que, según un proceso de elección interno, son orígenes de confianza de contenido de carpetas.

Para indicar el estado actual de una carpeta concreta en la base de datos que envía el mensaje, la base de datos de carpetas públicas envía un mensaje de estado a otra base de datos en estas circunstancias:

• En respuesta a una solicitud de estado enviada por otra base de datos. El mensaje de estado solo se envía a la base de datos solicitante y solo si se cumplen estas condiciones:

  • La base de datos que recibió la solicitud de estado está en la lista de solicitudes de respuesta requerida.

  • La tabla de estado de replicación indica que la base de datos que recibió la solicitud de estado tiene actualizaciones que faltan en la base de datos que envió la solicitud.

• No hubo actualizaciones posteriores 24 horas después de que se recibió la última actualización de una carpeta. Cada vez que la base de datos recibe una actualización a una carpeta específica, el temporizador se restablece a 24 horas. Este mensaje de estado se envía a las otras bases de datos de carpetas públicas que contienen réplicas de la carpeta actualizada.

Si una base de datos de carpetas públicas recibe un mensaje de estado que indica que la base de datos que lo envía tiene información más reciente sobre la carpeta, la base de datos receptora crea una solicitud de reposición. Si resulta que los números de cambio son iguales (o los del servidor receptor son más recientes), no se lleva a cabo ninguna acción. Por ejemplo, cuando se inicia una nueva base de datos de carpetas públicas por primera vez, envía mensajes de solicitud de estado a todas las bases de datos usadas por la jerarquía de carpetas públicas. Cada base de datos responde con información sobre el estado de la jerarquía (según el seguimiento en esa base de datos). La nueva base de datos usa esta información para identificar las réplicas que debería tener (si las hay). Después, la nueva base de datos puede enviar solicitudes de reposición para obtener el contenido de las réplicas.

Volver al principio

Ejemplos de ciclos de replicación

La siguiente ilustración muestra un escenario simplificado de dos servidores con la secuencia de eventos que tiene lugar cuando se agrega una réplica de contenido a una base de datos de carpetas públicas. Esta acción agrega la base de datos de carpetas públicas a la lista de réplicas de la carpeta. Observe que la secuencia de pasos depende de factores tales como los tiempos de los intervalos de replicación y la topología de enrutamiento.

Secuencia de eventos cuando agrega una réplica a una base de datos de carpetas públicas

Los detalles del proceso son los siguientes:

1. Trabajando en ExServ01, un administrador agrega ExServ01 a la lista de réplicas de una carpeta.

2. ExServ01 envía un mensaje de jerarquía.

3. ExServ02 agrega ExServ01 a la copia local de la lista de réplicas de la carpeta.

4. ExServ01 envía una solicitud de estado a ExServ02.

5. ExServ02 envía un mensaje de estado a ExServ01 que incluye el CNSet completo de la carpeta.

6. ExServ01 determina que falta todo el contenido de la carpeta y registra las entradas correspondientes en la matriz de reposición.

7. Si el contenido sigue faltando una vez transcurrido el tiempo de espera de reposición, ExServ01 crea una solicitud de reposición y la envía a ExServ02.

8. ExServ02 compila los mensajes de contenido y los envía a ExServ01.

9. ExServ01 usa los mensajes de contenido entrantes para actualizar el contenido de las carpetas y la información de seguimiento relacionada.

10. Si sigue pareciendo que faltan números de cambio, ExServ01 espera 24 horas y envía una solicitud de reposición actualizada. Si hay un servidor diferente de ExServ02 disponible, es posible que ExServ01 envíe la solicitud a ese servidor.

La siguiente ilustración muestra un escenario simplificado de dos servidores con la secuencia de eventos que tiene lugar cuando se quita una réplica de una base de datos de carpetas públicas. Esta acción quita la base de datos de carpetas públicas de la lista de réplicas de la carpeta. Observe que la secuencia de pasos depende de factores tales como el número de servidores en la topología.

Secuencia de eventos cuando quita una réplica de una base de datos de carpetas públicas

Los detalles del proceso son los siguientes:

1. Trabajando en ExServ01, un administrador quita ExServ01 de la lista de réplicas de una carpeta.

2. ExServ01 marca su réplica (la copia de la carpeta en ExServ01) como pendiente de eliminación.

   Los clientes ya no pueden tener acceso a la carpeta mediante esta base de datos.

3. ExServ01 envía un mensaje de jerarquía.

4. ExServ02 actualiza su copia de la lista de réplicas de la carpeta para mostrar que la carpeta se encuentra en estado pendiente de eliminación en ExServ01.

   ExServ02 ya no remite a los clientes que busquen esta carpeta a ExServ01.

5. ExServ01 envía una solicitud de estado a ExServ02.

6. ExServ02 envía un mensaje de estado a ExServ01. Si la réplica en ExServ02 no está actualizada, ExServ02 coloca las entradas adecuadas en la matriz de reposición. En un plazo de cinco minutos, ExServ02 envía la solicitud de reposición correspondiente a ExServ01.

7. ExServ01 comprueba que la réplica de carpeta en ExServ02 contenga toda la información que contiene la réplica pendiente de eliminación. Si no la contiene, ExServ01 envía las actualizaciones de contenido correspondientes y vuelve al paso 5. De lo contrario, ExServ01 procede al paso 8.

   Este procedimiento garantiza que, siempre que existan otras réplicas, la eliminación de una sola réplica no ocasione pérdida de contenido.

8. ExServ01 marca su réplica con eliminar ahora. En el siguiente ciclo de mantenimiento, se quitará la réplica de ExServ01.

9. ExServ01 envía un mensaje de jerarquía.

10. ExServ02 quita ExServ01 de su copia de la lista de réplicas de la carpeta.

Volver al principio

Procedimientos recomendados para la implementación de la replicación

La replicación de carpetas públicas en Exchange puede ser una operación que use muchos recursos. La replicación necesita recursos de red, CPU y disco para funcionar. Si implementa una solución que permite una replicación de carpetas públicas eficiente, especialmente en organizaciones en que dichas carpetas se usan con frecuencia, puede mejorar notablemente la carga de disco, la CPU y la red en la organización de Exchange.

Por lo general, se recomienda minimizar la replicación en la organización. De esta manera, reducirá la cantidad de datos que viajen por la red. Además, puede contribuir a garantizar que sea menos probable que varios usuarios tengan acceso a diferentes versiones de los datos en varias réplicas. Sin embargo, observe que, al minimizar la replicación, disminuye la disponibilidad de los datos de carpetas públicas porque hay menos réplicas de la carpeta disponibles para los clientes si se produce un error en una base de datos de carpetas públicas. Si se requiere disponibilidad a gran escala para los datos de una carpeta pública específica, es posible que requiera un mayor nivel de replicación.

Volver al principio

 © 2010 Microsoft Corporation. Reservados todos los derechos.