Tagebuch

Забавно. При попытке удалить отмонтированную датабазу Exchange привычно ругался:
This mailbox database contains one or more mailboxes, mailbox plans, archive mailboxes, or arbitration mailboxes.

При этом Get-Mailbox -Database basename - пусто.
С -arbitration и -archive тоже ничего.

Помогло только в гуе отсортировать по архивной датабазе и вывести список ящиков.

Подняла вчера очередной exchange edge, синхронизация прошла и тут бряк - знакомая ошибка. В очереди скапливаются письма, отлуп:
451.4.4.0 Primary target IP address responded with: "451.5.7.3 cannot achieve exchange server authentication.

Ну, собственно, оно нам прямым текстом говорит "потуши файрвол, сука". А если точнее - требуется отключить SMTP Inspection на cisco.

Пришел начальник.
Вежливо спросил, можно ли спалить мой Exchange.
Получил утвердительный ответ - жги!
Спалил.

Ну или короче, как в Дне радио - пришел, сжег и ушел.

Хорошо хоть карта почтовика у меня за спиной устарела ещё два года назад и ничему не соответствует, только дырку в стене закрывает.

0.


А вот что подумали люди, проходящие по коридору с той стороны, я боюсь даже представить.
И что это вообще такое было - тайна, покрытая мраком.

В сети полно мануалов по кросс-форест миграции, а это для моей записной книжки.
Уровень леса и там и там 2008r2, exchange 2010.

1. В target лесу делаем Prepare-move-request
Синтаксис:

$local =Get-Credential - таргет
$remote =Get-Credential - исходный
C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\Prepare-MoveRequest.ps1 -Identity user@domain.com -RemoteForestDomainController dc.sourcedomain.com -RemoteForestCredential $remote -LocalForestDomainController dc.targetdomain.com -LocalForestCredential $local -UseLocalObject -Overwrite -verbose

2. Запускаем ADMT
Миграция пользователя.
User account migration wizard – source domain, target domain
User selection option – select users from domain
User selection – добавляем выбранного пользователя
Organization unit selection – выбираем нужное ou
Password options – Migrate passwords – Password migration source DC DC with PES
Account Translation Options – Target Account State – Target same as source, Sourse account disabling оставляем пустым. Обязательно ставим галку Migrate user SIDs to target domain.
На запрос аудита отвечаем YES (если не включили политику)
User account - Вводим логин-пароль администратора исходного домена
User options – Translate roaming profiles – Update user rights – Fix users group memberships
Exclude specific object properties from migration. Выбрать и исключить (тип user):

HomeMDB
HomeMTA
mDBUseDefaults
msExchHomeServerName
msExchMailboxSecurityDescriptor
msExchMDBRulesQuota
msExchPoliciesIncluded
msExchRecipientDisplayType
msExchRecipientTypeDetails
msExchUserAccountControl
msExchVersion
showInAddressBook

Conflict Management – Migrate and merge conflicting objects – отметить move merged object to the specified target Organization unit
Finish

3. Перемещаем локальный профиль.
Security Translation Wizard
Previosly migrated objects
Sourse domain, target domain
Select computers from domain
Add – выбрать компьютер
Translate objects – user profiles
Security Translation Options – add
Finish
В появившемся окне нажать run pre-check and agent operation

4. Move-request. Выполняется в целевом домене. Синтаксис следующий:
New-MoveRequest -Identity user@domain.lan -Remote -TargetDatabase databasename -RemoteHostName cas.sourcedomain.lan -RemoteCredential

$remote -TargetDeliveryDomain stg.ru -DomainController dc.target.lan


Дополнения

Проверить, что SID-хистори перенеслась после миграции пользователя, можно либо просмотрев лог ADMT, либо посмотрев атрибут sIDHistory у

пользователя в перенесённом домене. Атрибут не должен быть пустым.

При выполнении prepare-moverequest можно получить следующее:
ould not find the default Administrative Group 'Exchange Administrative Group (FYDIBOHF23SPDLT)'.
+ CategoryInfo : NotSpecified: (0:Int32) [Update-Recipient], DefaultAdminist...tFoundException
+ FullyQualifiedErrorId : 27C11212,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

В этом случае у нас не пройдет Invoke Update-Recipient, следовательно, атрибут legacyExchangeDN не будет установлен. При попытке сделать move-request получим отлуп:  critical property 'LegacyExchangeDN' is missing in the UserMailbox object

В этом случае либо делать самому Update-Recipient, либо прописывать LegacyExchangeDN вручную.

Если при попытке сделать move-request получаем:
The target recipient user' must be a mail-enabled user when the primary mailbox is moving cross forest.
+ CategoryInfo : InvalidArgument: (user@domain.com:MailboxOrMailUserIdParameter) [New-MoveRequest], RecipientTaskException
+ FullyQualifiedErrorId : CBF0E63A,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

Значит в ADMT не были исключены определённые атрибуты. Смотрим пользователю в атрибуты, атрибут msExchHomeServerName. Если там ссылка на MBX-сервер из старого домена, значит так и есть. Удаляем атрибут, запускаем заново. После того, как пройдет move-request, в msExchHomeServerName появится имя нового сервера.

