Наша организация в настоящее время переходит со стороннего сервера Exchange 2013 на Office 365. Наша организация охватывает несколько филиалов, каждый со своим собственным доменом, и мы переносим пользователей из одного офиса / домена за раз (поэтапная миграция, не врезной).
По этой причине я не использую DirSync, и это предполагает сосуществование двух систем Exchange до конца миграции.
Миграция проходит относительно гладко. У меня есть:
Тем не менее это становится дорогостоящим, поскольку наша устаревшая платформа оплачивается почтовым ящиком (а не локальным сервером Exchange). Таким образом, мы в основном платим дважды за перенесенные учетные записи электронной почты.
Если мы удаляем учетные записи электронной почты на устаревшей платформе, мы получаем сообщения об ошибках NDR, так как записи X.500 исчезают.
У меня есть список всех адресов X.500 на устаревшей платформе от провайдера.
Некоторые сайты ( https://www.experts-exchange.com/questions/28537964/Solving-the-X-500-Issue-with-inter-tenancy-migration-of-Office365.html ) предполагают, что добавления адреса X.500 в конце Office 365 будет достаточно ... но я не могу понять, как это будет работать, так как как устаревшая платформа узнает, что X.500 для этой учетной записи теперь обрабатывается на Office 365? (поскольку X.500, насколько мне известно, не полагается на записи MX?).
Обдуманный мной обходной путь заключался в удалении почтовых ящиков на устаревших платформах и добавлении их обратно в качестве контакта, добавлении исходного адреса X.500, а затем пересылке электронных писем, отправленных этому контакту, на адрес .onmicrosoft.com. Однако устаревшая консоль управления не позволяет этого. У нас нет доступа к AD или PowerShell.
Короче говоря, я ищу лучший способ удалить учетные записи электронной почты на устаревшей платформе, не вызывая ошибок отчета о недоставке из-за адресов X.500, имея в виду, что у нас нет доступа к AD или PowerShell на устаревшей платформе. платформу, и только на веб-платформу администрирования (Odin).
Спасибо!
Решение X.500 используется, когда все почтовые ящики находятся на новой платформе (будь то Office365 или автономный сервер). Это позволяет конечным пользователям отправлять электронные письма на старые адреса, и они доставляются. Ключевой бит заключается в том, что и отправитель, и получатель находятся на одной платформе.
В вашем сценарии это не сработает. Контакты - это тот метод, который вы могли бы использовать, добавив к контакту внешний адрес onmicrosoft.com, а также адрес X.500. Однако, если инструменты управления не позволяют этого, тогда вы в значительной степени застряли в том, что делаете сейчас, и понесете убытки. Единственное другое решение - сообщить пользователям, что файл псевдонимов больше не действителен и им нужно выбрать нового получателя.
Все, если ваши варианты упрощения работы для конечных пользователей зависят от полного доступа к старой платформе, которой у вас нет.