Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender и Exchange 2013


Не так давно Exchange 2013 преподнес довольно неприятный сюрприз.

Дело в том, что в Exchange 2013 версии выше, чем SP1 не работает корректно разрешение Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender,  отвечающие за прием сообщений от своего домена. Довольно часто в среде Exchange, начиная еще с 2007 многие администраторы использовали это разрешение, чтобы предотвратить отправку писем от своего домена.

Увы, если мы используем версию выше, чем SP1, то письма от нашего домена будут игнорировать это разрешение, и приходить в организацию. Если Вы используете простейшую инсталляцию без дополнительных средств защиты, то набираемся терпения, и ждем, когда эта досадная ошибка будет исправлена в будущих релизах. (Или пишем транспортное правило для обхода проблемы)

Самое время начинать тестировать решения защиты от спама от внешних поставщиков, у многих из которых есть пробный временный период 🙂

train_wreck

CU7


Краткая заметка про обновление.

dag3

Что понравилось:

1) Ставится быстро, и без проблем- установка заняла ровно 2 часа, в следующий раз запущу инсталлятор из бани 🙂

2) Вновь работает переключение баз с “нижней” версии CU6 и обратно. Я обновлял среду из двух серверов, и по привычке решил проверить это дело. В этот раз чутьё не подвело: база в DAG из двух членов спокойно переезжает с одного члена группы на другого.

На скриншоте видно, что серверы имеют разную версию, и в то же время одна база, которая только что была на “старом” сервере спокойно катается туда и обратно.

dag1dag2

3) Про падение POP3 на серверах после обновления даже не стоит упоминать- привычно поднял сломанную обновлением службу, не обращая особого внимания, поскольку вижу это уже в третий раз:

cas4

Симптоматика проста- сервер не отдает баннера по 110 порту, показывая вместо него курсор, но тем не менее, как порядочный подключается и гордо его показывает. Служба в это время работает, но забрать почту у клиентов разумеется не получается. Лечим просто- переводим компонент в активное состояние.

Set-ServerComponentState -Identity EX01 -Component PopProxy -Requester HealthAPI -State Active

проверяем состояние вновь:

Get-ServerComponentState -Identity EX01

компонент активен, служба тоже отдает баннер

cas3

Что касается других адских хинтов обновления, то был совет от Ильи обновить перед установкой серверы последними патчами безопасности. На одном сервере это прошло хорошо- установив 6 обновлений, сервер попросился на перезагрузку, и после перезагрузки быстро установил обновление  CU7. Со вторым сервером повезло меньше-точно так же его обновив, сервер отказывался устанавливать CU на проверке реквизитов, говоря, что есть апдейты для которых нужна перезагрузка. Перезагрузку пришлось провести четыре раза, после этого сервер успокоился. Вывод, который можно сделать из этого: сначала установим CU, а потом можно обновить сервер, все равно перезагружать придется. Но не 4 раза 🙂

Как бороться с нехваткой места на диске Exchange 2013?


Один из способов- не хранить журналы логов транспорта, если, конечно это позволяет “политика” 🙂

Ограничение в 7 дней вполне подойдет для практики реальной жизни.

Get-TransportService SVEX01 |Set-TransportService -ConnectivityLogMaxDirectorySize 500MB
Get-TransportService SVEX01 |Set-TransportService -MessageTrackingLogMaxDirectorySize 500MB
Get-TransportService SVEX01 |Set-TransportService -IrmLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ServerStatisticsLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ActiveUserStatisticsLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -MessageTrackingLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -TransportSyncHubHealthLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -SendProtocolLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ReceiveProtocolLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -TransportSyncHubHealthLogMaxDirectorySize 500MB

Get-TransportService SVEX01 |Set-TransportService -TransportSyncLogMaxDirectorySize 500MB

Также напомню, что если что-то ненужно, то не нужно и не можно это и собирать.

Get-EventLogLevel | where { $_.EventLevel -ge 1} | Set-EventLogLevel -Level 0

Что касается дисков с логами самих служб, я бы привел простенький oneliner:

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-1) | Remove-Item

Другой вариант решения проблемы- у Ильи в блоге

Единое пространство имен в Exchange 2013


