Exchange в вопросах и ответах : Получить правильное сообщение

В этом месяце решать самые заковыристые задачки по Exchange привычному автору этой колонки помогает приглашенный специалист.

Хенрик Уолтер

Приглашенный специалист — Джордж Хинтерхофер

Отслеживание сообщений

Вопрос Не могли бы вы дать парочку советов по отслеживанию сообщений? Нам кажется, что графический интерфейс мало помогает в решении этой задачи. Нам нужен совет, как извлечь нужную информацию из журналов отслеживания сообщений.

Ответ Для отслеживания сообщений лучше всего использовать Windows PowerShell. Это дает больше средств управления запрашиваемыми параметрами и работает значительно быстрее. Вот пример команды:

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"

Она возвращает все записи отслеживания сообщений с адреса test@contoso.com со всех транспортных серверов в среде, начиная с 9:00 утра 18 марта 2012 года. Если нужно экспортировать результаты для одного из ваших пользователей или клиентов, передайте результаты по конвейеру в командлет Export-CSV:

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv

Вам найти в результатах причину неполадки? Добавьте в команду командлет format-list:

Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl

Для простоты использования и чтобы каждый раз не печатать много текста, рекомендуется написать собственную небольшую функцию Windows PowerShell. Это позволяет быстро и эффективно выполнять поиск. Следующий пример читает журналы транспортных серверов-концентраторов, принимая в параметре –sender отправителя, и возвращает данные за последние 24 часа:

functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }

При использовании этой функции вы можете задавать свои параметры. Этот код можно также разместить в файле $profile .ps1 — тогда он будет загружаться при запуске. После этого вам будет достаточно просто выполнить такую команду:

mt –sender test@contoso.com

Накопительные обновления

Вопрос Я слышал, что папку Updates на установочном носителе Exchange 2010 можно использовать для «наката» накопительных обновлений во время установки. Правда ли это?

Ответ Да, это верно — по крайней мере частично. Папку Updates можно использовать для установки соответствующих накопительных обновлений в процессе установки нового экземпляра Exchange 2010 и за счет этого сократить общее время установки. Достаточно просто скопировать .msp-файл в этот каталог (рис. 1).

Рис. 1. Добавление msp-файла в каталог позволяет установить накопительное обновление

Не пытайтесь это делать при установке обновления, например обновленной до второго пакета исправлений версии или при установке второго пакета исправлений на первый. Это работать не будет, и на установка завершится с ошибкой. Обновления должны устанавливаться последовательно, а этот способ не позволяет это делать. Подробнее см. статью «Install the Latest Update Rollup for Exchange 2010» в библиотеке TechNet.

SP1 или SP2?

Вопрос Мы установили на своих пограничных серверах Exchange 2010 второй пакет исправлений. Установка завершилась без ошибок, но если посмотреть номер сборки с помощью командлета Get-ExchangeServer, можно увидеть версию 14.1.xx, что означает пакет исправлений 1. Что здесь не так?

Ответ Это немного запутанное, но совершенно ожидаемое поведение. При наличии пограничной подписки Microsoft не обновляет номера сборок в рамках стандартного процесса синхронизации EdgeSync. Если когда-либо понадобится перестроить всю подписку (например, когда используемый для EdgeSync сертификат устареет), вы увидите, что номера сборок тоже обновились.

Задержка с разрешениями

Вопрос Когда я пытаюсь добавить разрешение на полный доступ к почтовому ящику Exchange 2010, список почтовых ящиков наполняется очень медленно (на это уходит от нескольких минут до нескольких часов). С этим можно что-то сделать?

Ответ Это очень популярный вопрос. Причина того, что окно выбранных учетных записей заполняется так медленно заключается в неудачном запросе LDAP. Извлекаются все почтовые ящики, после чего применяется фильтр. Если, к примеру, вам нужен почтовый ящик Fred, вы сначала получаете список всех субъектов безопасности и только после этого проверяете, есть ли в списке нужный ящик. Это ужасающе медленный процесс, особенно если в системе много пользователей.

К счастью эта проблема исправлена в последнем и совершенно замечательном накопительном обновлении для Exchange 2010 SP2.

Интегрированная проверка подлинности