Если вы по какой-то причине сначала сделали переезд ADMT до prepare-move request, при попытке выполнить prepare получите следующую ошибку:
Cannot create mail enabled user because an existing object with type already has the same proxy addresses/MasterAccountSid

В этом случае вам придётся прибить всё из атрибута proxyAddresses и сделать учетку mail-enabled:
Enable-MailUser -DomainController dc.domain.lan -Identity user
ExternalEmailAddress – user@target.local, дополнительно proxyaddress user@domain.com
В исходном домене учетке сделать дополнительный proxyaddress user@target.local

После этого осуществить prepare-moverequest, где в качестве user необходимо написать user@target.local
Дальше move-request – как обычно.

Собственно, всё.

Первое, на что надо обратить внимание при планировании архитектуры exchange (а принцип некст-некст и в продакшн я не рассматриваю) - это отказоустойчивость.
Ни красивость, ни удобство управления, а доступность 24\7, потому что почта это критичный сервис практически в любом компании. И да, блин, никого не волнует, что вам удобнее настраивать вот так, а эдак - настройка займет дольше времени.
Поэтому решение "а давайте презентуем виртуалке с mbx физический диск на 4тб" на мой взгляд абсолютно, недопустимо, критично идиотское. Да, я всё понимаю, так удобнее рулить, один диск это не два и не три. Не надо париться с другими почтовыми хостами. Но, блин, наша работа заключается в в удобстве и доступности сервисов со стороны пользователей. Наше удобство это вопрос вторичный. VHD не поддерживает больше 2тб? Удивительно, но 2 VHD прекрасно образуют 4 тб, не говоря уже про 3. И внезапно у нас нет проблем ни с бэкапами, ни с отвалившимся физическим диском, ни с бесконтрольно растущими базами. Да, внезапно при больших объемах неплохо бы иметь базы под отключенные мэйлбоксы.
А это я всё к тому, что при переводе всё на нормальный принцип работы mbx я наткнулась на давно любимые грабли, а именно:

The log copier was unable to continue processing for database 'BASENAME\SERVERNAME' because an error occured on the target server: Continuous replication - block mode has been terminated. Error: the log file sector size does not match the current volume's sector size (-546) [HResult: 0x80131500]. The copier will automatically retry after a short delay.

Привет VHDX, ага.
Но блин, при нормальном, адекватном подходе не должно такого быть. Если у тебя что-то не жрёт больше 2тб, зачем ему это впихивать? Если ты уже виртуализируешь всё что можно, о каких физических дисках может идти речь?
А выстроить структуру "как надо" всегда проще, делая правильно сразу. Нежели потом осторожно выковыривая костыли.

- Здравствуйте. С такого-то числа я нахожусь в отпуске. С уважением, Иван Иваныч.
- Здравствуйте. С такого-то числа я нахожусь в отпуске. С уважением, Пётр Петрович.
- Здравствуйте. С такого-то числа я нахожусь в отпуске. С уважением, Иван Иваныч.
- Здравствуйте. С такого-то числа я нахожусь в отпуске. С уважением, Пётр Петрович.

И так почти сутки.
Встретились два робота, ага.

В аду есть специальное место для людей, которые используют автоответ.

Круче всего была тётенька, которая потратила по-моему полдня на то, чтобы выбрать из адресной книги туеву хучу народа (потому что группа рассылки премодерируемая) и отправила письмо с запросом отлупа о прочтении.

А ещё один дяденька вставил себе в подпись картинок, висящих в интернетах, ссылка в пять строк длиной и ещё сайт с каким-то похабным названием типа "fuckmanass.com". Ну и понятно жаловался, какого хрена некоторые люди видят у него вместо красивой картинки какой-то ахтунг.

Короче это всё из серии "почему растут логи" и напоминание себе - никогда не исключать пользовательских проблем.

Как известно, в exchange 2010 привесить пользователю дополнительный почтовый ящик можно как минимум двумя способами. Вариант первый локальный - файл данных, параметры, дополнительно, добавить.
Вариант второй - в остастке exchange дать полный доступ на ящик.
В том и в другом случае у пользователя в outlook появится новый почтовый ящик.

Проблема отловилась такая - при удалении полного доступа ящик из outlook удаляться отказался. Запрос возникает следующий:
"Чтобы удалить учетную запись, перейдите на вкладку Файл, на вкладке сведения нажмите кнопку "Настройка учетных записей", выберите учетную запись электронной почты и нажмите кнопку "Удалить".
Ещё бывает такой:
Невозможно показать папку. Приложению microsoft outlook не удается получить доступ к указанной папке.

Решение:

1. AD, users and computers => учетная запись почтового ящика, который никак не может отключиться.
2. Свойства, вкладка "редактор атрибутов".
3. Найти атрибут msExchDelegateListLink
4. Удалить из него значение учетной записи, где отключен полный доступ.
5. Перезапустить outlook.

Обещали исправить это в rollup3. Не исправили.

- Вика, а у нас на exchange используется smtp?

Я зависла.