Exchange Queue — очередь за ответами (Exchange Queue & A)Тайм-ауты OWA, устранение неполадок командлетов и прочее

Кей Си Лемсон (KC Lemson) and Нино Билик (Nino Bilic)

В.: Мы недавно перешли с Exchange Server 2003 на Exchange Server 2007. Мы получаем жалобы, что веб-доступ к Outlook® (OutlookWeb Access, OWA) отключается по тайм-ауту для пользователей с ограниченным доступом, выбравшими вариант «Это личный компьютер» при входе в OWA 2007. Какой командой командной консоли Exchange можно проверить тайм-аут для личных компьютеров?

О Давайте на секунду остановимся. Сперва я объясню, зачем сделана возможность выбрать личный или общий компьютер (см. рис. 1), и покажу, как выбор обуславливает разницу в поведении. Цель – дать пользователю способ дать знать Exchange, какой уровень безопасности необходим – входите ли вы в OWA из общедоступного интернет-киоска в аэропорту, например, или с вашего домашнего компьютера. Администратор Exchange может принять решение по-разному относиться к этим типам сеансов. Например, администратор может настроить сеансы, прошедшие проверку подлинности, таким образом, чтобы они завершались быстрее на общедоступных компьютерах (скажем, за несколько минут), чем на личных компьютерах (максимум до трех дней). В зависимости от выбора пользователя, администратор может настроить и другие параметры по-другому. Например, администратор может позволить доступ к библиотекам документов SharePoint® и разделяемым папкам Windows® только при входе с личного компьютера. Конечно, это зависит от того, сделал ли пользователь правильный выбор. Если администраторы не верят, что пользователь сделает правильный выбор, они могут выставить значения тайм-аута и прочих параметров настройки одинаково для всех вариантов выбора.

Рис. 1** Общедоступный и личный типы сеансов позволяют по-разному настроить тайм-аут и другие параметры настройки **(Щелкните изображение, чтобы увеличить его)

Вариант, по поводу которого возник вопрос, был перенесен нами из Exchange 2003, когда в OWA впервые появилась проверка подлинности, основанная на формах. (Историческая справка: первая реализация проверки подлинности на основе форм была отчасти разработана талантливым менеджером программы. Не стану раскрывать ее имени, но могу сказать, что позднее она обрела славу и счастье, выпуская раз в два месяца статью для TechNet Magazine.)

Этот параметр на самом деле хранится в системном реестре, но, поскольку в Windows PowerShell™ есть интерфейс для обновления реестра, вы можете установить его при помощи командной консоли Exchange. Следующий пример устанавливает тайм-аут равным 1440 минутам, или одному дню, когда пользователь при входе выбирает вариант с личным компьютером:

set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout 
-value 1440 -type dword

Конечно, поскольку этот параметр хранится в системном реестре, можно обновить параметр реестра самостоятельно при помощи regedit, если вам угодно:

#include <standard disclaimer about mucking
   with the registry.h>
#include <musing from author about when as a
   company we will ever be able to stop making
   that standard disclaimer about mucking with
   the registry.h>

В любом случае, вам придется перезапустить IIS, чтобы быть уверенным, что OWA воспримет новое значение параметра. Это должно быть возможно сделать, выбрав Пуск | Выполнить и введя «iisreset /noforce».

В.: Мы поощряем каждого сотрудника, пользующегося полным клиентом MAPI Outlook, архивировать менее-чем-срочно необходимое содержимое в личные папки (PST-файлы). Однако архивированное содержимое недоступно, когда пользователь входит в Outlook Web Access из дома. Как сделать эти файлы PST доступными через интерфейс OWA?

О.: К сожалению, OWA не поддерживает доступ к файлам PST. OWA с самого начала строился как исключительно сетевой клиент. Мы проделали немало работы, чтобы быть уверенными, что на локальном компьютере не остается ни следа личных данных – это включает возможности вроде механизма безопасного отключения, впервые использованного в Exchange 2003, и технологии WebReady Document Viewing в Exchange 2007, которая проверяет, что на жестком диске не осталось кэшированных копий вложений. Поэтому доступ к PST-файлам из OWA идет вразрез с нашей целью создать простой в развертывании, только сетевой клиент.

При этом, в целом использование PST представляет интересный момент, который нам хотелось бы обсудить. Прошлой осенью мы встретились с заказчиком, пользователям которого была установлена квота в 200 МБ на размер почтового ящика, и практически у каждого пользователя был как минимум один PST-файл. Поскольку в этой организации была политика, позволявшая очистку и замену пользовательских компьютеров с минимальными затратами труда, все пользователи были обязаны держать свои PST-файлы на сетевом диске. Его резервное копирование выполнялось централизованно.

