A solicitação de movimentação da caixa de correio do Exchange de 2013 para 2016 fica presa na Semeadura inicial

2

Estou no meio da migração do Exchange 2013 para 2016. A maioria dos movimentos deu certo, no entanto, algumas caixas de correio parecem estar ficando presas em Semente inicial e depois de algumas horas de parar aqui, falhar em FailedStuck .

A execução de Get-MailboxStatistics -IncludeReport mostra que a movimentação está paralisada executando o IsInteg porque são caixas de correio grandes. Isso parece ser basicamente um New-MailboxRepairRequest que fica na fila indefinidamente.

Eu posso executar New-MailboxRepairRequest com -Force e ele será concluído imediatamente, então acho que é apenas um problema de gerenciamento da carga de trabalho, mas já faz alguns dias e os reparos ainda não estão concluídos.

Soluções possíveis

  • Como posso dizer a New-MoveRequest para ignorar a execução inicial do IsInteg? Terei prazer em executá-los manualmente após a mudança.

  • Como posso editar as Solicitações de reparo de caixa de correio que as solicitações de movimentação criam com o sinalizador -Force? Tanto quanto eu posso dizer que não há Set-MailboxRepairRequest .

  • Como posso desativar o gerenciamento de carga de trabalho para solicitações de reparo de caixa de correio? Como isso parece ser o que está atrasando meus movimentos / reparos, mesmo quando nada está acontecendo (é o fim de semana às 4 da manhã no novo hardware, e eles não vão ceder).

  • Como posso aumentar o limite "Large Mailbox" (a mensagem abaixo faz alusão a ele como uma opção de configuração). Se eu configurá-lo para algo como 50 GB, todas as caixas de correio serão movidas sem fazer um reparo.

Mais informações

O relatório mostra:

Report : 18/03/2017 12:34:12 AM [EXCH16-SYD-01] Setting up ISInteg repair run upfront for this mailbox since it's a large mailbox. 
"Primary mailbox size = 11120110046, Archive mailbox size = 0, Large mailbox size threshold config value = 10737418240

Então:

18/03/2017 12:54:33 AM [EXCH16-SYD-01] Store IsInteg task is pending completion for mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536'. IsInteg

O relatório repete isso por horas, até que, eventualmente, expira porque nenhum progresso foi feito. Eu finalmente encontrei que há um correspondente

Para provar que o gerenciamento de carga de trabalho está causando problemas, verifiquei todas as solicitações de reparo de caixa de correio em todas as caixas de correio e confirmei que nenhuma delas estava em andamento.

[PS] C:\Windows\system32>Get-Mailbox -Server EXCH01-SYD | Foreach { Get-MailboxRepairRequest -Mailbox $_.PrimarySMTPAddress.tostring() }

Identity Task Detect Only Job State Progress
-------- ---- ----------- --------- --------
62d54094-6b61-4f1c-a... {MessageId} False Queued 0
...
62d54094-6b61-4f1c-a... {FolderView} False Queued 0

Há 29 reparos aqui, todos eles estão enfileirados.

Coisas a serem observadas

  • Isso só acontece com caixas de correio com mais de 10 GB de tamanho, porque esse é o limite que faz com que uma tarefa IsInteg seja executada antes da movimentação.

  • É o IsInteg que está fazendo com que as coisas fiquem retidas. No entanto, se eu fizer um reparo do IsInteg com -Force , o reparo acontecerá imediatamente.

  • Mesmo para os reparos do IsInteg que eu posso fazer com -Force (que são bem-sucedidos), não vejo entradas de log de eventos como deveria .

  • Meu ambiente é 1x 2013 Exchange e 2x 2016 Exchanges e 1x 2010 Exchange. Todos estão executando a versão mais recente CU ou RU.

  • Mover a partir de 2010 não é um problema, mesmo para caixas de correio > 10 GB.

  • Estou em Coexistência há algumas semanas e migrei minha própria caixa de correio de 2013 para 2016 como um teste. Minha caixa de correio tem 15 GB e não foi enfileirada. Isso me leva a pensar que se eu fosse paciente o suficiente, os outros poderiam ter sucesso. Mas minha caixa de correio não mostrava FailedStuck e mostrava progresso constante.

  • Eu estou querendo saber se eu preciso acabar com todos os movimentos fracassados (agora eu simplesmente os retomei) e re-tentá-los um por um.

