Something went wrong…


Предположим, Вы мигрировали ящик пользователя в царство добра О365.

Пользователь становится зачем-то недоволен, так как у него не работает перенаправление или OWA Redirect для его ящика. Ошибку он получает вот такую, а разбираться с ней – вам, конечно.

 

 

 

 

 

 

Если почистить пул на бэкенде почтового сервера где находится активная база данных, то ошибка становится менее туманной, и из-за туч и облаков проступает лучик солнца:

 

 

 

 

То есть уже не просто We could not find a mailbox for this user. А есть продолжение

Continue reading “Something went wrong…”

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


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

img_25112016_173722

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

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

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

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

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

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

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

Performance Analysis of Logs (PAL) Tool

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

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

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


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

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

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

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

Get-TransportAgent

screenshot_16

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

Миграция на 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, или посматривая блоги, рисуют картинки и большие буквы, пытаясь донести до широких общественных масс ускользающую от них суть, изложенную все в том же документе. Так как таких статей довольно много, сегодня не хотелось бы на этом останавливаться подробно: я считаю, что вполне можно собраться с силами, и одолеть первоисточник за несколько попыток, не расползаясь по древу. Если вы пытались это сделать раньше, или никогда не видели ссылки выше- победите ее после окончания чтения данной статьи, для лучшего понимания ситуации. Continue reading “Autodiscover и все все все.”

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

Can’t remove move request


– Failed to communicate with the mailbox database, говорит нам консоль при попытке удалить запрос на перемещение ящика в Office 365, да и “на земле” такое случается. А удалить, допустим, очень надо- ведь иначе никак не начать новый, ибо старый пока еще висит, пусть даже и выполненный.

Темные личности любят в этот момент  с торжествующим криком доставать ADSI и мужественно выпиливать атрибут msExchMailboxMoveRemoteHostName через него. Таким товарищам сразу становится грустно, если ящиков, скажем, 50 :). Облегчим им жизнь пятистопным ямбом:

Get-Mailbox | ft name,MailboxMoveRemoteHostName  #выловим тех, у кого атрибут не очищен, и очистим его.

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

$ou = “LDAP://OU=Users,OU=CA,OU=@To Cloud,DC=source,DC=com”
$filter = “(msExchMailboxMoveRemoteHostName=*)”
$searcher = New-Object adsisearcher([adsi]$ou , $filter)
$searcher.FindAll() | Foreach {
$user = $_.GetDirectoryEntry()
$user.’msExchMailboxMoveRemoteHostName’ = “$null”
$user.SetInfo()
}

ShadowMessagePreferenceSetting и его друзья


Администратор одной почтовой системы обратился ко мне с вопросом, и описал свою среду. У него имелись (для простоты) два сайта AD, и по 2 сервера в каждом сайте. Были собраны 2 DAG’a и растянуты между сайтами,  SiteAMBX1 был  в одной группе с SiteВMBX1 и аналогично, SiteAMBX2 вместе с SiteВMBX2. И возник довольно простой вопрос, почему же теневые копии писем отправляются не на локальный, “домашний” сайт сервера, который их отправил, а по WAN каналу в удаленный? (казалось бы)

Screenshot_7Если мы обратим взор на параметры транспорта, то увидим настройки для теневых копий по умолчанию,

из которых следует, что для создания теневой копии по умолчанию будет использоваться параметр PreferRemote, который будет стараться предпочитать удаленный сайт, и только в том случае, если это не удастся, будет использован локальный сайт.

Сделано это для повышения надежности транспорта, и надо признать, надежность транспорта в 2013 версии была сильно увеличена, по сравнению с предыдущими версиями.

Все остальные параметры теневых копий (RemoteOnly, LocalOnly)  и не только их можно подсмотреть тут: https://technet.microsoft.com/en-us/library/bb124151%28v=exchg.160%29.aspx

Вспомнить, как что работает, помогут вот эти ссылки:

http://www.msexchange.org/articles-tutorials/exchange-server-2013/planning-architecture/exchange-2013-mail-flow-part1.html

http://www.msexchange.org/articles-tutorials/exchange-server-2013/high-availability-recovery/transport-high-availability-exchange-2013-part1.html

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

Вот такие вопросы и такие ответы на них были даны. Задавайте почаще разные вопросы себе, сомневайтесь, и проверяйте практикой, как и что работает- и все будет работать отлично!