Microsoft заявляет, что это больше не работает, но это так.
У вас когда-нибудь была проблема с одним неисправным почтовым ящиком в Office 365 или, как теперь официально известно, Microsoft 365? Проблема с облачной инфраструктурой заключается в том, что вы на самом деле не знаете, что происходит в фоновом режиме или какое колесо хомяка питает базу данных Exchange, на которой находится один из ваших почтовых ящиков. Может быть, хомячков отправляют на аутсорсинг в страну третьего мира, но теперь они морские свинки, и они даже не помещаются в хомячье колесо.
То, что я пытаюсь сказать в бессмысленно запутанном виде, заключается в том, что иногда облачные материалы (это технический термин) просто перестают работать, и иногда вы можете увидеть, что, в то время как остальная часть вашего клиента Microsoft 365 в полном порядке, один почтовый ящик просто отказывается работать. Сценарий, с которым я столкнулся недавно, состоял в том, что почтовый ящик не мог получать почту ни от кого – там было отставание примерно на 6 часов с почтой просто в состоянии "очереди". Все остальные почтовые ящики были в порядке и получали почту от одних и тех же отправителей.
Локальный Exchange позволяет запускать New-MailboxRepairRequest, но в Exchange Online такой функции нет. Вот тут-то и пригодится New-MoveRequest.
Во-первых, обратите внимание, что, согласно официальной документации Microsoft об этом командлете, “после 15 апреля 2020 года вы не сможете использовать этот командлет для ручного перемещения почтовых ящиков в организации Exchange Online. Этот командлет можно использовать только для миграции в Exchange Online и обратно. Несмотря на то, что в нем говорится об этом, только на прошлой неделе мне удалось успешно переместить почтовый ящик между базами данных Exchange Online.
Во-первых, вы хотите подключиться к Exchange Online с помощью PowerShell и найти почтовый ящик, который хотите переместить. Это также покажет вам его текущую базу данных.
Get-Mailbox -identity *test*
Затем создайте запрос на перемещение.
New-MoveRequest -identity testuser
Тогда вы сможете получить подробную статистику по вашему запросу. В частности, вас должен интересовать его статус, а также информация об источнике и пункте назначения
Get-MoveRequest | Get-MoveRequestStatistics | fl
Вот тут-то все и становится странным. Запрос, по-видимому, занимает много времени, как минимум 24 часа. Однако, когда ранее возникала проблема, я запускал команду и видел немедленное воздействие. Вышеупомянутый почтовый ящик, который не работал, внезапно увидел, что вся почта прибыла в очередь, однако официальный статус все еще показывал, что перемещение базы данных продолжается.
Ниже приведено доказательство того, что команда все еще работает. Вы можете увидеть, что база данных почтовых ящиков совпадает с целевой базой данных на предыдущем снимке экрана. Обратите внимание, однако, что этот снимок экрана был сделан через три дня после первоначального запроса. Я проверил статус на следующий день, но перемещение все еще стояло в очереди, поэтому, хотя проблема была немедленно исправлена, выходные данные запроса не обновлялись в течение более длительного периода времени.
