Você está offline; aguardando reconexão

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

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 3161916
Sintomas
Se você estiver usando migração de loteou serial migração para migrar pastas públicas do Microsoft Exchange Server 2007 ou Microsoft Exchange Server 2010 para Exchange Server 2013, 2016 do Exchange Server ou o Exchange Online, perda de dados pode ocorrer se todas as réplicas de pasta não estão no banco de dados principal (o servidor de banco de dados principal, conecta-se ao serviço de migração). Todos os dados que estão no primeiro momento nas pastas que estão sendo migradas são copiados, mas quaisquer alterações incrementais que foram lançadas após a sincronização inicial podem ser perdidas.

Cenário de exemplo

Suponha que você tenha duas pastas públicas bancos de dados, PFDB1 e PFDB2, que são executados em servidores Exchange 2007 ou Exchange 2010. Além disso, você tem duas pastas, F1 e F2. Pasta F1 tem uma réplica em PFDB1 e pasta F2 tem uma réplica em PFDB2.

Quando você iniciar a migração e especificar PFDB1 como o banco de dados para conectar-se para o cmdlet New -MigrationEndpoint , todos os dados das pastas F1 e F2 é copiada durante a sincronização inicial (conforme mostrado na Figura 1). Isso ocorre mesmo que PFDB1 não tem uma réplica local de pasta F2.

Após esse primeiro processo de sincronização, preparar-se para a sincronização final e inicie a conclusão do lote. Você espera que todos os dados que são adicionados à pasta F1 e F2 após a primeira sincronização deve ser copiada sobre durante a sincronização final.

Diagrama mostrando a pasta F1 e F2 da origem é copiado para o destino durante a sincronização inicial.
A 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 pastas públicas modernas (como mostrado na Figura 2). Isso ocorre porque PFDB1 é especificado como o ponto de extremidade. O statusis de lote exibido como sincronizado. No entanto, quaisquer dados novos que foram adicionados à pasta F2 após a primeira sincronização não são copiados para pastas públicas modernas.

Além disso, se houver qualquer novo pastas são adicionadas ao PFDB2 após a primeira sincronização (pasta F3 na Figura 2), o conteúdo dessas pastas não será copiado ou. (Isso é verdadeiro mesmo que pasta F3 é exibida na hierarquia).

Diagrama mostrando que os dados incrementais pasta F1 é copiado e alterações a pasta F2 não são copiadas. Dados na pasta recém-adicionado F3 não é copiado, mas a pasta aparece na hierarquia.
A Figura 2. Dados incrementais para pasta F1 são copiados e alterações a pasta F2 não são copiadas. Embora os dados na pasta recém-adicionado F3 não são copiados, a pasta aparece na hierarquia.
Como Contornar
Antes de começar a migração de lote, certifique-se de que todas as pastas públicas possuem uma réplica do banco de dados de pasta pública será especificado como a origem para a migração. Além disso, certifique-se de que a replicação pública está em sincronia.

Solução alternativa para o cenário de exemplo

Para contornar esse problema, adicione uma réplica de pastas F2 e F3 em PFDB1, certifique-se de que replicação da pasta pública está em sincronia e inicie a migração de lote. Isso garante que os dados incrementais são copiados (independentemente de qual réplica for originalmente gravado).

Sabemos que essa solução alternativa não funcionará para alguns clientes devido ao tamanho da implantação de pasta pública. Se você estiver nessa situação, recomendamos que você aguarde até que o problema seja corrigido antes de executar uma migração.

Perguntas Freqüentes

Q:Quando este problema começou a ocorrer?
A: esse problema foi observado pela primeira vez no Exchange Server 2013 atualização cumulativa 1, RTM do Exchange Server 2016 e on-line do Exchange.

P: quais dados potencialmente perco?
A: a SRTA no relatório, pesquise por "informado alterações na hierarquia de pastas na origem," Selecione o primeiro item "informado alterações na hierarquia de pasta da fonte" que está listado e, em seguida, selecione a data e hora que está associado o log. Todos os dados que são adicionados à pasta F2 ou todas as pastas que são adicionadas ao PFDB2 após esse período serão perdidas.

P: ainda tenho meus bancos de dados de pasta pública do Exchange Server 2007 ou o Exchange Server 2010 no estado bloqueado como migramos para Exchange Server 2013, 2016 do Exchange Server ou o Exchange Online. Posso migrar meus dados perdidos ainda?
A: somente uma cópia dos dados do manual é possível.

P: Minha migração levava semanas para reachthe estado de pronto para concluir. É necessário recomeçar?
A: não, não é necessário reiniciar a migração de pasta pública. Quando forem concluídas as correções e as atualizações são instaladas em seu servidor (ou nos servidores Exchange Online, se você estiver migrando para o Exchange Online), a migração pode ser retirada da qual é agora e ele migrará os dados restantes. Você talvez precise reiniciar o lote de migração. No entanto, quando você fizer isso, o processo de procura de alterações e não recomeçar. Um lote de migração será reiniciada somente se você excluir e, em seguida, recriá-la.

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3161916 - Última Revisão: 09/20/2016 19:39:00 - Revisão: 5.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