Часто в спорах, главным аргументом в которых звучит фраза это них не так “Я всегда так делал”, возникает непонимание между сторонами. Выражается оно обычно в том, что в одна сторона долго и годами делала одно решение, и не знает, что давно в мире есть, скажем, новая архитектура транспорта. Ну и что, а мы всегда все делали без него и работало- говорят оппоненты. А тут предлагают что-то поменять, а не отключив голову делать руками то, что они делать давно привыкли. Всегда был RPC Endpoint и MAPI подключения, все было круто, здорово и хорошо. А про всякие новинки это надо технет читать и вообще головой думать, что энергозатратно. Через это узнаются внезапные открытия про новую архитектуру Exchange. Эта заметка- не исключение, а просто попытка осмысления ситуации, как она есть сейчас на текущий момент. И если бы таких споров не было, наверное, не было бы и заметки :).

оригинал технет

Переключение между центрами обработки данных в предыдущей версии Exchange 2010 было непростым, поскольку пространства имен для подключения клиентов и почтовых ящиков (DAG) были тесно соединены между собой. Если происходил сбой значительной части CAS, или Virtual IP массива, или части DAG, приходилось выполнять переключение между ЦОДами. В Exchange 2010 возможно самой большой единой точкой отказа в почтовой системе являлось полное доменное имя , которое сообщалось пользователям для входа. С точки зрения Exchange 2010, изменение этого FQDN происхоило непрозрачно, поскольку необходимо было внести изменения в DNS и выждать определенное время. А также могло потребоваться еще больше времени, поскольку кэширование имен в браузерах обычно может занимать около 30 минут или более. Continue reading “Единое пространство имен в Exchange 2013”

Exchange 2013 Event ID 2137


Создавая очередной DAG, я наткнулся на любопытную ситуацию: 2 базы из 5 никак не хотели реплицироваться с основных серверов с активной копией сразу после создания. Другие 3 это делали без особых проблем, но проблемные никак не желали наполняться, выдавая:
66%
Операция остановлена.

Копировать в буфер обмена…

ОШИБКА
Сбой серверной административной операции группы доступности базы данных. Ошибка Сбой операции. Ошибки CreateCluster могут возникать в результате неправильной настройки статических адресов. Ошибка: Error 0x71a (The remote procedure call was cancelled) from cli_RpccInstallFailoverClustering.

——————————————————————————–

Или

“RPC request to the Microsoft Exchange Information Store service for log truncation failed for database (DB Name). Error: Failed to notify source server ‘Server Name’ about the local truncation point. Hresult: 0xc8000713. Error: Unable to find the file.”

 

Continue reading “Exchange 2013 Event ID 2137”

CU 5


Уже на подходе, ждем релиза.Снимок

Уже и Кбшка промелькнула и исчезла, прям как с CU3 в свое время. И о новой OAB уже рассказали.

Ждать осталось немного TM, словом.

UPDTED:

Релиз

http://blogs.technet.com/b/exchange/archive/2014/05/27/released-exchange-server-2013-cumulative-update-5.aspx

И одновременно с ним Update Rollup 6 for Exchange Server 2010 Service Pack 3 (SP3)

 

 

 

Служба “Microsoft Exchange Transport” неожиданно прервана. Не запускается служба транспорта


В технетах такое происходит каждый день… В логах примерно вот такое событие: При проверке подлинности входящего прямого доверия произошла ошибка сертификата %1. Исходный IP-адрес сервера, который предпринял попытку проверки подлинности для Microsoft Exchange: [%2]. Проверьте правильность работы службы EdgeSync. Адрес уже используется. Компоновка: 0.0.0.0:25. Не удается начать прослушивание (ошибка: 10048). Компоновка: 0.0.0.0:25. Служба Microsoft Exchange Transport была неожиданно завершена. Это произошло 1 раз(а). Следующее корректирующее действие будет предпринято через 60000 мсек: Перезапуск службы.

Почему так происходит?

Коротко отвечая на вопрос- потому, что администратор плохо ознакомился с изменениями в службе транспорта и неправильно создал коннектор приёма, указав по старинке не Frontend Transport а Hub Transport при создании. После этого сервер начинает жаловаться- 421 4.3.2 Service not available‏, поскольку Frontend Transport честно ждет на 25 порту, а Hub Transport на новом, 2525. После какого-то времени 25 порт “отбирается” неправильным коннектором  и передается в пользование Hub Transport. Все, ситуация налицо, в случае сервера с обоим-двумя ролями.

Что же делать?

1) Пересоздать коннектор. 2) Более простой вариант- изменить его настройки, Set-ReceiveConnector Identity –TransportRole FrontEndTransport И после изменения перезапустить службу транспорта. Полезные ссылки: http://blogs.technet.com/b/rischwen/archive/2013/03/13/exchange-2013-mail-flow-demystified-hopefully.aspx

https://support.microsoft.com/kb/2958036?wa=wsignin1.0