Пятница, на часах 16.55, вы закругляетесь с делами и готовитесь покинуть офис, как вдруг… звонит телефон. Вы отвечаете на звонок: оказывается, у пользователей трудности с подключением к почтовым ящикам через Outlook Anywhere. Что делать? И как предупредить эту проблему в дальнейшем? .

Ваши серверы клиентского доступа составляют только часть инфраструктуры Exchange Server 2010. Другие роли сервера Exchange постоянно требуют равного или даже большего внимания, и в каждой роли есть свой фокус для администрирования. Поскольку главная функция роли клиентского доступа — облегчать соединение для почтовых клиентов, все должно быть без каких-либо неожиданностей, ведь ваша цель в управлении этой ролью — гарантировать, что клиенты могут успешно подключаться к организации Exchange и получать доступ к своей корреспонденции. Администрирование сервера клиентского доступа подразумевает три основные задачи:

  1. Управление настройками сервера клиентского доступа.
  2. Текущий мониторинг эффективной работы сервера и диагностика.
  3. Решение возникающих проблем.

Управление настройками роли

Даже после того как серверы клиентского доступа запущены и работают, вам, по всей вероятности, потребуется периодически настраивать их параметры. Сервер клиентского доступа имеет множество настроек, которыми вы можете управлять; самые основные из них отображаются через Exchange Management Console (EMC). Для менее общих настроек следует использовать Exchange Management Shell (EMS), либо удаленно, либо с сервера Exchange.

Вы можете дистанционно управлять серверами клиентского доступа одним из двух способов. Первый из них заключается в установке Exchange Management Tools на своей рабочей станции. Этот инструмент предоставит вам такие же функции, как если бы вы непосредственно подсоединились к серверу клиентского доступа. Однако он имеет кое-какие ограничения, и, наверное, самое большое из них состоит в том, что его установка возможна только на 64-разрядной рабочей станции. Если ваши администраторы используют 32-разрядные клиенты Windows или Windows XP, эта стратегия удаленного управления не будет работать. Однако если вы работаете с 64-разрядной клиентской системой под управлением Windows Vista SP2 или более новыми версиями либо 64-разрядной серверной системой под управлением Windows Server 2008 R2 или Windows Server 2008 SP2, то можете установить Exchange Management Tools. Чтобы установить данный инструмент, запустите setup.exe с установочного диска Exchange, выполните настраиваемую установку и выберите Exchange Management Tools, как показано на экране 1. В качестве альтернативы для установки инструмента можно воспользоваться методом автоматической установки. Введите следующую команду:

setup.com/role: ManagementTools

Второй путь — использовать удаленно PowerShell. PowerShell на удаленном Exchange 2010 предоставит дистанционный доступ с любой рабочей станции, на которой установлен PowerShell 2.0 и Windows Remote Management (WinRM) 2.0. Затем можно удаленно запустить команды EMS на серверах клиентского доступа. Одно из преимуществ использования данного подхода заключается в том, что вы можете управлять серверами клиентского доступа с 32-разрядной клиентской системы. Диапазон поддерживаемых клиентских версий Windows также расширяется благодаря этому способу, потому что удаленно PowerShell можно использовать на таких старых операционных системах, как XP или Windows Embeded. И PowerShell 2.0, и WinRM 2.0. доступны в пакете Windows Management Framework Core, который можно загрузить по адресу support.microsoft.com/kb/968929.

 

Установка Exchange Management Tools
Экран 1. Установка  Exchange Management Tools

Windows Management Framework Core может быть установлено как на 32-, так и на 64-разрядных операционных системах, работающих под управлением XP SP3, Windows Vista SP1 или более новых версий.

После установки Windows Manage­ment Framework Core вы можете использовать PowerShell 2.0 для удаленного соединения с серверами клиентского доступа через удаленный виртуальный каталог PowerShell. Когда вы дистанционно подключаетесь к PowerShell, клиент загружает команды, к которым имеет доступ ваша учетная запись, и запускает их на рабочей станции. Эти команды в действительности работают на сервере клиентского доступа в фоновом режиме, но все выглядит так, как будто они запускаются на рабочей станции. Если вы подсоединились к компьютеру в домене и у вас есть SSL, активированный для виртуального каталога PowerShell, вы можете воспользоваться следующими командами с консоли PowerShell на своей рабочей станции, чтобы удаленно установить соединение:

$Session = New-PSSession
   -ConfigurationName Microsoft
   . Exchange -ConnectionUri https://
   contoso-ex01.contoso.com/
   PowerShell/-Authentication
   NegotiateWithImplicitCredential
Import-PSSession $Session

Мониторинг производительности и диагностика

Контролируя сервер клиентского доступа, вы можете максимально автоматизировать процесс. Подключаться и вручную проверять состояние серверов — ненужная трата времени. У нас есть несколько программных продуктов мониторинга, включая Microsoft System Center Operations Manager и Quest Software Spotlight on Messaging. Если можно отслеживать сервер клиентского доступа без дополнительного программного обеспечения, вы можете воспользоваться встроенным инструментарием Windows, однако необходимо заранее позаботиться о запуске мониторинга. Вы должны сосредоточиться на нескольких вещах, контролируя инфраструктуру серверов клиентского доступа.

Администраторы Exchange зачастую сразу обращаются к средствам устранения неполадок или проводят расширенную диагностику, когда возникает проблема. Однако можно осуществлять мониторинг своих серверов клиентского доступа с помощью журналов событий Windows, поскольку они могут уже на раннем этапе подать сигнал тревоги, если что-то не так. Exchange записывает события в журнал приложений. Вы можете проверять системный журнал на предмет наличия предупреждений и ошибок, которые имеют отношение к базовой операционной системе. Иногда ошибка, вероятнее всего, связана с Windows Server, а не с Exchange. В частности, необходимо уделять пристальное внимание событиям, относящимся к протоколам клиентского доступа, Аutodiscover и адресной книге. Когда сбои возникают на серверах клиентского доступа, образуются обычные проблемные области. Если что-то происходит с IIS, это может повлиять на доступ клиентов через Outlook Anywere App (OWA), Exchange ActiveSync, Exchange Web Service и Outlook Anywere, поэтому важно сохранять работоспособность IIS. Ошибки клиентского доступа по RPC не проявляются через IIS, так что важно как можно скорее разобраться с сообщениями об ошибках, источником которых является MSExchange.

Другая вещь, которую необходимо отслеживать, это производительность серверов клиентского доступа. Вы можете собрать информацию о «железе» и службах, чтобы убедиться, что они работают в пределах пороговых величин. Можно задействовать монитор производительности Performance Monitor, perform.exe, чтобы собрать всю информацию. Монитор производительности использует счетчики, которые Exchange Server делает доступными.

Вы можете отслеживать аспекты эффективной работы аппаратного обеспечения, а заодно и обслуживать конечные точки служб серверов клиентского доступа. Таблица 1 идентифицирует несколько ключевых счетчиков, которые нужно принять во внимание во время мониторинга производительности аппаратного обеспечения. Таблица 2 содержит объекты счетчиков производительности, которые связаны с конечными точками служб сервера клиентского доступа.

 

Таблица 1. Счетчики производительности аппаратного обеспечения
Счетчики производительности аппаратного обеспечения

 

Таблица 2. Объекты счетчиков производительности для конечных точек служб серверов Client Access Server
Объекты счетчиков производительности для конечных точек служб серверов Client Access Server

У каждой конечной точки службы сервера клиентского доступа свои уникальные потребности, поэтому одна пороговая величина не может быть применена ко всем службам. К примеру, задержка будет иметь более высокую величину порога при контроле ActiveSync, чем в контроле RPC Client Access. Таблица 3 содержит некоторые важные счетчики производительности для мониторинга служб и виртуальных каталогов.

 

Таблица 3. Счетчики производительности для конечных точек служб Client Access Server Service
Счетчики производительности для конечных точек служб Client Access Server Service

Выявление неисправностей клиентского соединения

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