Eu sinto como se tivesse esgotado a maioria das minhas opções, então qualquer conselho é apreciado. Mesmo que alguém possa me dizer como executar algumas das "soluções possíveis" listadas. Como estas são apenas soluções teóricas para mim, não encontrei maneiras de realmente fazê-las.

    
por Geekman 19.03.2017 / 16:25

1 resposta

1

Encontrei uma solução simples para esse problema: faça downgrade de sua caixa do Exchange 2013.

Como parte do meu plano de migração, também tivemos 2013 em seu próprio DAG de dois nós. O segundo nó era novinho em folha e foi corrigido até a última UC da época:

AdminDisplayVersion: versão 15.0 (compilação 1236.3) (Exchange 2013 CU14)

O antigo nó de 2013 foi corrigido o suficiente para a coexistência de 2016:

AdminDisplayVersion: versão 15.0 (compilação 1178.4) (Exchange 2013 CU12)

Lembrei-me de que, antes de criar a nova caixa 2013, consegui migrar algumas caixas de correio de 15 GB até 2016 sem problemas.

Durante o curso de minhas migrações, eu tinha ativado todos os bancos de dados de caixa de correio no novo nó, então é claro que a versão CU no novo nó significava que todos os movimentos futuros de caixa de correio exigiam um reparo de caixa de correio quando & gt ; 10 GB.

A diferença é: para o nível de patch de CU mais antigo, não é necessário reparo de caixa de correio superior a 10 GB . Semelhante ao Exchange 2010 nesse sentido. Então, porque nenhum reparo / entrada ocorreu, o movimento é bem-sucedido. Não sei exatamente em que ponto o Exchange 2013 começou a exigir uma verificação IsInteg como parte da migração. Eu também não tenho certeza se isso é "corrigido" em versões posteriores.

Se for necessário fazer o downgrade para uma UC mais baixa, você poderá criar uma nova caixa 2013, configurar um DAG e migrar todos os bancos de dados para as versões mais antigas.

Você pode ver, comparando os relatórios de solicitação de movimentação, que IsInteg é executado antes que qualquer tentativa seja feita para começar a transferir os dados da caixa de correio, e é por isso que tudo fica paralisado.

Veja um trecho de uma solicitação de movimentação que falhou devido à verificação IsInteg:

    18/03/2017 12:34:12 AM [EXCH16-SYD-01] Setting up ISInteg repair run upfront for this mailbox since it's a large mailbox. "Primary mailbox size = 11120110046, Archive mailbox size = 0, Large mailbox size threshold config value = 10737418240

    ...

    18/03/2017 12:52:58 AM [EXCH16-SYD-01] Connected to source mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536 (Primary)', database
    18/03/2017 12:52:58 AM [EXCH16-SYD-01] Started Store IsInteg task for mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536'. IsInteg RequestGuid = 'd783655f-7e84-4afb-b6a3-0669e750041a'.
    18/03/2017 12:53:33 AM [EXCH16-SYD-01] Store IsInteg task is pending completion for mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536'. IsIntegRequestGuid = 'd783655f-7e84-4afb-b6a3-0669e750041a'. Percentages complete: 0 .
    18/03/2017 12:54:03 AM [EXCH16-SYD-01] Store IsInteg task is pending completion for mailbox '6e6a0983-02ab-4d1d-84ea-d0071e7e6536'. IsIntegRequestGuid = 'd783655f-7e84-4afb-b6a3-0669e750041a'. Percentages complete: 0 .

