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 расписано очень хорошо как быстро диагностировать проблему, и не хотелось бы повторяться.

Решение проблемы:

  1. Простое решение- открыть консоль Powershell, скопировать в нее
    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

    Как любое простое решение, оно имеет свои недостатки, поскольку не учитывает ролевую модель RBAC и полагается только на права пользователя в AD. Т.е., бытовым языком, если Вы из Organization Management то проблем Вы не увидите. Если Вы из другой группы- то решение Вам не поможет. Говорить о переносе ящиков в другие базы не будем— уже есть взрывы в комментариях в блоге разработчиках по этому поводу, да и можно представить, что мы, как администраторы, не имеем ящика, который должны лицензировать- ящик администратору просто ни к чему.

  2. Варварское решение (я очень надеюсь, что его оно не будет списано из блога и не появится в Microsoft kb ; )) Итак, для того,чтобы наша сессия не проксировалась, можно сделать следующее:
    1. Открываем IIS на серевере CAS.
    2. Находим каталог PowerShell.
    3. Выбираем «Advanced Settings» из меню Actions справа.
    4. Изменяем настройки Physical Path с «С:\ExchangeServer\V15\FrontEnd\HttpProxy\PowerShell» на «С:\ExchangeServer\V15\ClientAccess\PowerShell».
    5. Выполняем IISRESET

    Я описал случай с контроллерами домена не просто так, из любви к искусству, а потому,что поведение проксирования меняет логику отображения current domain controller, и заставляет неискушенного в ситуации администратора поволноваться. Надеюсь, это поправят в ближайших релизах CU, если вы можете открыть кейс с неправильным отображением Current* — открывайте, скорее будет исправлено.

  3.  Поменять ключ в реестре, согласно статье
  4. Подождать СU 12 🙂

Через некоторое время у Паши Нагаева возникла производственная необходимость поменять сертификаты на серверах, и он натолкнулся на похожие проблемы, я поделился своим опытом, и Паша затребовал срыва покровов и разоблачения ТЗ для общественности.

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

Не проходите мимо блога Ehlo, и внимательно читайте обо всех изменениях.  Очень может быть, что благодаря этому Вы сами справитесь с проблемой.

P.S. Вообще, при всех хороших исправлениях у CU11 все же есть много мелких и неприятных багов, вроде

«I’ve found that I cannot enter the product key for CU11 servers»
The same cmdlet and product key works fine on CU10 servers
или
Seeing more and more forum posts about weird behavior. All seem to start with …”I just applied Exchange 2013 CU11”.

 

 

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s