Вопрос Мы пытаемся включить интегрированную проверку подлинности Windows для OWA (Exchnage Outlook Web App), чтобы наши внутренние пользователи, являющиеся членами домена, могли пользоваться веб-почтой, не указывая учетных данных. Клиенты обращаются к кластеру с балансировкой нагрузки (NLB) по URL-адресу https://mail.contoso.com.

Мы отключили агент начальной нагрузки и включили проверку подлинности Windows в виртуальных папках OWA. Однако при обращении по адресу https://mail.contoso.com/owa все равно предлагается ввести имя и пароль. При доступе к OWA напрямую путем ввода URL-адреса сервера клиентского доступа, например https://cas1.contoso.com/owa или https://cas2.contoso.com/owa, указывать учетные данные не нужно. Но самое удивительное, что если ввести разрешенный IP-адрес имени mail.contoso.com, в нашем случае это https://10.1.1.150/owa, также удается войти без указания имени пользователя и пароля. Вы не могли бы нам помочь?

Ответ После детального изучения трассировок Netmon и Fiddler я наконец заметил изменение метода проверки подлинности (это видно в Fiddler) при переходе от https://10.1.1.150/owa (работает, пароль не запрашивается) к https://mail.contoso.com/owa (запрашивается пароль).

Оказывается, что при обращении по IP-адресу для аутентификации в OWA используется Windows NTLM. А при запросе NLB-кластера по полному доменному имени применяется Kerberos на сервере клиентского доступа.

Еще немного усилий и креативного применения команды setspn.exe –l и я обнаружил, что кто-то добавил запись SPN (Service Principal Name) для имени http/mail.contoso.com, которая соответствует учетной записи совершенно постороннего компьютера. Это заставляет клиентские компьютеры обращаться за билетом Kerberos (потому что в Active Directory есть соответствующая запись) и предъявлять его при обращении к серверу клиентского доступа. Последний не знает, что делать с билетами Kerberos, которые выпущены для совершенно другого сервера, поэтому я удалил повторный запрос проверки подлинности.

После удаления неправильной записи SPN сразу же заработала проверка подлинности Windows при обращении URL-адресу NLB-кластера и предложение ввести учетные данные больше не появлялось.

Рассогласование правовых оговорок

Вопрос Мы пытаемся создать правило транспорта, которое добавляло текст правовой оговорки в исходящую почту. В процессе тестирования мы обнаружили, что транспортные серверы по-видимому игнорируют это правило. Текст оговорок не добавлялся, даже после перезагрузки серверов-концентраторов, которая выполнялась, чтобы гарантировано обеспечить загрузку правила. Однако точно такое же правило отлично работает в тестовой среде. Вы не подскажете, в чем может быть причина?

Ответ Реальное правило, которое призвано выполнять описанную задачу, показано на рис. 2.

Рис. 2. Ожидается, что это правило должно добавлять правовую оговорку в конец исходящих сообщений

После проверки обычных в такой ситуации «подозреваемых» — репликация, транспортная служба не в курсе изменений и т. п. все выглядело безупречным. После этого мы проверили трассировку ExTRA, чтобы записать файл .etl с правилами, которые используются при обработке исходящей почты.

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

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

При анализе проблемы, я заметил, что параметр Default Remote Domain равен IsInternal:$true. Это заставляет сервер Exchange считать всю почту, поступающую на адрес *, внутренней и не добавлять текст правовой оговорки. Мы изменили значение обратно на false. Теперь текст правовой оговорки успешно применяется.

Henrik Walther носит звание Microsoft Certified Master, а также MVP по Exchange 2007 и обладает более чем 16-летним опытом работы в ИТ. Занимает должность архитектора технологий в Trifork Infrastructure Consulting (компании, находящейся в Дании и обладающей званием Microsoft Gold Certified Partner), а также работает в качестве технического писателя для Biblioso Corp. (находящейся в США компании, специализирующейся в области услуг по управлению документацией и локализации). Хенрик также работает по контракту в командах различных продуктов (в том числе в командах Exchange и Lync ) в Microsoft.Georg Hinterhofer носит звание Microsoft Certified Master for Exchange 2010. Он работает старшим инженером, специализирующимся исключительно по Microsoft Exchange. Он живет в Австрии, недалеко то Вены.