Во-первых, есть известные проблемы с доступом к PST-файлам, находящимся в сетевой папке. Точно так же, как OWA с самого начала разрабатывался исключительно для сети, PST-файлы предназначались для локального хранения. Не важно, насколько превосходна ваша сеть, она подвержена задержкам и прочим дефектам, которые могут сделать удаленное хранение данных (к которым в то же время нужен пользовательский доступ) проблематичным.

Во-вторых, квота на почтовый в этой организации была маловата (признаемся, мы живем в роскоши с корпоративным почтовым ящиком около 2 ГБ) по той причине, что они не хотели хранить все данные в Exchange, потому что тогда они были бы в ответе за резервное копирование всех этих данных. Тем не менее, с пользователями, хранящими свои данные в PST-файлах на сетевом диске, подлежащем резервному копированию, администраторы нисколько не выигрывали в работе. На самом деле, скорее всего, возникало больше работы по разным причинам, таким как: отсутствие контроля за единственным экземпляром в нескольких PST-файлах; расходы на техническую поддержку, связанные с проблемами с PST-файлами (такими как забытые пароли и общие сетевые проблемы); сложности с чисткой сообщений в PST-файлах после вирусной атаки; сложности с поиском сообщений в PST-файлах при возникновении юридических вопросов; издержки на поддержку отдельной системы резервного копирования; и т. д.

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

В.: У меня проблемы с командой командной консоли Exchange. Она просто не работает. Что не так?

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

Откройте сеанс командной консоли Exchange и введите start-transcript, как на рис. 2. Командная консоль Exchange начнет автоматически заносить все последующие команды в текстовый файл, как на рис. 3 (не волнуйтесь, приложение сообщит вам, где он находится). Чтобы прервать запись, вы просто вводите stop-transcript.

Рис. 2** Использование командлета start-transcript для записи используемых команд и их результатов  **(Щелкните изображение, чтобы увеличить его)

Рис. 3** Windows PowerShell сохраняет журнал использованных вами команд в файле TXT **(Щелкните изображение, чтобы увеличить его)

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

В.: Я увидел, что установка Exchange 2007 создает новое подразделение (OU) в корневом домене. Оно называется Microsoft Exchange Security Groups и содержит пять новых групп безопасности Exchange 2007. Можно ли переместить эти группы в другое подразделение? Или даже в другой домен?

О.: Это вопрос про универсальные группы безопасности (USG), которые создаются в корневом домене на стадии подготовки Active Directory. Это группы:

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Servers
• ExchangeLegacyInterop

Во времена Exchange 2000 и Exchange 2003 возможность перемещать группы безопасности по умолчанию (сервера Exchange домена и сервера Exchange предприятия) была ограниченной. Лучше даже сказать, что вы могли перемещать их, но в процессе вы наломали бы дров. (Дополнительные сведения об этой проблеме можно найти в статье базы знаний Майкрософт по адресу support.microsoft.com/kb/260914). Так что все это было весьма ограничено.

В Exchange 2007 ситуация изменилась. Пять групп по умолчанию могут быть перемещены. Вы можете перенести их в другое подразделение в том же домене или в совсем другой домен.

В случае, если вдруг вы «потеряете» эти пять групп и не будете знать, куда вы их переместили – какое подразделение и какой домен – вы всегда сможете проверить значение атрибута otherWellKnownObjects в следующем контейнере:

CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com

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

В.: Я нашел глобальную группу безопасности, называемую «Exchange Install Domain Servers», в моем домене. Для чего она нужна?

О.: Вы определенно ведете учет в Active Directory®. И в самом деле, в каждом домене, где установлены серверы Exchange 2007, будет группа, называющаяся «Exchange Install Domain Servers». Эта группа создается в подразделении Microsoft Exchange System Objects (MESO). Если вы посмотрите на эту группу, вы увидите, что она является членом группы «Exchange Servers» корневого домена, которая является универсальной группой безопасности.

Вкратце, «Exchange Install Domain Servers» используется для обхода возможной проблемы с длинными циклами репликации Active Directory, когда вы выполняете установку Exchange 2007 в одном из дочерних доменов. Предположим, что у вас есть корневой домен Root, дочерний домен Child и дочерний домен Child - Grandchild. (Мы знаем, что схема названий великолепна! Полагаете, что сможете угадать наши пароли?)