Veja um trecho de uma solicitação de mudança que funcionou, de 2013 a 2016:

   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Connected to source mailbox '9a45c915-a87e-4211-8539-35034be5c0eb (Primary)', database

   ...

   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Request processing started.
   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Source mailbox information:
   Regular Items: 28128, 4.865 GB (5,223,415,468 bytes)
   Regular Deleted Items: 134, 8.387 MB (8,794,863 bytes)
   FAI Items: 440, 2.627 MB (2,754,276 bytes)
   FAI Deleted Items: 0, 0 B (0 bytes)
   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Source archive mailbox information:
   Regular Items: 52386, 11.77 GB (12,639,788,901 bytes)
   Regular Deleted Items: 0, 0 B (0 bytes)
   FAI Items: 1, 2.658 KB (2,722 bytes)
   FAI Deleted Items: 0, 0 B (0 bytes)
   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Cleared sync state for request
   9a45c915-a87e-4211-8539-35034be5c0eb due to 'CleanupOrphanedMailbox'.
   2/04/2017 8:22:30 PM [EXCH16-SYD-01] Cleared sync state for request
   f33ab71d-170b-4d55-bbfb-a9bb65db2fdc due to 'CleanupOrphanedMailbox'.
   2/04/2017 8:22:31 PM [EXCH16-SYD-01] Stage: CreatingFolderHierarchy.
   Percent complete: 10.
   2/04/2017 8:22:32 PM [EXCH16-SYD-01] Initializing folder hierarchy from
   mailbox '9a45c915-a87e-4211-8539-35034be5c0eb (Primary)': 1146 folders
   total.
   2/04/2017 8:22:32 PM [EXCH16-SYD-01] Folder creation progress: 0 folders
   created in mailbox '9a45c915-a87e-4211-8539-35034be5c0eb (Primary)'.
   2/04/2017 8:23:02 PM [EXCH16-SYD-01] Folder hierarchy initialized for
   mailbox '9a45c915-a87e-4211-8539-35034be5c0eb (Primary)': 1145 folders
   created.
   2/04/2017 8:23:02 PM [EXCH16-SYD-01] Initializing folder hierarchy from
   mailbox 'f33ab71d-170b-4d55-bbfb-a9bb65db2fdc (Archive)': 846 folders total.
   2/04/2017 8:23:22 PM [EXCH16-SYD-01] Folder hierarchy initialized for
   mailbox 'f33ab71d-170b-4d55-bbfb-a9bb65db2fdc (Archive)': 845 folders
   created.
   2/04/2017 8:23:22 PM [EXCH16-SYD-01] Stage: CreatingFolderHierarchy.
   Percent complete: 10.
   2/04/2017 8:23:22 PM [EXCH16-SYD-01] Stage: CreatingInitialSyncCheckpoint.
   Percent complete: 15.
   2/04/2017 8:23:22 PM [EXCH16-SYD-01] Initial sync checkpoint progress:
   0/1146 folders processed. Currently processing mailbox
   '9a45c915-a87e-4211-8539-35034be5c0eb (Primary)'.
   2/04/2017 8:24:06 PM [EXCH16-SYD-01] Initial sync checkpoint completed:
   1970 folders processed.
   2/04/2017 8:24:06 PM [EXCH16-SYD-01] Stage: LoadingMessages. Percent
   complete: 20.
   2/04/2017 8:24:06 PM [EXCH16-SYD-01] Stage: LoadingMessages. Percent
   complete: 20.
   2/04/2017 8:29:06 PM [EXCH16-SYD-01] Stage: CopyingMessages. Percent
   complete: 27.
   2/04/2017 8:29:06 PM [EXCH16-SYD-01] Copy progress: 4546/81089 messages,
   653.3 MB (684,996,208 bytes)/16.65 GB (17,874,496,811 bytes), 11/846
   folders completed.
   2/04/2017 8:34:10 PM [EXCH16-SYD-01] Stage: CopyingMessages. Percent
   complete: 28.
   2/04/2017 8:34:10 PM [EXCH16-SYD-01] Copy progress: 5536/81089 messages,
   818.5 MB (858,269,612 bytes)/16.65 GB (17,874,496,811 bytes), 11/846
    
por 13.04.2017 / 15:59