O seu browser não é suportado

Tem de atualizar o seu browser para utilizar o site.

Atualize para a versão mais recente do Internet Explorer

Poderá ocorrer perda de dados durante a migração de pasta pública para o Exchange de 2013, troca de 2016 e 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 batch ou série migração para migrar pastas públicas do Exchange Server 2007 ou o Exchange Server 2010, a perda de dados do Exchange Server 2013, 2016 do Exchange Server ou Exchange Online, poderá ocorrer se as réplicas dos todas as pastas não estiverem 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 é inicialmente presentes nas 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, em execução nos servidores do Exchange 2007 ou 2010 do Exchange. Além disso, suponha que 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 de Novo -MigrationEndpoint cmdlet, todos os dados da pasta F1 e F2 será copiado durante a sincronização inicial (conforme ilustrado na figura 1), apesar de PFDB1 não tem uma réplica local da pasta F2.

Após esta sincronização inicial, preparar para a sincronização final e iniciar a conclusão do lote. A expectativa é que todos os dados que são adicionados à pasta F1 e F2 depois de concluída a sincronização inicial devem ser copiados 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 sincronização inicial.

Problema
Durante a sincronização incremental e final, uma vez que PFDB1 for especificada como o ponto final, os dados incrementais da pasta F2 não são copiados para modernas pastas públicas (conforme ilustrado na figura 2). Estado de batch mostrará como sincronizado. No entanto, quaisquer novos dados que foi adicionados na pasta F2 após a primeira sincronização inicial 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 sincronização inicial (pasta F3 na figura 2), o conteúdo dessas pastas não será copiado quer. (Embora, a pasta F3 irá mostrar 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 serão copiadas. Dados na pasta adicionada recentemente não for copiado F3 mas a pasta é apresentado 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

Adicionar uma réplica da pasta F2 e F3 no PFDB1, certifique-se de replicação da pasta pública está sincronizada e, em seguida, iniciar a migração de batch. Isto garante que os dados incrementais são copiados através de (independentemente de qual réplica está originalmente escrito).

Temos consciência de que alguns clientes, isto não funcionar devido ao tamanho da sua implementação de pasta pública. Se estiver nesta situação, recomendamos que aguarde até o problema é corrigido antes de efectuar uma migração.
Estado
Trabalhamos actualmente uma correcção. A correcção envolve alterações Exchange de 2013, troca de 2016 e Exchange Online. As correcções estará disponíveis em 13 de actualização cumulativa do Exchange 2013 (CU13) e CU2 de 2016 do Exchange.

PERGUNTAS MAIS FREQUENTES

Q:Foi quando esta situação de início?
A: CU1 de 2013 do Exchange, Exchange 2016 RTM e Exchange Online.

Q: os dados que potencialmente perde-se?
A: relatório de na 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, escolha a data e hora em que está associada ao registo. Quaisquer dados que são adicionados à pasta F2 ou quaisquer novas pastas que são adicionadas PFDB2 após este período de tempo podem ser perdidas.

Q: ainda existe minhas bases de dados pastas públicas do Exchange 2007 ou 2010 do Exchange no seu estado bloqueado desde que foi migrado para o Exchange de 2013, troca de 2016 ou Exchange Online. Pode ainda obtenho o meu perdidos dados migrados?
A: só é possível uma cópia dos dados manual.

Q: minhas migração demorou semanas a obter no estado de preparado para concluir. É necessário recomeçar?
A: não, não terá 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 em servidores do Exchange Online, no caso de uma migração 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, mas reiniciar um lote de migração significa que deve procurar alterações e não começar de novo. Um lote de migração só seria recomeçar se eliminar e recriar o processo de migração.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3161916 - Última Revisão: 05/12/2016 23:22:00 - Revisão: 2.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