Чтобы начать установку Exchange 2007 в этой организации, первым делом вам необходимо расширить схему и подготовить домен Root. Это создает исходные пять универсальных групп безопасности, обсуждавшихся в предыдущем ответе.

Затем, пусть вам нужно произвести установку в домене Grandchild. Чтобы быть в состоянии запустить службы Exchange 2007 в локальном домене, программа установки помещает учетную запись сервера Exchange 2007 в группу Exchange Servers домена Root. Поскольку в этот момент вы в домене Grandchild, репликация членства в группе Exchange Servers может занять немало времени.

Exchange Servers является универсальной группой, и репликация членства в ней происходит для всего леса. Из-за потенциальной задержки в репликации возможно, что установка в домене Grandchild не сможет запустить службы, поскольку репликация разрешений не завершится к окончанию установки. Вот поэтому, когда первый сервер Exchange 2007 устанавливается в домене, в локальном домене создается группа Exchange Install Domain Servers.

Учетная запись сервера Exchange будет сделана членом этой группы во время установки. Членство в этой группе дает службам достаточно прав, чтобы запуститься по окончании установки, даже в том случае, когда репликации группы Exchange Servers из домена Root еще не произошло. Обратите внимание, что репликация в локальном домене обычно происходит быстрее, чем репликация между доменами.

В.: В документации по Exchange 2007 сказано, что нужно запускать установку с ключом /PrepareLegacyExchangePermissions даже до того, как схема расширена для Exchange 2007. Почему? (И не могли ли вы сделать название этого ключа подлиннее?)

О.: Мы рады слышать, что вы читаете документацию перед установкой. Как она вам?

Ключ /PrepareLegacyExchangePermissions (для краткости /pl), многословно говоря, дает службам обновления получателей (Recipient Update Services, RUS) Exchange 2000 и Exchange 2003 разрешения на запись в наборы свойств Exchange Information и Personal Information. В процессе расширения схемы Exchange 2007 несколько атрибутов (таких как Proxy Addresses) перемещаются из набора свойств Active Directory Public Information в набор свойств Exchange Information. По умолчанию, RUS Exchange 2000 и Exchange 2003 не обладают правами записи в набор свойств Exchange Information. На практике это означает, что, если вы сперва запустите расширение схемы Exchange 2007, это повредит службы обновления получателей Exchange 2000 и Exchange 2003, потому что они будут не в состоянии обновлять получателей! (Если вы хотите дополнительно почитать про эти наборы свойств, посетите наш блог по адресу msexchangeteam.com.)

Поэтому очень важно запустить установку с ключом /pl до того, как расширять схему для Exchange 2007. Следует также удостовериться, что закончена репликация этих изменений во все домены, где есть получатели Exchange 2000 или Exchange 2003 (чтобы службы обновления получателей существовали в этих доменах). Если позже новые домены добавляются к лесу, и вам необходимо создать в них службы обновления получателей Exchange 2000 или Exchange 2003, вам нужно выполнить установку с ключом /pl в этих доменах.

Поэтому, когда вы впервые запускаете установку с ключом /pl, вы значительно облегчите себе жизнь, сделав это под учетной записью с правами администратора предприятия. Тогда установка в корневом домене определит, для каких еще доменов это необходимо, и запустит для каждого из них установку с ключом /pl. Если не пользоваться учетной записью администратора предприятия, вам придется запускать установку с ключом /pl, пользуясь учетной записью с правами администратора домена в каждом домене отдельно. К счастью, документация Exchange 2007 четко описывает все требования к правам.

(И наконец, вы спрашивали, не могли ли мы сделать название этого ключа подлиннее?) Просто попробуйте трижды быстро произнести /PrepareLegacyExchangePermissions:

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

PrepareLegacyExchangePermissions

Мы планировали сделать его /PrepareLegacyExchangePermissionsWOWThisIsaReallyLongname, но потом мы выбрали более короткий и дружественный вариант /PrepareLegacyExchangePermissions.

Ладно, мы просто выдумали это. Но вы всегда можете пользоваться гораздо более коротким /pl. И это правда – мы клянемся!

Кей Си Лемсон (KC Lemson) - менеджер по пользовательской среде для Exchange Server. Свободное время она проводит в ожидании сообщения электронной почты, в котором будет сказано, куда вложить средства на обучение ее детей.

Нино Билик (Nino Bilic), технический руководитель для Exchange Server, занят подсчетами, сколько раз в течение обычного рабочего дня ему удастся сыграть в Halo.

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.