Запрос на перемещение почтового ящика Exchange с 2013 на 2016 застревает при начальном заполнении
Я нахожусь в процессе перехода с Exchange 2013 на 2016. Большинство перемещений прошли успешно, однако некоторые почтовые ящики, похоже, застревают на Initial Seeding , а затем, после нескольких часов простоя, сбой на FailedStuck .
Running Get-MailboxStatistics -IncludeReport показывает, что перемещение зависло при выполнении IsInteg, потому что это большие почтовые ящики. Похоже, что это New-MailboxRepairRequest , который просто ставится в очередь на неопределенное время.
Я могу запустить New-MailboxRepairRequest с -Force , и он будет завершен немедленно , поэтому я думаю, что это просто проблема управления рабочей нагрузкой, но прошло несколько дней, а ремонт все еще не завершен.
Возможные решения
Как я могу указать
New-MoveRequestпропустить выполнение IsInteg авансом? Я с радостью запущу их вручную после переезда.Как я могу отредактировать запросы на восстановление почтового ящика, создаваемые запросами на перемещение, с помощью флага -Force? Насколько я могу судить, нет
Set-MailboxRepairRequest.Как я могу отключить управление рабочей нагрузкой для запросов на восстановление почтовых ящиков? Поскольку это, кажется, то, что задерживает мои переезды / ремонт, даже когда ничего не происходит (сейчас выходные в 4:00 на новом оборудовании, и они не сдвинутся с места).
Как я могу поднять «Большой почтовый ящик» порог (в сообщении ниже упоминается, что это параметр конфигурации). Если я установлю что-то вроде 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:
AdminDisplayVersion: версия 15.0 (сборка 1236.3) (Exchange 2013 CU14)
Старый 2013 год узел был просто пропатчен достаточно для сосуществования 2016 года:
AdminDisplayVersion: Версия 15.0 (сборка 1178.4) (Exchange 2013 CU12)
Я вспомнил, что до того, как я построил новый ящик 2013 года, я успешно мог без проблем перенести несколько почтовых ящиков объемом 15 ГБ в 2016.
В ходе миграции я активировал все базы данных почтовых ящиков на новом узле, поэтому, конечно, версия 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