Puede producirse pérdida de datos durante la migración de carpetas públicas a Exchange 2013, 2016 de Exchange o Exchange Online

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3161916
Síntomas
Si está utilizando migración de loteo serie migración migrar carpetas públicas de Microsoft Exchange Server 2007 o Microsoft Exchange Server 2010 para Exchange Server 2013, 2016 de Exchange Server o Exchange Online, la pérdida de datos puede producirse si no están todas las réplicas de la carpeta en la base de datos principal (el servidor de base de datos principal que se conecta el servicio de migración). Se copian todos los datos que está actualmente primero en las carpetas que se migran, pero se pueden perder los cambios incrementales que se han registrado después de la sincronización inicial.

Escenario de ejemplo

Suponga que tiene dos carpetas públicas bases de datos, PFDB1 y PFDB2, que se ejecutan en servidores de Exchange 2007 o Exchange 2010. Asimismo, dispone de dos carpetas, F1 y F2. Carpeta F1 tiene una réplica en PFDB1 y carpeta F2 tiene una réplica en PFDB2.

Al iniciar la migración y especifica PFDB1 como la base de datos al que conectarse en el cmdlet de New -MigrationEndpoint , se copian todos los datos de las carpetas, F1 y F2 durante la sincronización inicial (como se muestra en la figura 1). Esto ocurre incluso si la PFDB1 no tiene una réplica local de la carpeta F2.

Después de este primer proceso de sincronización, se preparan para la última sincronización y empezar a completar el lote. Se espera que todos los datos que se agregan a la carpeta F1 y F2 después de la primera sincronización debe copiarse sobre durante la última sincronización.

Diagrama que muestra esa carpeta F1 y F2 del origen se copia en el destino durante la sincronización inicial.
La figura 1. Carpeta F1 y F2 del origen se copia en el destino durante la primera sincronización.

Problema
Durante la sincronización incremental y final, los datos incrementales desde la carpeta F2 no se copian a las carpetas públicas moderno (como se muestra en la figura 2). Esto es porque PFDB1 se especifica como el extremo. Statusis de lote que se muestra como sincronizado. Sin embargo, los datos nuevos que se ha agregado a la carpeta F2 después de la primera sincronización no se copian a las carpetas públicas modernas.

Además, si existen las nuevas carpetas que se agregan a PFDB2 después de la primera sincronización (carpeta F3 en la figura 2), el contenido de dichas carpetas no sin copiado cualquiera. (Esto ocurre aunque se muestre la carpeta F3 en la jerarquía).

Diagrama que muestra que los datos incrementales carpeta F1 se copia y no se copian los cambios a la carpeta F2. Datos en la carpeta recién agregada F3 no se copian, pero la carpeta aparecen en la jerarquía.
La figura 2. Se copian los datos incrementales a carpeta F1 y no se copian los cambios a la carpeta F2. Aunque no se copian los datos en la carpeta recién agregado F3, aparece la carpeta en la jerarquía.
Solución
Antes de iniciar la migración por lotes, asegúrese de que todas las carpetas públicas tienen una réplica en la base de datos de carpetas públicas que se especificará como origen para la migración. Además, asegúrese de que la replicación pública está sincronizada.

Solución para el escenario de ejemplo

Para evitar este problema, agregue una réplica de carpetas F2 y F3 en PFDB1, asegúrese de que la replicación de carpetas públicas está sincronizada y, a continuación, iniciar la migración de lote. Esto garantiza que los datos incrementales se copian (sin tener en cuenta qué réplica originalmente escribirlo en).

Somos conscientes de que esta solución no funcionará para algunos clientes debido al tamaño de la distribución de carpetas públicas. Si estás en esta situación, recomendamos que espere hasta que se solucione el problema antes de ejecutar una migración.

PREGUNTAS MÁS FRECUENTES

Q:Cuando se inició este problema que se produzca?
A: primero ha observado este problema en 1 acumulativo de actualizaciones de Exchange Server 2013, 2016 versión RTM de Exchange Server y Exchange Online.

Q: qué datos perder?
A: informe de la Sra., buscar "informó de los cambios de jerarquía de carpetas en el origen," Seleccione el primer elemento "informó de los cambios de jerarquía de carpetas de origen" que aparece y, a continuación, seleccione la fecha y hora que está asociado con el registro. Se perderá cualquier dato que se agrega a la carpeta F2 o todas las carpetas nuevas que se agregan a PFDB2 después de este tiempo.

Q: todavía tengo mis bases de datos de carpetas públicas de Exchange Server 2007 o Exchange Server 2010 en su estado bloqueado ya que realizamos la migración a Exchange Server 2013, 2016 de Exchange Server o a Exchange Online. ¿Puedo migrar todavía Mis datos perdidos?
A: sólo es posible una copia manual de los datos.

Q: Mi migración tomaba semanas al estado de listo para completar lleguen. ¿Tengo que volver a empezar?
A: No, no tienes que reiniciar la migración de carpetas públicas. Cuando se completan las revisiones y las actualizaciones se instalan en el servidor (o en los servidores de Exchange Online, si va a migrar a Exchange Online), la migración puede captar desde donde está ahora y migrará los datos restantes. Deberá reiniciar el proceso de migración. Sin embargo, al hacerlo, el proceso busca cambios y no empezar de nuevo. Un lote de migración comienza de nuevo sólo si eliminar y volver a crearla.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3161916 - Última revisión: 06/24/2016 07:57:00 - Revisión: 4.0

Exchange Server 2016 Enterprise Edition, Exchange Server 2016 Standard Edition, Microsoft Exchange Server 2013 Enterprise, Microsoft Exchange Server 2013 Standard, Microsoft Exchange Online

  • kbsurveynew kbbug o365 kbgraphic kbgraphxlink kbmt KB3161916 KbMtes
Comentarios