Миграция со стороннего размещенного сервера Exchange на Office 365 - Как избежать отчетов о недоставке, вызванных адресами X500?

Наша организация в настоящее время переходит с сервера Exchange 2013, размещенного на стороннем сервере, на Office 365. Наша организация охватывает несколько филиалов, каждый со своим собственным доменом, и мы переносим пользователей из одного офиса / домена за раз (поэтапная миграция, а не переключение).

Из-за этого я не использую DirSync, и это предполагает сосуществование двух систем Exchange до конца миграции.

Миграция проходит относительно гладко. У меня есть:

• Созданных пользователей на платформе Office 365 с соответствующими псевдонимами SMTP.
• Использовал MigrationWiz для переноса данных нашего почтового ящика.
• На время оставил учетные записи электронной почты на устаревшем сервере и перенаправил их. входящие электронные письма на соответствующий псевдоним .onmicrosoft.com для каждого пользователя, так что электронные письма, отправленные внутренними пользователями, все еще использующими устаревшую платформу, будут приниматься пользователями, уже перешедшими на Office 365.

Тем не менее, это так. становится дорого, так как наша устаревшая платформа оплачивается почтовым ящиком (а не локальным сервером Exchange). Таким образом, мы в основном платим дважды за перенесенные учетные записи электронной почты.

Если мы удалим учетные записи электронной почты на устаревшей платформе, мы будем получать сообщения об ошибках NDR, так как записи X.500 исчезают.

I есть список всех сертификатов 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. 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. 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. как как устаревшая платформа узнает, что X.500 для этой учетной записи теперь обслуживается Office 365? (поскольку X.500, насколько мне известно, не полагается на записи MX?).

Обходной путь, который я рассматривал, заключался в удалении почтовых ящиков на устаревших платформах и добавлении их обратно в качестве контактов, добавляя исходный адрес X.500 , а затем пересылать электронные письма, отправленные этому контакту, на адрес .onmicrosoft.com. как как устаревшая платформа узнает, что X.500 для этой учетной записи теперь обслуживается Office 365? (поскольку X.500, насколько мне известно, не полагается на записи MX?).

Временное решение, которое я рассматривал, заключалось в удалении почтовых ящиков на устаревших платформах и добавлении их обратно в качестве контактов, добавляя исходный адрес X.500 , а затем пересылать электронные письма, отправленные этому контакту, на адрес .onmicrosoft.com. Однако устаревшая консоль управления не позволяет этого. У нас нет доступа к AD или PowerShell.

Короче говоря, я ищу лучший способ удалить учетные записи электронной почты на устаревшей платформе, не вызывая ошибок отчета о недоставке из-за адресов X.500, сохраняя помните, что у нас нет доступа к AD или PowerShell на устаревшей платформе, а только к веб-платформе администрирования (Odin).

Спасибо!