Тестирование удаленного соединения. Один из лучших способов проверки соединения — использовать анализатор удаленного соединения Exchange Remote Connectivity Analyzer, который можно найти на www.testexchangeconnectivity.com. Этот онлайн-инструмент проверки соединения (экран 2), который поддерживается Microsoft, помогает установить, связана проблема с соединением к клиенту или с сервером Exchange.

 

Анализатор Exchange Remote Connectivity Analyzer
Экран 2. Анализатор Exchange Remote Connectivity Analyzer

Команды для тестирования соединения. Exchange содержит несколько команд, с помощью которых можно проверять разнообразные аспекты сервера клиентского доступа при выявлении проблем с соединением. В таблице 4 представлен список этих команд с описанием действий.

 

Таблица 4. Команды проверки соединения
Команды проверки соединения

Для команд проверки соединения необходим предварительно настроенный почтовый ящик, чтобы осуществить проверку виртуальных каталогов на сервере клиентского доступа. Прежде чем выполнять команды, необходимо создать учетную запись для их использования. Чтобы создать учетную запись, используйте сценарий PowerShell под названием NewTestCasConnectivityUser.ps1. Этот сценарий находится в папке Scripts в каталоге установки Exchange, по умолчанию это C:\Program Files\Microsoft\Exchange Server\V14\Scripts. Вы можете выполнить сценарий без каких бы то ни было параметров или указать организационную единицу (OU) для учетной записи и ее настройки Unified Messaging. Когда вы создадите учетную запись, задайте одноразовый пароль. Он больше не понадобится, потому что после создания учетной записи им управляет Exchange и он постоянно изменяется.

Запись диагностики. Чтобы выйти на более детальный уровень устранения неисправностей, можно включить запись диагностики для некоторых компонентов сервера клиентского доступа. Exchange 2010 предусматривает интерфейс для работы в ЕМС. Вы можете получить доступ к интерфейсу записи диагностики для серверов клиентского доступа, выбрав Server Configuration, Client Access. Укажите сервер клиентского доступа, для которого будет включена запись журнала, и выберите Manage Diagnostic Logging Proprties на панели Action. Журналы, которые генерируются в процессе диагностики, записываются в раздел Application журналов событий Windows.

Журналы работы протоколов. Службы RPC Client Access, Address Book, IMAP4 и POP3 предоставляют возможность включения журналов работы протокола. Журнал протокола делает наглядным согласование между клиентом, который пытается подключиться, и отвечающим сервером. Эти журналы хранятся как файлы с разделителем запятой, которые открываются в любом текстовом редакторе. Одна часть информации журналов протоколов может быть общей для всех служб, но другая часть относится исключительно к той службе, для которой записывается. На экране 3 показан журнал работы протокола для службы RPC Client Access. Этот журнал содержит полезную информацию для устранения неисправностей RPC Client Access, такую как клиентская программа (outlook.exe), версия (12.0.4518.1014) и даже режим работы (с кэшированием).

 

Журнал протокола для службы RPC Client Access
Экран 3. Журнал протокола для службы RPC Client Access 

Журнал протокола включается для служб либо с помощью файла конфигурации службы, либо через EMS. По умолчанию журналы расположены здесь: С:\Program Files\Microsoft\Exchange Server\V14\Logging.

В таблице 5 показано, как включать журнал протокола.

 

Таблица 5. Включение протокола работы журналов для служб Client Access Server
Включение протокола работы журналов для служб Client Access Server

Для клиентских протоколов, которые используют IIS (OWA, Exchange Control Panel, Exchange ActiveSync, Exchange Web Service, Аutodiscover, Outlook Anywhere и удаленный PowerShell), можно использовать журналы IIS, чтобы объединить сходную информацию. По умолчанию эти журналы находятся в папке C:\inetpub\logs\LogFiles.

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

Серверы клиентского доступа составляют лишь отдельную часть целостной инфраструктуры Exchange — в основном прицеле администраторов Exchange находится управление данными на серверах почтового ящика.

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

Кен Сен-Сир (ken.stcyr@microsoft.com) — архитектор решений компании Microsoft с более чем 10-летним опытом работы. Имеет сертификат Microsoft Certified Master in Directory Services