Poderá ocorrer perda de dados durante a migração de pasta pública para troca de 2013, Exchange 2016 ou Exchange Online

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 3161916
Sintomas
Se estiver a utilizar migração de batchou série migração para migrar pastas públicas do Microsoft Exchange Server 2007 ou Microsoft Exchange Server 2010, a perda de dados do Exchange Server 2013, 2016 do Exchange Server ou Exchange Online, poderá ocorrer se todas as réplicas de pastas não estão na base de dados primário (o servidor de base de dados primário que liga o serviço de migração). Todos os dados que está presentemente primeiro em pastas que estão a ser migradas são copiados, mas podem perder as alterações incrementais registados após a sincronização inicial.

Cenário de exemplo

Suponha que tem duas pastas públicas bases de dados, PFDB1 e PFDB2, que são executadas nos servidores do Exchange 2007 ou 2010 do Exchange. Além disso, tem duas pastas, F1 e F2. Pasta F1 tem uma réplica no PFDB1 e pasta F2 tem uma réplica no PFDB2.

Quando iniciar a migração e especificar PFDB1 como a base de dados para ligar para o cmdlet New -MigrationEndpoint , todos os dados das pastas F1 e F2 é copiado durante a sincronização inicial (conforme ilustrado na figura 1). Isto ocorre mesmo que PFDB1 não tem uma réplica local da pasta F2.

Após este processo de sincronização primeiro, preparar para a sincronização final e começar a concluir do lote. Pensa que quaisquer dados que são adicionados à pasta F1 e F2 após a primeira sincronização deve ser copiada através de durante a sincronização final.

Diagrama mostrando nessa pasta F1 e F2 da origem é copiado para o destino durante a sincronização inicial.
Figura 1. Pasta F1 e F2 da origem é copiado para o destino durante a primeira sincronização.

Problema
Durante a sincronização incremental e final, os dados incrementais da pasta F2 não são copiados para as pastas públicas modernos (conforme ilustrado na figura 2). Isto acontece porque o PFDB1 é especificado como o ponto final. Statusis o lote apresentado como sincronizadas. No entanto, quaisquer novos dados que foi adicionados à pasta F2 após a primeira sincronização não são copiados para pastas públicas modernas.

Além disso, se existirem quaisquer novas pastas que são adicionadas à PFDB2 após a primeira sincronização (pasta F3 na figura 2), o conteúdo dessas pastas não será copiado quer. (Isto acontece mesmo que a pasta F3 é apresentada na hierarquia).

Diagrama que mostra que os dados incrementais para pasta F1 é copiado e as alterações à pasta F2 não serão copiadas. Dados na pasta adicionada recentemente não for copiado F3 mas a pasta é apresentado na hierarquia.
Figura 2. Os dados incrementais para pasta F1 são copiados e as alterações à pasta F2 não são copiadas. Apesar de não são copiados os dados na pasta recentemente adicionado F3, aparece a pasta na hierarquia.
Como contornar
Antes de iniciar a migração de batch, certifique-se de que todas as pastas públicas têm uma réplica da base de dados de pasta pública que irá ser especificado como a origem de migração. Além disso, certifique-se de que a replicação pública está sincronizada.

Solução para o cenário de exemplo

Para contornar este problema, adicione uma réplica das pastas F2 e F3 PFDB1, certifique-se de que a replicação pasta pública está sincronizada e, em seguida, iniciar a migração de batch. Isto torna-se de que os dados incrementais são copiados (independentemente de qual réplica está originalmente escrito).

Temos consciência de que esta solução alternativa não funcionará com alguns clientes devido ao tamanho da implementação de pasta pública. Se estiver nesta situação, recomendamos que aguarde até o problema é corrigido antes de executar uma migração.

PERGUNTAS MAIS FREQUENTES

Q:Quando este problema se iniciou a ocorrer?
A: este problema foi primeiro observado no Exchange Server 2013 cumulativa actualização 1, Exchange Server de 2016 RTM e no Exchange Online.

Q: os dados que potencialmente perde-se?
A: relatório no casados de FRESCO, procura por "alterações de hierarquia da pasta comunicado na origem," Seleccione o primeiro item de "alterações de hierarquia da pasta comunicado na origem" listado e, em seguida, seleccione a data e hora em que está associada ao registo. Perdem-se quaisquer dados que são adicionados à pasta F2 ou quaisquer novas pastas que são adicionadas PFDB2 após este período de tempo.

Q: ainda existe minhas bases de dados pastas públicas do Exchange Server 2007 ou 2010 de servidor do Exchange no seu estado de bloqueada uma vez que podemos migradas para o Exchange Server 2013, 2016 do Exchange Server ou Exchange Online. Posso ainda migrar os dados perdidos?
A: só é possível uma cópia dos dados manual.

Q: minhas migração demorou semanas para o estado de preparado para concluir reachthe. É necessário recomeçar?
A: não, não tem de reiniciar a migração de pastas públicas. Quando estiverem concluídas as correcções e as actualizações estão instaladas no servidor (ou nos servidores de Exchange Online, se estiver a migrar para o Exchange Online), a migração pode ser retirada onde é agora e irá migrar os restantes dados. Poderá ter de reiniciar o processo de migração. No entanto, ao fazê-lo, o processo de procura para que as alterações e não começar de novo. Um lote de migração recomeça apenas se a eliminar e, em seguida, volte a criá-la.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3161916 - Última Revisão: 06/24/2016 12:48:00 - Revisão: 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 KbMtpt
Comentários