Powershell 5.0 RTM


Наконец-то, после досадного бага, вышел исправленный релиз Powershell 5.0. Январь- февраль я раз в две недели ходил, проверял, не изменилось ли чего- и вот, к концу месяца-таки доисправляли. Не прошло и двух месяцев, в общем 🙂

https://blogs.msdn.microsoft.com/powershell/2016/02/24/windows-management-framework-wmf-5-0-rtm-packages-has-been-republished/

Забираем.

Advertisements

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

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

 

 

Planner в Office 365


Хочу поделиться небольшим наблюдением: очень многие люди считают, что Office 365- это почта :).

Ну, наверное, как и Exchange на земле для 95% пользователей это письма взад назад, а про задачи, календари и доступность не все и слышали. Это наблюдение легко проверить- задайте следующий вопрос собеседнику- что такое, как вам кажется, Office 365? Уверен, Вы получите ответ выше. Не все помнят, что это еще и огромный сам по себе Sharepoint Online, и Skype for Business, и Azure RMS, (который настраивается за несколько минут, в отличие от on-prem), и Mobile Device Management, и Портал для самостоятельного сброса пароля пользователей, и 2-х факторная аутентификация, и интеграция с Azure  и его возможностями из коробки, и редкие в наших палестинах Delve, Sway, Visio Pro for Office 365, Project Pro for Office 365 или Microsoft Power BI for Office 365. Задайте тот же вопрос себе, подумайте  немного над ответом.

Не так давно в семействе 365 появился новый продукт, Planner.

Если очень коротко его охарактеризовать, то это своеобразный заменитель MS Project в облаке, тесно интегрированный с Office 365 Groups.

Выглядит очень толково. и хорошо подходит для командной работы над проектом – рекомендую поглядеть и попробовать самостоятельно.

Итак, что нам нужно, чтобы его включить? Continue reading “Planner в Office 365”

Хозяйке на заметку- Outlook.com


Не всегда кольцевая верификация HELO=PTR(IP), IP=A(HELO), считающаяся заповедью почтового администратора, свято соблюдается всеми.

Примером может послужить статья https://support.microsoft.com/en-us/kb/3019655

“The recipient server requires that the server name that’s contained in the message HELO string have a corresponding pointer (PTR) resource record (reverse IP lookup). Exchange Online and Exchange Online Protection use multiple IP addresses to send mail. Because of DNS limitations, all these IP addresses can be mapped through the PTR record to the server name that’s in the message HELO string.”

в которой говорится, что ввиду неких ограничений (В DNS, Карл!) такое поведение Outlook.com не соблюдает. Более того, В одной из своих SPF MS вставила ipv6 значение, что в некоторых ситуациях может привести к проблемам при анализе и проверке SPF записи. Правильные парни разделяют ip4 и ip6 в разные include, а не валят все в кучу. Надеюсь, этот момент когда-нибудь 🙂 отловят и исправят- пока оно так.

Поэтому, будьте внимательны и осторожны при работе с почтой.

Что касается хороших новостей- то рекомендую всем вступать в партию новую программу сервисов репутации, которая призвана помочь Вашим почтовым серверам при работе с Outlook.com.

Regardless of the deliverability status, Outlook.com recommends that all senders
join two free programs that provide visibility into the Outlook.com traffic on your
sending IP(s), the sending IP reputation with Outlook.com and the Outlook.com user
complaint rates.

Junk Email Reporting program (JMRP) When an Outlook.com user marks an email as “junk”,
senders enrolled in this program get a copy of the mail forwarded to the email address
of their choice. It allows senders to see which mails are being marked as junk and
to identify mail traffic you did not intend to send. To join, please visit http://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts]http://support.msn.com/eform.aspx?productKey=edfsjmril&ct=eformts.

Smart Network Data Services program (SNDS). This program allows you to monitor the
health and reputation of your registered IPs by providing data about traffic such
as mail volume and complaint rates seen originating from your IPs. To register, please
visit http://postmaster.live.com/snds/.

There is no silver bullet to maintaining or improving good IP reputation, but these
programs help you proactively manage your email eco-system to help better ensure
deliverability to Outlook.com users.

