Анализ производительности PAL


Вовнею посвящается.

img_25112016_173722

Проносило меня как-то мимо ФБ, и случайно я увидел тредик, в котором поднимался, в общем-то каждодневный и злободневный вопрос для любого администратора.

Как замониторить почтарь систему Х. Тут и администратор желтой программы, и ДБА, и кто угодно может расстроиться и начать искать крайних кругом, стреляя в администраторов виртуализации, или склоняя другие отделы к вспомоществованию.

В том топике сразу же эксперты с мировым именем на вопрос чем и как снять показания с больного, предложили perfmon.

Ну еще бы: данные-то от него не им смотреть, поэтому почему бы и не предложить.

Увидев такое я загрустил, поскольку вопрос «тормозит у меня» поднимается довольно часто, а внятных гайдов, куда бежать-то и нет.

А вопросы, чем анализировать данные которые дают, есть.

Было решено исправить упущение, по этому встречаем:

Performance Analysis of Logs (PAL) Tool

[Чего на курсах МС не расскажут, так это того, что собирать данные в виде культурных графиков можно старым добрым способом, но мы его трогать не будем, просто хотелось бы упомянуть что можно и так. Не все про это знают, увы.]

Читать далее

Четвертая часть марлезонского балета


Краткое содержание предыдущих серий тут

Спустимся-ка мы сегодня с облаков на землю. Ведь никто же не против? 🙂

Задали тут джентльмены в чатике вопрос:  а как быть с Recipient Filtering на рабоче-крестьянском сервере с ролью мейлбокс. Понятное дело, на Edge и в облачном EOP она работать будет. А на земле в 2013 придется покрутиться. Итак, поехали.

Смотрим, включены ли агенты:

Get-TransportAgent

screenshot_16

Читать далее

Миграция на Exchange 2016


Такая миграция….

Вляпались в https://support.microsoft.com/en-ca/kb/2990117

постоянный запрос пароля в OA.

Outlook Anywhere users prompted for credentials when they try to connect to Exchange Server 2013 or Exchange Server 2016

Особенно обидно, что на серверы руками были установлены эти апдейты в конце марта, но серверы, к большому сожалению не перегружались.

Поэтому, напеваю все тот же мотив: обновляйте серверы. А после обновления перегружайте их! 😉

Enable-ExchangeCertificate и его друзья.


Чтобы назначить сертификат на службы Exchnage, требуется подсмотреть в справку, которая предлагает убирать его и назначать через параметры командлета Enable-ExchangeCertificate.

Мол, поставьте None и все будет ОК, сертификат уйдет. Логично, да. Disable-ExchangeCertificate пилить лень, делайте все через один командлет, всем будет проще.

https://technet.microsoft.com/en-us/library/dd351257(v=exchg.141).aspx

И это действительно работает, но только для служб IMAP и POP! Ну, и IIS, конечно.

А что делать, если вы задумчиво ковыряете древний сервер транспорта, которому лет уже больше, чем вашему сыну, и который имеет на борту уже с пяток сертификатов? Понятно, что некоторые из них давно просрочены, и не используются службами транспорта (все же помнят алгоритм выбора сертификата для транспорта, если их несколько;) ? Какой будет выбран?). Понятно, что нет на свете таких администраторов, которые удаляли бы «протухшие» сертификаты с серверов, но все же, как решить проблему «отвязки» конкретного сертификата с SMTP?

В общем, плохие новости сегодня: простого способа удалить сертификат для службы SMTP нет.

Придется удалять его полностью (можно экспортировать и сделать это скриптом) и только в этом случае он отвяжется от параметров транспорта.

PS. Хочу напомнить также, что Set-POP/IMAPSettings тоже умеет работать с сертификатами для данных сервисов.

 

 

 

Cashe mode и все-все-все


Обычно, когда администратор почтовой системы слышит о том, что Outlook должен очень тесно сотрудничать с VDI, то его такие новости не радуют. Не радуют администратора и медленные каналы связи, при которых тоже приходится задумываться о разных интересных настройках. (Не поймите меня правильно:- я за VDI,  но с Outlook в нем часто возникают трудности).

Сегодня как раз хотелось об этом поговорить,

И начнем мы с ключа MAPIBlockOutlookNonCachedMode. Ключ этот, как мне справедливо поставили на вид старшие товарищи, существует с момента выхода десятки в свет, но про существование технетов, а тем более статью, где описаны эти и очень многие другие параметры, например настройки для AS девайсов, или EwsAllowOutlook, который зарубит Free Busy по вашему велению, многие не знают. Наша задача- просветительская, поэтому делюсь ТЗ из отрытых, так сказать источников. Очень рекомендую освежить память и припасть к ним, ибо в повседневной работе настройки иногда помогают.

Итак, зачем нам ключ, можно прочитать все в той же статье. Мы же поговорим про его практическое применение. Приходишь так, запросто к кому-нибудь в гости- а там анархия, хаос и прочее непотребство. Администратор пытается управлять ключами реестра, о которых кто-то, наверное, уже читал ранее. Получается, как получается. Но есть и решение со стороны сервера. Посмотреть, как обстоят дела, можно так:

Get-CASmailbox | ? {$_.MAPIBlockOutlookNonCachedMode -eq "True"}
Get-CASmailbox | ? {$_.MAPIBlockOutlookNonCachedMode -eq "False"}
Get-Mailbox | ? {$_.Office -eq "VDI"} | Set-CASmailbox -MAPIBlockOutlookNonCachedMode $true
Что нужно помнить- если ящик был на терминальном сервере или на VDI, и был он подключен через online mode,
то он после принудительного включения использования только кэшированного подключения не подключится сам!
Такие изменения необходимо документировать. Ну, и знать про них :)

Далее, поговорим про задачи деления пользователей на внутренних и внешних.
В Exchange 2010 нам помогал в этом параметр -MAPIBlockOutlookRpcHttp $true, и многие его активно пользовали. И потом еще большие многие, матерясь, поправляли ключи, когда траблшутили это :) а вот в 2016 появился другой ключ:
MAPIBlockOutlookExternalConnectivity. Он поможет решить задачу "Outlook для Васи работает только внутри!"
MapiHttpEnabled, опять же, для самых правильных парней, не убоявшихся 2016, порадует возможностью порулить параметрами на уровне конкретного ящика.

Полезные ссылки
Таблица внизу
https://technet.microsoft.com/ru-ru/library/bb125264(v=exchg.160).aspx

 

Просмотрите остальные настройки, надеюсь, найдете для себя интересные. Это, конечно же была реклама технета.

PS. Граждане бандиты! Неистово плюсуйте понравившиеся статьи, чтобы я мог понимать, какие темы более интересны.  Есть мысли написать разоблачения про Архивы, выпившие несколько литров крови. Будет ли это интересным, работа с архивами?

Autodiscover и все все все.


Очень многие в интернетах обращают свое внимание на механизм Autodiscover, и это хорошо. Еще более многие пытаются пересказать простыми понятными словами старый добрый документ Understanding the Exchange 2010 Autodiscover Service, или посматривая блоги, рисуют картинки и большие буквы, пытаясь донести до широких общественных масс ускользающую от них суть, изложенную все в том же документе. Так как таких статей довольно много, сегодня не хотелось бы на этом останавливаться подробно: я считаю, что вполне можно собраться с силами, и одолеть первоисточник за несколько попыток, не расползаясь по древу. Если вы пытались это сделать раньше, или никогда не видели ссылки выше- победите ее после окончания чтения данной статьи, для лучшего понимания ситуации. Читать далее

Throttling, replication и DAG.


Если мы решаем проблему первоначального заполнения (seeding) ну очень большой базы данных, то уместно в этот момент вспомнить про VSS. Если вспоминать про такие вещи не хочется, то можно обойтись встроенными механизмами Exchange. Однако, как быть, если базы- большие, от полутора ТБ и их много, да и WAN канал достаточно узкий? hello_html_m1bd97e73

Встроенного throttling’а, который регулировал бы полосу репликации БД- нет. (Именно отсюда растет рекомендация Microsoft о выделенной сети для репликации DAG). Если начать копирование даже одной БД на 2 терабайта на канале с утилизацией в 20 МБ, то можно забыть о репликации на неделю, а то и больше, при условии, что процесс будет под наблюдением и, как говорится, ничего такого не случится. А как быть, если нет выделенной сети, а физический канал между сайтами только один? Ведь Exchange «съест» всю полосу, а что тогда останется для клиентов и приложений?

Можно, конечно выполнять Suspend-DatabaseCopy/Update-MailboxDatabaseCopy в рабочие/нерабочие часы, но есть решение более элегантное.

Как многие помнят, в Windows 2012 значительно улучшилась функциональность QoS, и стало возможным гибко управлять трафиком на основе портов и приложений. Эти возможности многие администраторы успешно применяют, когда работают с Hyper-V Replica, и цели имеют схожие с нашей задачей. Поскольку для репликации БД используется MS Exchange Replication Service, просто ограничим его аппетиты до 5 мб/c:

New-NetQosPolicy «ExchangeRepl» -AppPathNameMatchCondition msexchangerepl.exe -ThrottleRateActionBitsPerSecond 5000000

Буквально через пару секунд в диспетчере ресурсов сервера мы видим, что загрузка сетевого интерфейса стала такой, как мы определили политикой.

Удалить политику можно так:

Remove-NetQosPolicy «ExchangeRepl»

Поправить, разумеется- так: Set-NetQosPolicy.

Как видите, все очень несложно, можно выполнять команды в автоматическом режиме, в зависимости от ваших условий и потребностей, и не обращаться за помощью в отдел сетевых администраторов 🙂 Не забывайте о возможностях Windows Server 2012, и более старших версий, используйте их в повседневной работе.

 

Полезные ссылки

https://technet.microsoft.com/en-us/library/dd638104.aspx

https://technet.microsoft.com/en-us/library/dn904093%28v=exchg.150%29.aspx