Назад | Перейти на главную страницу

Запрос на перемещение почтового ящика Exchange с 2013 на 2016 застревает при начальном заполнении

Я нахожусь в процессе перехода с Exchange 2013 на 2016. Большинство перемещений прошли успешно, однако некоторые почтовые ящики, похоже, застревают на Первоначальный посев, а затем после нескольких часов простоя здесь FailedStuck.

Бег Get-MailboxStatistics -IncludeReport показывает, что перемещение застряло при выполнении IsInteg, потому что это большие почтовые ящики. Похоже, это в основном New-MailboxRepairRequest это просто ставится в очередь на неопределенное время.

Я могу бегать New-MailboxRepairRequest с участием -Force и он будет завершен немедленно, поэтому я думаю, что это просто проблема управления рабочей нагрузкой, но прошло несколько дней, а ремонт все еще не завершен.

Возможные решения

Как я могу сказать New-MoveRequest пропустить запуск IsInteg заранее? Я с радостью запускаю их вручную после переезда.
Как я могу отредактировать запросы на восстановление почтового ящика, создаваемые запросами на перемещение, с помощью флага -Force? Насколько я могу судить, нет Set-MailboxRepairRequest.
Как отключить управление рабочей нагрузкой для запросов на ремонт почтовых ящиков? Похоже, это то, что тормозит мои переезды / ремонт, даже когда ничего не происходит (сейчас выходные в 4 часа утра на новом оборудовании, и они не сдвинутся с места).
Как я могу поднять порог «большого почтового ящика» (в сообщении ниже упоминается, что это параметр конфигурации). Если я установлю что-то вроде 50 ГБ, все почтовые ящики будут перемещены без ремонта.

Больше информации

Отчет показывает:

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

Затем:

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

Отчет повторяется в течение нескольких часов, пока не истечет время ожидания, потому что не было достигнуто никакого прогресса. В конце концов я обнаружил, что есть соответствующий

Чтобы доказать, что управление рабочей нагрузкой вызывает проблемы, я проверил все запросы на восстановление почтовых ящиков во всех почтовых ящиках и подтвердил, что ни один из них не выполнялся.

[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

Здесь 29 ремонтов, все в очереди.

На заметку

Это происходит только с почтовыми ящиками размером 10+ ГБ, потому что это пороговое значение, при котором задача IsInteg запускается перед перемещением.
Это IsInteg, который заставляет вещи задерживаться. Но если я сделаю ремонт IsInteg с -Force тогда ремонт происходит сразу.
Даже для ремонта IsInteg я могу сделать -Force (которые отображаются как успешные), я не вижу записей журнала событий как я должен.
Моя среда - это 1x 2013 Exchange, 2x 2016 Exchange и 1x 2010 Exchange. Все используют последнюю версию CU или RU.
Переход с 2010 года не проблема даже для почтовых ящиков> 10 ГБ.
Я работаю в режиме сосуществования несколько недель и в качестве теста перенес свой собственный почтовый ящик с 2013 на 2016 год. Мой почтовый ящик составляет 15 ГБ, и он не стоял в очереди. Это заставляет меня думать, что если бы я был достаточно терпеливым, другие могли бы добиться успеха. Но мой почтовый ящик не показывался FailedStuck и показывал постоянный прогресс.
Мне интересно, нужно ли мне просто стереть все неудачные ходы (сейчас я просто возобновляю их) и повторять их один за другим.

Я чувствую, что исчерпал большинство своих возможностей, поэтому приветствую любые советы. Даже если бы кто-нибудь мог сказать мне, как выполнить некоторые из перечисленных «возможных решений». Поскольку для меня это всего лишь теоретические решения, я не нашел способов их реализовать.

Я нашел простое решение этой проблемы: Понизьте версию Exchange 2013.

В рамках моего плана миграции у нас также был 2013 год в собственном двухузловом DAG. 2-й узел был совершенно новый и был исправлен до последней версии CU на тот момент:

AdminDisplayВерсия: версия 15.0 (сборка 1236.3) (Exchange 2013 CU14)

Старый узел 2013 года был просто пропатчен достаточно для сосуществования 2016 года:

AdminDisplayВерсия: версия 15.0 (сборка 1178.4) (Exchange 2013 CU12)

Я вспомнил, что до того, как я создал новый ящик 2013 года, мне удалось без проблем перенести несколько почтовых ящиков объемом 15 ГБ в 2016 год.

Во время миграции я активировал все базы данных почтовых ящиков на новый node, поэтому, конечно же, версия CU на новом узле означала, что все будущие перемещения почтовых ящиков потребовали ремонта почтового ящика, если> 10 ГБ.

Разница в следующем: для более старого уровня исправлений CU, не требуется ремонт почтового ящика более 10 ГБ. В этом смысле похож на Exchange 2010. Таким образом, поскольку ремонт / isinteg не производился, перемещение выполняется успешно. Я не уверен, в какой именно момент Exchange 2013 стал требовать проверку IsInteg в рамках миграции. Я также не уверен, будет ли это «исправлено» в более поздних версиях.

Если необходимо перейти на более раннюю версию CU, вы можете создать новый модуль 2013, настроить DAG, а затем перенести все свои базы данных на более старые версии.

Сравнивая отчеты о запросах на перемещение, вы можете видеть, что IsInteg запускается до того, как будет предпринята какая-либо попытка начать передачу данных почтового ящика, и именно поэтому все останавливается.

Вот отрывок из запроса на перемещение, который не удался из-за проверки 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 .

Вот отрывок из запроса на перемещение, который работал с 2013 по 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