Также два толковых сервиса, которые могут помочь при разблокировке:

https://sender.office.com/ и  delist@messaging.microsoft.com

Сервисы хоть и полезные, но тоже доставляют радости иногда.delist

 

Дело о пропавших пользователях Skype for Business


После миграции в Office 365 у двух пользователей обнаружилась странная проблема. Лицензия Е3 была назначена, и  никаких видимых проблем для входа вроде бы не было. Тем не менее, войти в Skype не получалось. После пристального рассмотрения, выяснилось, что пользователь не виден в консоли  Skype for Business, и свойства на портале не редактируются.

 

s1

Видно также, что у пользователя, которого мы не видим в skype, RegistrarPool  пустой. У видимых, что характерно, домашний пул имеется.

s4s5

Как лечить пользователей-невидимок: Continue reading “Дело о пропавших пользователях Skype for Business”

RelinquishedWlmStall и его друзья


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

Ошибка из заголовка статьи напрямую связана с тихими и незаметными вещами, такими, как индексация.

Если с ней непорядок, и чинить ее нет возможности, тогда делаем следующее:

Screenshot_7

Находим базу с проблемой. В этом также может помочь Get-MailboxDatabaseCopyStatus.

Отключаем индексацию для такой базы Set-MailboxDatabase “DBwithfailedindex” -IndexEnabled:$False

ind

Перезапускаем “подвисшие” запросы на перемещение Get-MoveRequest
Get-MoveRequest|Suspend-MoveRequest ; Get-MoveRequest|Resume-MoveRequest

CU11, mailbox anchoring, и почему это важно


Утром на прошлой неделе позвонил мне AStankevich, и поинтересовался, не желает ли благородный дон принять участие в увлекательном и забавном траблшутинге. Благородный дон, разумеется согласился, поскольку ситуация показалась весьма интересной.

Диспозиция такая:

4 мультиролевых сервера в одном сайте, назовем его Москва, собранные в DAG.

такие же 4 на другой площадке, в другом сайте. Назовем его Воронеж.

Итак, что у нас есть? У нас есть основной ЦОД, и были подняты 4 новых сервера в новом ЦОДе. Для этих новых серверов необходимо правильно прописать настройки для OA, OWA, ну и всего такого прочего, все как обычно.

Проблема: При запуске EMS и вводе любой команды из модуля Exchange консоль задумывается почти на 10 минут. Или на полчаса — как пойдет.При этом, не важно, выбираете ли вы для выполнения командлета локальный сервер, соседний сервер в стойке, или сервер из удалённого сайта. Собственно, проблема заключалась в том, что поменять настройки виртуальных каталогов просто не получалось- сессия замирала и просто отваливались с красными нехорошими словами. При этом, серверы обладают огромным запасом памяти, процессора, и нагрузка на них около нулевая. И, разумеется, если не работать с метаданными директорий, а набрать что-то вроде

Get-OwaVirtualDirectory -ADpropertiesOnly | Set-OwaVirtualDirectory -InternalUrl https://URL/OWA

то все отображается быстро, по понятной причине.

Траблшутинг:

Началось все достаточно бодро, замерами и анализом procmon, но достаточно быстро энтузиазм пропал- было не очень понятно, в чём проблема. Тут я вспомнил, что не так давно Паша Нагаев наступал на грабли с Exchange, использующих контроллерами домена в других сайтах.  И поведение показалось мне похожим на наше, ибо было стойкое ощущение, что сессия проксируется в другие сайты, а серверы были подняты совсем недавно, и изменений сделать еще не успели.

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

Get-ExchangeServer -identity $env:Computername -Status | FL Name,Current*

выдавала по-прежнему информацию, что мы подключены к КД в “чужом” сайте.

При этом, с сетевой точки зрения, подключений не было (netstat | select-string “myremotedcinremotesite”).

Это навело на мысли, что сессия внутри EMS просто проксируется, и в этот момент я вспомнил про изменение в поведении с CU11- наша сессия проксируется не нашим CAS в нашем сайте, а тем, на котором ящик администратора, либо системный, если ящик администратора отсутствует.

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

Решение проблемы: Continue reading “CU11, mailbox anchoring, и почему это важно”