A migração do Exchange de 2003 para 2010 está me dando um inferno

Question

Então, eu tenho duas máquinas:

• Exchange 2003 - Versão 6.0 (Build 7654.0) 4 GB de RAM, MDB de 55 GB, Server 2003
• Exchange 2010 - Versão 14.3 (Build 123.0) 8 GB de RAM, 22 GB MDB, Server 2008 R2

Existem aproximadamente 80 caixas de correio entre os dois servidores.

De acordo com o título da pergunta, estou movendo todos os meus usuários de 2003 para 2010. Mudei cerca de 50% dos meus usuários, mas continuo ficando preso em alguns.

Vamos começar pelo que realmente está acontecendo:

• O MoveRequest local é iniciado e parece funcionar sem problemas
• Na metade da movimentação, o banco de dados da caixa de correio Target é desmontado
• Quando tento remontar o banco de dados, ele diz que há um arquivo de log ausente.
• Mesmo se ignorar o fato de o arquivo de log estar ausente e aceitar a perda de dados, ainda não consigo montá-lo novamente até remover o pedido de movimentação, tentar montá-lo (e falhar) e redefinir o serviço Armazenamento de Informações. / li>

Coisas que tentei:

• Reparar o banco de dados com o ESEUTIL depois de inicialmente desmontar
• Aceitando 'BadItems' em caso de corrupção
• Tentei limpar o lixo eletrônico da conta manualmente e tentar novamente
• Limpando o banco de dados de destino com o EMS
• Criando um novo MDB para usar como um banco de dados de destino
• Cota de armazenamento removida da caixa de correio de origem

Como você pode ver, estou metaforicamente agitando meus braços em desespero para conseguir que isso funcione.

Alguma idéia?

Vou rodar o ISINTEG no meu servidor 2003 esta semana, para ver se consigo encontrar / consertar qualquer corrupção.

    

Answer 1

1. verifique se o Exchange 2010 registra porque é desmontado. Deve ter feito alguma coisa.
   • verifique o log de solicitação de movimentação - > EMC - > Configuração de destinatário - > Mover pedido - > clique com o botão direito do mouse na solicitação de movimentação e verifique o status / ou as propriedades que devem conter muitas informações.
   • verifique o log de eventos do sistema - > Eu acho que o evento sobre desmontar deve ir para o log do Windows - > log de aplicativos.
   • verificar todos os registros específicos da troca - > visualizador de eventos - > Aplicativos e registros de serviço - > Microsoft - > Troca
2. Sua versão sugere que você tenha um 2010 SP3 limpo. Pacote Cumulativo de Atualizações 3 Para o Exchange 2010 SP3 (KB2891587). Está faltando uma atualização importante do SP3 de postagem para o Exchange 2010. link
3. ative o log circular no banco de dados de destino. Isso deve reduzir drasticamente a quantidade de logs gerados durante um movimento.
4. check Você não está executando nenhuma cópia de sombra na unidade em que o registro do banco de dados / banco de dados do Exchange 2010 está localizado.
5. Exclua do seu antivírus o diretório em que o banco de dados e os registros do Exhcange 2010 estão localizados,
6. verifique o tamanho do banco de dados. Embora o padrão seja 1024 GB, mas apenas no caso de verificar essa chave de registro: link
7. verifique se o armazenamento em disco do Exchange 2010 está funcionando corretamente.
8. 8 GB não é muito nem RAM para o Exchange 2010. Verifique este link link - Se bem entendi Você tem todas as funções em um servidor. Eu tenho um semelhante sob o meu controle e eu designei esse servidor 20GB de memória RAM. 19280MB comido com relação ao store.exe - > 10 GB :). Apenas cerca de 250MB paginados. No entanto, ele estava correndo antes com 8GB, mas caiu uma vez por 2 semanas (hard lockup).

Answer 2

Como resposta à resposta do @ BartłomiejZarzecki:

1. Os logs disseram que o banco de dados não pôde encontrar o arquivo de log, tentou recuperar, mas como não tenho um DAG, ele não conseguiu. O banco de dados desmontado como resultado.
2. O pacote cumulativo de atualizações foi aplicado. Nenhuma mudança na migração, mesmo problema.
3. Registro circular ativado. Isso reduz significativamente o tamanho do log.
4. Não há cópias de sombra em execução.
5. O antivírus é executado no nível do hipervisor e é transparente para o próprio servidor, o que provavelmente não foi útil nesse caso, já que os arquivos de log foram selecionados como um Trojan Script e depois excluídos. Eu adicionei uma exceção e agora a migração funciona bem agora.
6. Todos os tamanhos de banco de dados estão definidos como padrão
7. O armazenamento em disco está bem; este servidor é uma máquina virtual.
8. Vou sugerir isso ao meu gerente, embora provavelmente não queiramos fazer isso porque não aproveitamos muito esse servidor:)