我正处于从 Exchange 2013 迁移到 2016 的过程中。大部分操作进展顺利，但是，一些邮箱似乎卡在Initial Seeding，然后在这里停滞几个小时后，在FailedStuck失败。
运行Get-MailboxStatistics -IncludeReport显示移动卡在运行 IsInteg，因为它们是大邮箱。这似乎基本上是New-MailboxRepairRequest无限期排队的。
我可以运行New-MailboxRepairRequest，-Force它会立即完成，所以我认为这只是一个工作负载管理问题，但已经过了几天，修复仍然没有完成。
可能的解决方案
我怎么知道
New-MoveRequest要跳过 IsInteg 预先运行？我很乐意在移动后手动运行它们。如何使用 -Force 标志编辑移动请求创建的邮箱修复请求？据我所知，没有
Set-MailboxRepairRequest。如何禁用邮箱修复请求的工作负载管理？因为这似乎是什么阻碍了我的移动/修复，即使什么都没有发生（这是周末凌晨 4 点在新硬件上，他们不会让步）。
如何提高“大邮箱”阈值（下面的消息暗示它是一个配置选项）。如果我将其设置为 50GB，则所有邮箱都将被移动而无需进行修复。
更多信息
报告显示：
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+ GB 的邮箱上，因为这是导致 IsInteg 任务在移动之前运行的阈值限制。
是 IsInteg 导致事情停滞不前。但是，如果我使用 IsInteg 进行修复，
-Force则修复会立即发生。即使对于我能够进行的 IsInteg 修复
-Force（显示为成功），我也没有看到任何我应该看到的事件日志条目。我的环境是 1x 2013 Exchange 和 2x 2016 Exchange，以及 1x 2010 Exchange。所有都运行最新的 CU 或 RU 版本。
从 2010 年开始迁移不是问题，即使对于大于 10 GB 的邮箱也是如此。
我已经在 Co-existence 中运行了几个星期，并将我自己的邮箱从 2013 年迁移到 2016 年作为测试。我的邮箱是 15 GB，它没有排队。这让我想，如果我足够耐心，其他人可能会成功。但是我的邮箱并没有显示FailedStuck，并且显示出不断的进步。
我想知道我是否只需要清除所有失败的动作（现在我只是恢复它们）并一一重试。
我觉得我已经用尽了我的大部分选择，所以任何建议都值得赞赏。即使有人可以告诉我如何执行列出的一些“可能的解决方案”。由于这些对我来说只是理论上的解决方案，我还没有找到实际执行它们的方法。
我找到了解决此问题的简单方法：降级您的 Exchange 2013 机器。
作为我迁移计划的一部分，我们在自己的 2 节点 DAG 中也有 2013。第二个节点是全新的，当时已修补到最新的 CU：
AdminDisplayVersion：版本 15.0（内部版本 1236.3）（Exchange 2013 CU14）
旧的 2013 节点刚刚修补到足以让 2016 年共存：
AdminDisplayVersion：版本 15.0（内部版本 1178.4）（Exchange 2013 CU12）
我记得在我构建新的 2013 盒子之前，我成功地将几个 15 GB 的邮箱迁移到了 2016 年，没有任何问题。
在我的迁移过程中，我已经激活了新节点上的所有邮箱数据库，所以当然，新节点上的 CU 版本意味着所有未来的邮箱移动都需要在 > 10GB 时进行邮箱修复。
不同之处在于：对于较旧的 CU 补丁级别，超过 10GB 不需要修复邮箱。在这个意义上类似于 Exchange 2010。因此，由于没有进行修复/集成，因此移动成功。我不确定 Exchange 2013 在什么时候开始需要 IsInteg 检查作为迁移的一部分。我也不确定这在以后的版本中是否“修复”。
如果需要降级到较低的 CU，您可以构建一个新的 2013 框，设置 DAG，然后将所有数据库迁移到旧版本。
通过比较移动请求报告，您可以看到 IsInteg 在任何尝试开始传输邮箱数据之前运行，这就是一切停止的原因。
这是由于 IsInteg 检查而失败的移动请求的摘录：
这是从 2013 年到 2016 年有效的移动请求的摘录：