MKB phpBB

Почтовая система на базе MS Exchange 2012
В этой статье будет описан процесс организации с нуля почтового домена, в отказоустойчивой распределенной конфигурации, с интеграцией в AD.
С данной схемой можно прекрасно использовать mail firewall. Один из вариантов такого файерволла описан тут...

Концепция
кластер из 2х ClientAccess Hub серверов + кластер/DAG из серверов клиентского доступа с ролями Mailbox.
Для чего городить такой, на первый взгляд странный винегрет? Во благо масштабируемости. CAS/DAG ставится на филиал, а кластер из ClentAccess Hub серверов агрегирует подключения, в случае если филиалов два и более.
Если у вас всего один филиал, оставьте два сервера с ролью CAS/Mailbox, не заморачивайтесь.

Подготовка
Предполагается, что вы уже установили 4 сервера с чистой ОС win2012. Получили по два сервера <Mailbox>/<Client access> и <Hub transport>. В принципе можно разделить роли Mailbox и ClientAccess по разным серверам, увеличивая отказоустойчивость того или иного модуля, но главное знать, что edge transport вы с cas/mailbox вместе не установите. Однако Microsoft в версии 2013 отошли от классических консолей управления, насаждая свой PowerShell, и переведя GUI в web-сервисы, и если вы поставите на сервер лишь роль MailDatabase, без ClientAccess, то для управления сервером вам оставят лишь PowerShell. При этом сам Microsoft рекомендует роли совмещать.
Так же потребуется развернуть роль так называемого Witness сервера (сервер слежения), для контроля кластеризации серверов почтовых баз. Можно использовать чистый сервер, либо использовать в его качестве любой имеющийся (даже без любой exchange роли), главное чтоб он не был частью DAG (см. ниже).
Что же касается самой роли Edge Transport, то это по сути обычный smtp mx relay. Можете поставить на нем системы фильтрации и антивирусной защиты, но... лучше его заменить на более адекватный mail firewall (хотя бы опен сорс, например). Еще надо подготовить организационную схему на контроллере домена.
netdom Query fsmo (узнаем мастера схемы) Надо вставить установочный диск MS Exchange в сервер мастер схемы. И запускаем такие команды.
cmd ((на схема-мастере, под суперадмином)) Ожидаем репликации на все контроллеры домена (или делаем ее вручную).

Установка Mail Database Server Cluster.
Для отказоустойчивости будем собирать DAG (Database Availability Group), и в этих целях потребуется по два сетевых интерфейса на каждый сервер. Один интерфейс маршрутизируемый, обеспечит продуктивный трафик, второй изолированный, нужен для heartbeat репликации (собственно отказоустойчивость).
Условно, маршрутизируемый интерфейс будет в сети 10.77.3.64/26, имея ip адреса 10.77.3.69-70.
На heartbeat интерфейсе будет сеть 10.77.3.32/27. Адреса соответственно 10.77.3.33-34.
Сервера необходимо ввести в домен.

Устанавливаем на каждый из mail-box серверов необходимый набор утилит и компонентов: После установки появится требование перезагрузки. Подчиняемся...

Далее необходимо установить Unified Communication Manager http://www.microsoft.com/en-us/download ... 24fa6=True
Перезагружаемся...

Запускаем установку Exchange2013. В мастере все шаги интуитивно понятны. На шаге Server Role Selection выбираем Mailbox role и ClientAccess role. На шаге выбора модели организации надо принять решение как разделять доступ к администрированию. Если у вас разные админы рулят AD и Exchange серверами, то выбирайте Apply split permission..., иначе оставляйте по умолчанию.

Все эти шаги проделываем для обоих серверов Mail Database.

Теперь настроим Witness сервер. Суть настройки сводится к добавлению в локальные администраторы сервера группы Exchange Trusted Subsystem.
На нем же надо создать каталог для DAG, желательно с не очень длинным именем. Подойдет например C:\MSK-DAG1

Дольнейшие настройки потребуют от пользователя членства в грумме Organization Management. По умолчанию в ней лишь основной администратор домена.
Настраиваем базы данных почты. Делается это из Exchange Control Panel (ecp), через web браузер.
В разделе servers, подраздел databases. Создаем необходимое количество баз, указываем параметры ограничений по своему вкусу. Вообще планирование почтовых баз в exchange - отдельная тема. Старайтесь лишь делить базы так, чтобы не допускать роста каждой из них более 200Гб. Обслуживание гигантских баз то еще удовольствие.

