Мы находимся в процессе гибридной миграции сосуществования с локального Exchange 2010 на Office 365. Это означает, что у нас работают ADFS и «Dirsync» (теперь называемый Windows Azure AD Sync). Мы прошли более половины процесса миграции почтовых ящиков, поэтому около 60% почтовых ящиков наших пользователей находятся в облаке, а остальные 40% или около того все еще находятся в локальных базах данных Exchange 2010.
Сегодня мы обнаружили, что один из наших пользователей имеет как локальный почтовый ящик, так и почтовый ящик Office 365, связанный с его одной учетной записью AD. Это означает, что если он открывает Outlook на компьютере, присоединенном к домену, и выполняет начальную настройку, он использует автообнаружение для подключения его к локальному почтовому ящику, но если он входит в портал Office 365, он показывает его облачный почтовый ящик.
Что еще хуже, когда пользователь, чей почтовый ящик находится в облаке, отправляет ему электронное письмо, оно попадает только в его облачный почтовый ящик, а когда пользователь, чей почтовый ящик все еще находится в локальной среде, отправляется только в его локальный почтовый ящик. почтовый ящик. Таким образом, он не может видеть всю свою почту в одном месте.
Как мы можем «объединить» его почтовые данные (конечный пункт назначения: Office 365) и убедиться, что его Outlook «автоматически обнаруживает» почтовый ящик Office 365 и вся почта маршрутизируется в этот почтовый ящик?
Я решил, что не хочу экспортировать всю почту из облачного почтового ящика с помощью Outlook, удалить лицензию Office 365 (или просто лицензию EOL) у пользователя, затем использовать Powershell для постоянного удаления почтового ящика, затем переместить местный почтовый ящик в облако, а затем повторно импортировать экспортированные данные в новый облачный почтовый ящик. Я знал, что это сработает, но, похоже, это обошло все стороной. То, что я в итоге сделал, возможно, было более правильным, но вот еще один способ:
<псевдоним пользователя>@<настраиваемый домен>.mail.onmicrosoft.com
. После того, как объект Mail User был отсортирован, я решил, что мне нужно настроить несколько вещей в атрибутах Active Directory:
<псевдоним пользователя>@<нашний пользовательский домен>.mail.onmicrosoft.com. com
.-2147483642
.2147483648
. 4
.Get-Mailbox -Identity | fl
. Хитрость заключается в том, что, когда о нем сообщается, он находится в формате text и для редактирования AD attritube необходимо ввести его в формате hex. Я использовал он-лайн конвертер (их несколько, которые я обнаружил после веб-поиска по несовпадению форматов), чтобы получить шестнадцатеричную версию и обновил атрибут AD.Анонимный пользователь предложил следующее, вместо использования GUID конвертера. Это также позволит Powershell автоматизировать процесс.
Вместо использования конвертера GUID вы можете просто скопировать GUID с 365 и обновить свойство пользователя в Active Directory:
$365MboxGUID = get-mailbox -identity $samaccountname | select -ExpandProperty ExchangeGuid
Set-ADUser $samaccountname -replace @{msExchMailboxGuid=$365MboxGUID}
У меня такая же проблема в моем домене. Кто-то вручную создал почтовый ящик o365 для пользователей, у которых уже есть локальный почтовый ящик
. Я нашел способ исправить это:
Remove-MsolUser -UserPrincipalName (скрытый) -Force
Remove-MsolUser -UserPrincipalName (скрытый) -RemoveFromRecycleBin -Force
Я думаю, это более просто и понятно. Вы также можете повторно перенести свой почтовый ящик локально (вне сети), если вам это нужно.
Спасибо, Мауро! Это сработало для меня, U пришлось добавить -UserPrincipalName
в вашу команду, и это сработало для меня!
Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -Force
Remove-MsolUser -UserPrincipalName youruser@youroffice365domain -RemoveFromRecycleBin -F
Чтобы избавиться от облачного почтового ящика, я просто перешел с одной подписки на другую, так что в IE я был на E5, я изменил свою учетную запись на Business Premium, но удалил опцию Exchange Online, затем я перенес свой почтовый ящик в облако, прежде чем вернуться к Подписка E5.