Наконец поднимаем DAG.
На контроллере домена создаем новый объект computer, даем ему имя обязательно такое же, как и будущее название нашей группы (msk-dag1), помещаем его в тот же OU, где находятся сервера Exchange. В меню консоли AD тычем в View -> Advanced features. Открываем параметры созданного объекта DAG, закладка security, добавляем группу Exchange Trusted Subsystem, даем ей Full control. Туда же добавляем первый сервер exchange mailbox, аналогично даем Full control. И делаем Disable account на объекте msk-dag1.
Лезем в Exchange Admin Center на первом сервере почтовых баз. В раздел servers. Подраздел Database Availability Group. Создаем новую группу. Называем ее соответственно, MSK-DAG1, указываем сервер слежения (FQDN), путь с каталогу на Witness сервере (C:\MSK-DAG1), ip адрес группы (адрес будет шариться между членами кластера, и должен быть в общей с ними сети).
Выбираем созданную группу, заходим в memberships. Добавляем там наши mailbox сервера. Сохраняем и ждем пока пройдет репликация и все операции по созданию DAG.
В результате в AD будет создан объект computer с именем нашей группы, и соответствующая запись в dns.
Переходим в подраздел databases. Выбираем по очереди каждую из созданных баз на первом сервере, жмем additional -> add copy, и добавляем второй сервер.
Все.

Настройка кластера Client Access Server
До версии 2013 exchange подразумевал создание CAS array, с организацией NLB. Теперь же, т.к. сильно пересмотрена архитектура ролей, CAS стал по сути сверхинтеллектуальным mail-прокси-сервером, тесно интегрирующимся в AD, распознающим сайты и с прочими разными полезными ништяками.
Если в используете для почтовой системы лишь один кластер с CAS/DAG ролями, то отказоустойчивость client access frontend вам придется обеспечивать лишь через dns round robin. Благо outlook клиент достаточно умен, чтобы в случае выхода из строя одной ноды перекинуться на резервную. Либо используйте аппаратные решения сторонних вендоров для сетевой балансировки. WNLB и DAG на одной системе развернуть не удастся.

Итак, ставим пару серверов с ролью ClientAccess, аналогично, как и в разделе выше, лишь не указываем роль Mailbox. После всех процедур все Exchange сервера увидят друг друга в домене.

Настроим RoundRobin DNS имя. Например mail.domain.ru, которое будет иметь два ip адреса наших новых CAS серверов.

Ну и наконец создадим внешний коннектор.
Чтобы работал почтовый обмен с внешним миром, необходимо создать коннектор отправки с типом Internet. Можете направить его напрямую в интернет, используя внешние MX записи, либо направить сквозь смартхост (тот же почтовый релей, исполняющий роль mx сервера, например).
Остальное опционально.

Импорт адресной книги.
В некоторых ситуациях вам может понадобиться сформировать адресную книгу, которая будет дистрибьютиться всем клиентам в outlook. Это может быть необходимо, если вы мигрируете из одного почтового домена в другой и не желаете поднимать FIM/Sharepoint, или если у вас есть список внешних контактов партнеров вашей компании, и т.п.
В Exchange 2013 эти манипуляции делаются через автономную адресную книгу (Offline Address Book). Управление книгой в версии 2013 отличается от предыдущих. И делать все придется через PowerShell, ибо в ECP интерфейсе нет никаких рычагов управления.
Управление адресными книгами происходит через так называемый арбитражный почтовый ящик.
Первым шагом нужно определить, какой сервер отвечает за формирование книги, и в какой базе данных лежит нужный нам арбитражный ящик.
Получаем имя базы.
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “*oab*”} | ft name,database
Определяем активный сервер
Get-MailboxDatabaseCopyStatus <db_name>
Подходящий сервер будет в статусе mounted.
Дальнейшие действия нужно проводить на этом самом сервере, в его PowerShell консоли.

Проблема с доставкой внешней почты
Exchange 2013 451 4.7.0 Temporary server error. Please try again later. PRX5
Written by Allen White on. Posted in Exchange 2013
In Exchange 2013 RTM and Exchange 2013 CU1 you may occasionally receive the following errors in your Outlook clients as seen below. This is currently a know problem with Exchange 2013 and can be resolved with the following. By default the standard frontend receive connector is bound to all addresses on the server as seen below, this is now know to occasionally cause issues with DNS lookups. We need to change the setting here to the specific IP address that the Exchange 2013 server uses and also put a line in our hosts file. To edit the bindings in Exchange 2013 click the pencil sign above to edit and change the ip address to the Exchange servers NIC as seen below. Once done apply all settings. Now browse to the hosts file that is located in C:>Windows>System32>Drivers>etc
Edit the host file and add entry’s for your Exchange 2013s IP and its host name, for example. As seen here. Then reboot your server and you will not receive the Exchange 2013 451 4.7.0 Temporary server error. Please try again later. PRX5 error.

I had the same issue when i tried to install CU2. when i did a get-ServerComponentState -identity “MailboxServer”. All the server components where in an Inactive state. i sent them active one by one by doing.
set-ServerComponentState ‘MailboxServer’ –Component ‘ComponentName’ –State Active –Requester Functional

Just for the record. The HOSTS entry patches the effect, but the real problem is probably elsewhere, namely:
See http://exchangeserverpro.com/exchange-2 ... s-lookups/
to find out how to explicitly define DNS servers for the transport services – this is necessary when you have multiple network cards, e.g. for a DAG network on a combinded CAS/MBX server cluster (you won’t want to have the DAG network in DNS, as it might cause certificate trouble with autodiscover.
You can user get-transportservice | fl name,*dns* to verify that ExternalDNSServers and InternalDNSServers are now populated, instead of relying on some networkcard settings.
But this is only half the truth, because a similar setting exists for set/get-frontendtransportservices. And *this* is not set by the ECP GUI. See
http://social.technet.microsoft.com/For ... or-451-470
Set the DNS servers for the frontend servers using above powershell command, and the effect should go away.

We are receiving the following error when sending emails from external addresses to distribution groups.
SMTP Error 451 4.7.0 Temporary server error. Please try again later. PRX1
The option to allow unauthenticated users to send email us correctly set.
2 CAS Servers
2 Mailbox servers
Exchange 2013 CU 8
was not able to find to much documentation for this error. Most of what I found applied to a similar error with the PRX5 code at the end.

"SMTP Error 451 4.7.0 Temporary server error. Please try again later" I suspect some DNS issue on the exchange based on the above error. You can possibly check the dns settings
Run the below command to check the values of dns servers
Get-Transportserver [YOUREXCHANGESERVER] : Format-List internaldnsservers, externaldnsservers
If you find the values to be empty then run the below command
Set-TransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-TransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

Set-FrontEndTransportService exchange2013 -ExternalDnsServer 10.10.100.10, 10.10.100.11
Set-FrontEndTransportService exchange2013 -InternalDnsServer 10.10.100.10, 10.10.100.11

Make sure transport service and frontendtransport service both has the same DNS server values
If you are looking for the protocol logs and message tracking logs path you can refer my article
http://exchangequery.com/2014/02/21/ana ... ange-2013/

Не удается доставить: Inbound proxy probe после включения функции защиты от нежелательной почты.
Exchange для самотестирования использует немного странноватое решение — Health ящики. Они с завидной стабильностью отсылают от имени inboundproxy@contoso.com почту, а точнее каждые 5 минут. До CU9 эта почта еще и проходила в логах сервера, но этот момент «починили» в стиле Microsoft.
Письма так и продолжают ходить внутри почтового сервера и какие бы домены не обслуживались почта все равно идет от имени inboundproxy@contoso.com на ящик Health****@первыйобслуживаемыйдомен.ru.
Лечится эта ситуация самым простым и надежным способом — добавлением в исключения.
Set-ContentFilterConfig -BypassedSenders "inboundproxy@contoso.com" -BypassedSenderDomains "contoso.com" -BypassedRecipients "inboundproxy@contoso.com"

Проблема номер следующая: Некоторые почтовые аккаунты не подключаются к мобильным клиентам через MS ActiveSync.
Тут, с одной стороны, все тривиально, а с другой все плохо.
Микрософт озаботился нашей всеобщей безопасностью, а в особенности административными аккаунтами.
Скорее всего вы пытаетесь в мобильном клиенте логиниться через учетную запись, обладающую защитной шапкой невидимкой, под названием "AdminSDHolder". Погуглите в микрософте что это за неведомая ебаная хуйня.
Под этим волшебным колпаком находятся вот эти объекты:

The following list describes the protected groups in Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008:

Account Operators
Administrators
Backup Operators
Domain Admins
Domain Controllers*
Enterprise Admins
Print Operators
Read-only Domain Controllers*
Replicator
Schema Admins
Server Operators
Additionally the following users are also considered protected:
Administrator
Krbtgt

* Only group is protected, not the members.

Суть этой каряги сводится к тому, что ежечасно(по дефолту) на эти группы и их мемберов накатываются ACL-ы, описанные в этом самом AdminSDHolder, и снимаются наследования безопасности. Все эти объекты так же обладают атрибутом "adminCount", со значением равным "1", что и означает принадлежность к этой касте неприкасаемых.
Как лечить? А никак. Официальный ответ микрософта - "нехуй сидеть в почте под админскими аккаунтами". Но MS был бы не MS, если бы тут нельзя было присунуть черенок лопаты в жопу.
Дабы разок подключиться к почте, можно просто на нужный аккаунт в ADU&C включить наследование безопасности (по необходимости дождаться реплики), и пробовать подключаться. Только не тормозите, через час все это хозяйство опять задефолтится.
Если есть желание выключить эту ботву насовсем для какой-то учетки, то помимо наследования так же поправьте атрибут "adminCount", поставив ему "0". Больше этот аккаунт ваш АдминСДХолдер не побеспокоит.
Самый же идеальный вариант - это добавить в накатываемые ACL-ы нужных разрешений для доступа к почте по ActiveSync. Располагаются они тут: Adsiedit.msc -> Default naming context -> root.domain -> System -> AdminSDHolder: properties->security. Ну чо далее вы понели да?...
Однако есть нюанс. Я нихера не понял какие собственно пермишшены нужны для этого говна. Чёт дико лень разбираться пока. Если кто знает/разберется - поделитесь, не в падлу!
Тут норм описали про этот сраный механизм: https://www.osp.ru/winitpro/2010/11/13006804/