Уроки из центра обработки данных: управляемая доступность – Русский блог Microsoft Exchange. Установка агента на сервере Edge Server

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке .

Установка агента на сервере Edge Server

Сервер Edge Transport можно установить в качестве отдельного сервера или в качестве члена домена Active Directory.

Если вы помните топологию из первой части, я решил установить Edge Server в качестве отдельного сервера (рабочей группы). Это означает, что аутентификация на сервере Operations Manager будет происходить с помощью сертификатов, поскольку агент в рабочей группе не может аутентифицироваться на сервере управления в домене, используя протокол Kerberos.

Рисунок 1: Аутентификация с помощью сертификата

В этом сценарии агента нужно установить вручную. Хотя установка агента доступна с носителя установки Operations Manager, мы воспользуемся исполняемыми файлами с сервера Management Server, так как необходимые исправления там уже есть.

1. Вернитесь обратно в папку, куда устанавливали OpsMgr на сервере управления (\\OpsMgr\D$\Program Files\System Center Operations Manager 2007\AgentManagement\AMD64\ ) и выполните любое имеющееся там исправление (в моем случае было лишь Q950853-x64.msp).

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

Выполните следующие шаги на обоих компьютерах, содержащих агента и сервер управления, используя один и тот же центр сертификации (ЦС) для каждого:

Запросите сертификаты с ЦС

Примите запрос сертификата на ЦС

Установите одобренные сертификаты в хранилища сертификатов компьютеров

Используйте инструмент MOMCertImport для настройки Operations Manager 2007

Можно использовать личный ЦС, не обязательно покупать публичные сертификаты. В зависимости от типа внутреннего ЦС, который вы используете ‘ Enterprise или Standalone ‘ процедуры издания требуемых сертификатов будут немного различаться. Разница состоит в шаблонах, нужных для сертификата: отдельный ЦС (Stand-Alone CA) позволит указать OID для типа требуемого сертификата, а производственный (Enterprise) ЦС имеет хорошо определенный шаблон, который можно использовать. Вот почему для Enterprise CA нам нужно создавать и включать новый шаблон сертификата.

ЗАМЕТКА: для создания и включения необходимого шаблона нужно использовать службу сертификатов Windows Certificate Service на сервере версии Windows Server Enterprise Edition. Если у вас нет версии Enterprise Edition, я советую вам установить новый отдельный ЦС.

Поскольку на моем контроллере домена уже установлен Stand-Alone CA, я опишу шаги по установке такого типа ЦС.

Выполните эти шаги на сервере Edge и сервере OpsMgr (обоим требуется сертификат):

1. Для одобрения ждущего запроса сертификата войдите на компьютер, содержащий службу сертификации (Certificate Services) в качестве администратора и откройте консоль администрирования центров сертификации (Certification Authority). Разверните вкладку имени вашего ЦС, а затем нажмите на Ждущие запросы (Pending Requests) . В появившейся панели правой клавишей нажмите на ждущем запросе с предыдущей процедуры, наведите курсор на Все задачи и выберите Издать (Issue) .
2. Для получения сертификата войдите на компьютер, на который устанавливаете сертификат (и с которого вы выполняли запрос). Запустите обозреватель Internet Explorer и подключитесь к компьютеру со службой Certificate Services (http:///certsrv). a) На странице приветствия Microsoft Certificate Services Welcome нажмите Показать статус ожидающего запроса сертификата (View the status of a pending certificate request) . b) На странице Просмотр статуса ожидающего запроса сертификата нажмите на сертификате, который запрашивали. c) На странице Сертификат издан (Certificate Issued) нажмите Установить этот сертификат . В диалоговом окне Потенциальное нарушение безопасности выберите Да (Yes) . d) На странице Сертификат установлен (Certificate Installed) после того, как увидите сообщение Ваш новый сертификат был успешно установлен , закройте обозреватель.
3. Поскольку оба сервера должны доверять ЦС, выпустившему сертификаты, нам необходимо импортировать сертификат ЦС на обе машины (Edge и OpsMgr). Запустите обозреватель Internet Explorer и подключитесь к компьютеру со службой сертификации Certificate Services (http:///certsrv). a) На странице приветствия нажмите Загрузить ЦС сертификат, цепь сертификатов или CRL (Download a CA Certificate, certificate chain, or CRL) . b) На странице Download a CA Certificate, Certificate Chain, or CRL выберите Загрузить цепь ЦС сертификатов . c) В диалоговом окне нажмите Сохранить , укажите имя файла (.P7B), а затем снова нажмите Сохранить . Закройте обозреватель.
4. Выполните MMC и добавьте оснастку Сертификаты (в диалоговом окне оснастки сертификатов выберите для учетной записи компьютера , а затем нажмите Далее . Убедитесь, что выбран Локальный компьютер и нажмите Завершить ). Разверните Сертификаты (локальный компьютер) , разверните Доверенные корневые центры сертификации (Trusted Root Certification Authorities) , правой клавишей нажмите Сертификаты , выберите Все задачи и нажмите Импортировать . Найдите место, в которое вы сохранили файл.P7B и импортируйте сертификат.
5. Для импортирования сертификата используйте MOMCertImport, перейдите к папке, где находятся исполняемые файлы установки Operations Manager 2007. Утилита MOMCertImport расположена в \SupportTools\i386 (для 64-разрядных компьютеров \SupportTools\amd64). Выполните следующую команду: MOMCertImport /SubjectName

(Можно также экспортировать ранее изданный сертификат в.PFX файл и выполнить команду MOMCertImport .pfx )

Рисунок 11: Выполнение MOMCertImport

Если нужно удалить импортированные сертификаты с помощью команды MOMCertImport, просто выполните MomCertImport /Remove .

Разрешение ручной установки агента

Перед первой ручной установкой агента глобальные параметры необходимо изменить с отвержения на ‘Просмотр новой ручной установки агента в ожидающем виде управления (Review new manual agent installation in pending management view)’ в консоли действий OpsMgr 2007.

Откройте консоль действий (Operations Console) и в панели Администрирование выберите Настройки . В правой панели разверните вкладку Сервер и нажмите правой клавишей на Безопасность (рисунок 12). Выберите Свойства и в закладке Общие выберите опцию Просмотр новой ручной установки агента в ожидающем виде управления (рисунок 13). Нажмите OK для завершения.

Рисунок 12: Разрешение ручной установки агента

Рисунок 13: Глобальные параметры сервера управления — безопасность

После каждой ручной установки агента каждый новый агент должен быть одобрен в консоли System Center Operations Manager Console:

Откройте консоль Operations Console, в панели Администрирование разверните вкладку Управление устройствами и выберите опцию Ожидающее управление (Pending Management) . В правой панели правой клавишей жмите на каждом сервере, требующем одобрения, и выбирайте опцию Одобрить (рисунок 14).

Для проверки успешности одобрения агента посмотрите в папку Управляемый агент (Agent Managed) на предмет наличия там одобренного агента.

Рисунок 14: Одобрение установленного вручную агента

Заключение

На этом мы закончим вторую часть данной серии. В следующей части мы рассмотрим процесс настройки System Center Operations Console, необходимый для мониторинга серверов Exchange 2007 с помощью диспетчера Operations Manager 2007.

Источник http://www.msexchange.org

Businesses today rely on their mail and messaging systems more than any other piece of infrastructure. Seasoned Exchange administrators know that it is absolutely important to monitor Exchange 24X7, not only to prevent downtime and quickly fix problems after they arise, but also to know the health of individual components and to identify potential problems and performance degradations before they turn into costly downtime.

OpManager"s Exchange Monitor Benefits

• Detect Exchange problems quickly
• Pin-point the exact point of failure
• Minimize Exchange downtime
• Know the health of your Exchange Server, inside out

Exchange Monitor"s Features

Exchange Monitoring - Monitoring of Exchange Services

Exchange Server depends on certain critical services for proper operation.The first step in ensuring Exchange availability is to monitor these critical services.

Exchange Monitor monitors the following critical services

• Simple Mail Transfer Protocol (SMTP) that transports electronic mail across the network.
• Exchange Information Store (IS) that manages Microsoft Exchange Information Storage.
• Exchange MTA Stacks that provide Microsoft Exchange X.400 services.
• Exchange Routing Engine that processes Microsoft Exchange routing information.
• Exchange System Attendant that provides system related services for Microsoft Exchange.

When any of these services become unavailable, your Exchange Server will not be able to perform critical tasks properly.

Exchange Monitoring - Monitoring of Information Store

Exchange"s Information Store (IS) serves email requests within a particular Exchange Server domain. Problems like information store thread spending a lot of time looking up an account security identifier (SID) in the Active Directory directory service or the IS intermittently stopping to respond can occur. By continuosly monitoring the IS & configuring thresholds, such situations can be got ridden of.

Exchange Monitoring - Monitoring of Queues & Connections

A growing queue of connections/active connections is a sure indicator of trouble. A growing queue may mean that the Exchange server is under attack from spam. The number of connections can grow too if an Exchange Server malperforms & fails to close the connections. A potential blockage can appear due to a large number of queues and/or connections which will cripple Exchange"s performance. Hence monitoring queues & connections will help identify such bottle-necks early on. And OpManager"s Exchange Monitor does a good job in identifying this through setting up of thresholds & notifying you of the imminent failure.

Exchange Monitoring Dashboard

Exchange Monitor offers an intuitive dashboard which gives you an overall picture of your Exchange health at-a-glance.

MS Best Practices - Setting Up Thresholds

Exchange Monitor includes more than 60 critical parameters that need to be monitored out-of-the-box. Also several monitors come with pre-configured thresholds set according to best practices recommended by Microsoft. You can start with these values and fine-tune it based on actual baseline values in your organization.

Need Features? Tell Us

If you want to see additional Exchange Monitoring features implemented in OpManager, we would love to hear.

Каждому администратору, обслуживающему систему Exchange Server , хочется иметь информацию о малейших ее сбоях. Многие разумно предпочитают заниматься незначительными неполадками, чтобы потом не устранять более масштабные проблемы. Возможно, кто-то из читателей полагает, что для этого требуется программный пакет средств мониторинга и управления, такой, например, как Microsoft Operations Manager (MOM), OpenView компании HP или Spotlight on Exchange компании Quest Software. Разумеется, перечисленные изделия наделены массой полезных функций, но многие наверняка будут удивлены обилием средств мониторинга и контроля, реализованных в Exchange и Windows. Администратор может следить за работой служб и приложений, управлять службами и получать уведомления без каких-либо дополнительных затрат. С помощью встроенных инструментов можно управлять сразу несколькими серверами. Более сложные инструменты могут быть полезны при переходе от небольшой группы серверов к организациям Exchange, состоящим из множества серверов, расположенных в различных местах, или в тех случаях, когда необходимо строго соблюдать соглашения об уровне обслуживания (Service Level Agreements, SLA), в которых большое значение придается извещениям о проблемах на ранних стадиях.

Основы мониторинга служб

Функционирует ли интересующий меня сервер? Пожалуй, на этот вопрос ответить проще всего, но между тем он относится к числу самых важных. Многие администраторы, как правило, проверяют состояние серверов средствами диспетчера Exchange System Manager (ESM).

Чтобы проверить состояние любого виртуального сервера, нужно раскрыть узел протокола в контейнере Protocols, расположенном под сервером, а затем найти знакомый кружок красного цвета. Подобная мера вполне целесообразна в качестве первого шага. Но при этом мы узнаем только одно - активен ли виртуальный сервер. Базовая служба не может быть остановлена без какого-либо указания на это в ESM , кроме красного «X», поэтому нам непросто определить, что именно случилось: остановлен экземпляр виртуального сервера, произошел сбой базовой службы или эта служба была отключена.

Более надежный источник данных - приложение панели управления Services (services.msc). Эта небольшая служебная программа позволяет просматривать и изменять состояние служб Exchange , а также служб, необходимых для их функционирования. Для подключения к другому серверу достаточно правой клавишей мыши щелкнуть на значке Services (Local) и выбрать команду Connect to another computer. Это очень удобно в тех случаях, когда требуется управлять серверами с помощью настольной системы или ноутбука. Приложение позволяет определять, функционирует ли служба в данный момент; администратор может останавливать и перезапускать службы, а также задавать условия их запуска. Приложение Services можно использовать для получения дополнительной информации в тех случаях, когда ESM сообщает, что служба не функционирует в штатном режиме.

Разумеется, не каждый администратор захочет выполнять любую задачу с помощью графического интерфейса. Службами можно управлять и из командной строки. Для этого существует два метода: проверенные временем команды NET и команда Sc. Скорее всего, многие уже знакомы с командами NET START и NET STOP; при их использовании необходимо вводить имя службы, которой предстоит управлять (скажем, с помощью команды NET STOP msexchangeIS можно остановить выполнение службы Information Store ). Если ввести только имя команды NET START без указания аргументов, на экране будет отображен список всех служб, функционирующих в системе, в которой вы зарегистрировались; эта функция может быть полезной, когда требуется установить, какие службы функционируют в данный момент. Если же попытаться остановить службу, от функционирования которой зависят другие службы (скажем, System Attendant ), NET STOP предложит подтвердить команду, если вы не присоединили к ней переключатель /y.

Команда Sc более функциональна, но для ее использования придется проделать кое-какую дополнительную работу. Для начала полезно вспомнить, что с помощью команды Sc администратор может обращаться к службам на других серверах; достаточно указать имя сервера (имя NetBIOS или полностью уточненное имя DNS), перед которым следует ввести две обратные косые черты. С командой Sc можно использовать несколько командных глаголов:

• Sc query извещает администратора о состоянии указанной службы (которая, будем надеяться, функционирует в данный момент), о том, какие управляющие команды она готова принимать, а также о ее последнем коде выхода.
• Sc qc показывает имя службы, способ запуска (автоматический, ручной или “отключено”), путь к двоичному образу, описательное имя (display name), учетную запись, использованную для запуска службы, и зависящие от нее службы.
• Sc queryex отображает ту же информацию, что и Sc query, плюс идентификатор процесса службы, который иногда требуется для того, чтобы завершить зависший процесс; эти сведения могут понадобиться в случае зависания службы SMTP при появлении искаженного сообщения.
• Sc start и Sc stop выполняют задачи, указанные в их именах, т. е. запускают и останавливают службы. Каждую службу необходимо останавливать своей командой, поскольку одна команда не в состоянии остановить службу и зависящие от нее компоненты. Sc имеет еще одну особенность, в отличие от команд NET: последние не возвращают управление пользователю до тех пор, пока команда либо не завершила выполнение запроса, либо не дала сбой при попытке его выполнения. Между тем Sc просто передает команду и немедленно возвращает управление, отображая при этом состояние START_PENDING или STOP_PENDING.
• Sc enumdepend отображает список служб, функционирование которых зависит от указанной службы. Эту команду полезно применять в сочетании с командой Sc stop; таким образом, можно начинать с остановки зависимых служб.

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

Настройка служб для повторного запуска в автоматическом режиме

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

1. Запустить приложение Services.
2. Открыть диалоговое окно Properties целевой службы.
3. Перейти на вкладку Recovery, показанную на рис. 1. По умолчанию службы Exchange настроены таким образом, что в случае аварийного сбоя никакие действия не предпринимаются. Однако можно указать другие настройки: запустить службу повторно, выполнить внешнюю программу (это может быть сценарий) или перезапустить компьютер. Так, служба IIS Admin в случае отказа запускает файл iisreset.exe с переключателем /start. Задача этого исполняемого модуля в том, чтобы очистить службу и обеспечить ее нормальный перезапуск.
4. В качестве первой меры при сбое служб Exchange указать перезапуск соответствующей службы.
5. В качестве второй меры на случай сбоя предусмотреть отправку средством уведомления соответствующего сообщения непосредственно на какую-либо другую учетную запись или устройство, работу которого вы контролируете.

В окне диспетчера ESM есть узел Monitoring and Status (он располагается внутри узла Tools). Должен признать, что большинство администраторов Exchange из тех, с кем мне доводилось встречаться, никогда не пользовались этими инструментами, что весьма прискорбно. Конечно, инструменты, о которых идет речь, не могут заменить такие пакеты, как, скажем, MOM , но они наделены рядом весьма полезных функций. Начнем с узла Status (см. рис. 2). Он предоставляет сводные данные по состоянию всех коннекторов Exchange и серверов организации. Администратор видит, какие коннекторы находятся в рабочем состоянии, а какие отключены; увидев отключенный коннектор, он должен вручную проверить виртуальный сервер, на котором тот расположен, и систему на другом конце канала связи, поскольку ESM не дает информации о том, в чем именно состоит проблема. В этом случае может оказаться полезным инструментальное средство Winroute; оно отображает таблицу маршрутизации, которая может помочь установить, что является причиной проблемы.

Другие объекты, за которыми можно наблюдать с помощью узла Status, пожалуй, представляют больший интерес. По умолчанию каждый сервер имеет компонент состояния, именуемый . Этот компонент в сочетании с инструментарием управления Windows WMI (Windows Management Instrumentation) обеспечивает мониторинг состояния хранилища Information Store, стеков агента Message Transfer Agent (MTA), процессора маршрутизации, компонента System Attendant , виртуального сервера SMTP, а также Web-служб IIS. Если какая-либо из этих служб останавливается, состояние контролируемого компонента меняется на критическое, и диспетчер ESM рассылает уведомления; к сожалению, для получения новых данных администратор должен следить за состоянием узла Status. Однако все эти службы проверяются с помощью инструментария WMI, что может приводить к некоторому запаздыванию отчетов. К примеру, когда я останавливаю агент MTA на одном сервере и вновь запускаю его через минуту-другую, ESM на другом сервере может не зафиксировать перерыв в работе. Поэтому, если используется данное средство мониторинга, следует чаще нажимать клавишу F5, чтобы инициировать обновление ESM. Кроме того, можно создавать собственные мониторы состояния на базе любого из шести типов ресурсов, которыми располагает ESM .

Счетчик доступной виртуальной памяти дает возможность устанавливать максимальные процентные значения для используемой виртуальной памяти. Если сервер превышает пороговое значение в течение указанного периода, при обновлении узла Status система выдаст соответствующее уведомление. Администратор может устанавливать как предупредительные, так и критические пороговые значения, что обеспечивает возможность получения своевременных предупреждений о нехватке ресурсов.

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

Счетчик свободного дискового пространства обеспечивает мониторинг отдельных накопителей. Администратор может получать предупреждение в случае, если объем доступного пространства становится меньше установленного значения. Эта функция весьма полезна при работе с томами, выделенными для регистрации транзакций, поскольку нехватка пространства на таких дисках может привести к неприятным последствиям.

Счетчики увеличения очередей SMTP и X.400 позволяют отслеживать динамику состояния очередей. Если какая-либо очередь заданного типа постоянно увеличивается в течение указанного периода, администратор получает соответствующее уведомление.

Следует использовать счетчики состояния служб Windows для мониторинга служб по своему выбору. Если службы, за которыми администратор хотел бы наблюдать, имеют отношение к системе Exchange, но не включены в объект Default Microsoft Exchange Services , он должен включить их в этот объект или создать собственный. Узел Notifications обеспечивает отправку сообщений электронной почты или запуск сценариев при переходе контролируемого объекта к критическому или пороговому состоянию. Щелкнув на этом узле правой клавишей мыши, можно запустить команды New E-Mail Action или New Script Action; последние, в свою очередь, отображают диалоговое окно Properties, показанное на рис. 3. Администратор может выбрать сервер, который будет осуществлять мониторинг, серверы и коннекторы, которые станут объектами мониторинга (один сервер или коннектор, все серверы или коннекторы в группе маршрутизации либо определяемый пользователем набор серверов или коннекторов), а также текст сообщения, который будет передаваться в процессе уведомления. Разумеется, решить эту задачу можно только в том случае, если принять саму идею отправки критических уведомлений о состоянии системы обработки электронной почты по каналам этой системы. К примеру, вряд ли можно считать наилучшим решением извещение администратора о полном выходе сервера из строя (если только в данной системе каждый сервер не используется для наблюдения за другими серверами; к сожалению, настройки для выполнения подобной задачи придется вводить вручную).

Уведомления на базе сценариев реализуются аналогичным образом. Для этой цели используются обычные сценарии VBScript или исполняемые модули, и, когда контролируемые серверы или коннекторы изменяют свое состояние так, что превышаются заданные критические значения, запускается сценарий или исполнимый модуль с параметрами, указанными администратором в командной строке. Это хороший способ для ввода в действие пейджеров или средств уведомления с помощью SMS от независимых поставщиков либо для запуска сценариев, выполняющих нестандартные задачи. К примеру, можно написать небольшой сценарий, который будет направлять уведомления на устройство Ambient Orb или Dashboard либо на «интеллектуальные» часы Microsoft SPOT; такой сценарий позволит, минуя каналы электронной почты, получать информацию о том, что в системе возникли какие-то неполадки.

Уведомления об увеличении размеров очередей SMTP

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

Запустить ESM.

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

Нажать кнопку Add.

В диалоговом окне Add Resource выбрать элемент SMTP queue growth и нажать ОК.

В диалоговом окне SMTP Queue Thresholds установить флажки Warning state (minutes) и Critical state (minutes); указать количество минут, по истечении которых постоянно увеличивающаяся очередь будет считаться достигшей критического состояния; по завершении нажать ОК.

Нажать кнопку ОК, чтобы закрыть диалоговое окно Properties.

Раскрыть узел Tools.

Раскрыть узел Monitoring and Status, правой клавишей мыши щелкнуть на папке Notifications и выбрать команду New, Script notification.

Нажать кнопку Select и выбрать сервер, мониторинг которого планируется осуществлять.

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

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

Трассировка сообщений

Функцию трассировки сообщений едва ли следует относить к средствам мониторинга, однако ее можно использовать в качестве грубого инструмента для определения состояния сервера. Бывает, что я ожидаю поступления на сервер Exchange сообщений по электронной почте, а их все нет. Причин может быть две: либо действительно никто ничего не пишет (даже спамеры), либо в инфраструктуре Exchange возникли какие-то проблемы. Существует способ, позволяющий быстро определить, в чем дело. Нужно запустить средство трассировки сообщений Message Tracking Center в узле Tools диспетчера ESM и выполнить быструю проверку сервера-моста SMTP на предмет наличия сообщений, поступивших на протяжении интересующего периода. Этот способ в сочетании с проверкой файлов регистрации прибора Barracuda Spam Firewall позволяет быстро установить, поступает ли почта в обычном режиме. Если нет, трассировка нередко указывает пункт, где сообщение «сбилось с курса». Это средство мониторинга весьма полезно, если использовать его в сочетании с функцией получения уведомлений в тех ситуациях, когда коннектор, по всей видимости, вышел из строя.

Чего не может ESM

А что если администратору необходимо отслеживать или контролировать показатели, не улавливаемые средствами ESM? В этом случае можно обратиться к интерфейсам WMI из комплекта Windows и Exchange и написать собственные сценарии для проведения мониторинга интересующих администратора показателей. Эта задача может вызвать затруднения у тех, кому никогда прежде не доводилось писать сценарии, но на самом деле она не так уж сложна. Вооружившись подготовленным специалистами Microsoft пособием Scripting Guide, а также двухтомным трудом Leveraging WMI Scripting и Understanding WMI Scripting Алана Лиссо, администратор получит в свое распоряжение все необходимые исходные материалы, а также множество примеров сценариев, которые можно приспособить для конкретных нужд.

Конечно, в некоторых сетях администраторам могут понадобиться дополнительные функции таких инструментальных средств, как MOM или Spotlight on Exchange. Эти средства способны интегрировать и отображать целый ряд параметров состояния. Они наделены гораздо большим числом функций мониторинга состояния серверов и уведомления администраторов в случае неполадок. Если администратор отвечает за сложную многосерверную среду или если в соответствии с требованиями коммерческого характера ему необходимо иметь более детализированное представление о состоянии системы обмена сообщениями, вероятно, лучше воспользоваться этими инструментами, а не создавать собственные. Итак, подведем итоги. Продуманное использование средств мониторинга диспетчера ESM в сочетании с инструментами мониторинга производительности, реализованными в Windows, позволит с большей точностью диагностировать состояние серверов Exchange и заблаговременно устранять небольшие проблемы.

For the purpose of writing this article, I installed the following environment on my test lab:

Figure 1: Solution topology used in this article

Table 1: List of servers

Exchange 2013 Management Pack Pre-requisites and Considerations

Before importing the Exchange 2013 MP into System Center Operations Manager, there are some pre-requisites that have to be met:

You have one of the following versions of System Center Operations Manager deployed in your organization:

• System Center Operations Manager 2012 RTM or later
• System Center Operations Manager 2007 R2 or later

You have already deployed SCOM agents to your Exchange Servers.

The SCOM agents on your Exchange Servers are running under the local system account.

The SCOM agents on your Exchange Servers are configured to act as a proxy and discover managed objects on other computers.

If you are monitoring Exchange Server 2013 Database Availability Groups (DAGs), ensure that all DAG members are monitored by Operations Manager.

Before downloading and installing the Exchange Server 2013 MP, you might want to import some recommended additional management packs, such as (these are the ones I used):

Add the Exchange servers as agent managed computers

Adding the Exchange servers to monitor as agent managed computers is the first required step.

1. Click the Administration tab and then click Configure computers and devices to manage on the Actions pane. This will start the Computer and Device Management Wizard (Figure 2). Click Next , choose Advanced Discovery (Figure 3) and select Servers Only from the Computers and Device Classes drop-down box.

Figure 2: Computer and Device Management Wizard

Figure 3: Advanced discovery

1. On the next window, browse for the computers you are adding (Figure 4) and click Next . Select Use selected Management Server Action Account (Figure 5), click Discover and wait for the discovery results (Figure 6). Figure 7 shows a brief summary that is displayed at the end of the wizard. It is mandatory that all systems running Exchange Server 2013 that are managed by Operations Manager use Local System as the Agent Action Account. Click Finish .

Figure 4: Discovery Method

Figure 5: Administrator Account

Figure 6: Select Objects to Manage

Figure 7: Summary

1. If the agent installation was successful, on each Exchange server you’ll be able to see the System Center 2012 - Operations Manager Agent listed on the Programs and Features on Windows 2012 (Figure 8). A new service is also created, the System Center Management Service , as depicted in Figure 9.

Figure 8: Programs and Features (Add/Remove Programs)

Figure 9: System Center Management Service Properties

1. To enable Agent Proxy configuration on all managed Exchange servers, in the Administration pane, under Administration , Device Management , Agent Managed , right-click on each Exchange server (Figure 10), select Properties , then the Security tab (Figure 11), and check the box Allow this agent to act as a proxy and discover managed objects on other computers . This step will also make exchange cluster instances to appear in the Agentless Managed section (ensure that all physical nodes of the cluster are monitored). Repeat the process for every managed Exchange 2013 server in the list

Figure 10: Agent Managed Properties

Figure 11: Enabling Agent Proxy

Create a new management pack for customizations

The customizations and overrides of sealed management packs, such as the Exchange 2013 MP, are usually saved in the default management pack. As a best practice you should create and use an unsealed management pack for each sealed management pack that you want to override, as shown in Figure 12.

Figure 12: Unsealed management packs

Creating a new management pack for storing overrides has the following advantages:

• It simplifies the process of exporting customizations that were created in your test and pre-production environments to your production environment.
• It allows you to delete the original management pack without first needing to delete the default management pack.
• It is easier to track and update customizations to individual management packs.

1. In the Operations Console, click the Administration button. In the Administration pane, right-click Management Packs and then click Create Management Pack . The Create a Management Pack wizard displays.
2. In the General Properties page (Figure 13), type a name for the management pack in Name , the correct version number in Version , and a short description in Description . Click Next and then Create .

Figure 13: Creating a Custom MP for customizations

Install the Exchange Server 2013 MP

With the recommended additional management packs already imported, download and install the latest Microsoft Exchange Server 2013 Management Pack (at the time of the writing of this article it was version 15.00.0620.018). You can find the latest Management Packs at the Microsoft System Center Marketplace .

Let’s look at the installation steps of the Exchange 2013 Management Pack:

1. Download the management pack file and launch the Microsoft Installer (MSI) package on the selected SCOM server. Accept the license agreement, and click Next (Figure 14).

Figure 14: License Agreement

1. Accept the default installation folder or select a new one. Click Next (Figure 15). The extraction process begins.

Figure 15: Select Extraction Folder

1. When the extraction ends, click Close (Figure 16). When the installation is complete, the management pack files are copied to the System Center Management Packs folder.

Figure 16: Extraction Complete

1. To import the Exchange 2013 MP, open the SCOM 2012 Operations Console. Click the Administration tab, right-click the Management Packs node and then click Import Management Packs (Figure 17).
2. Click Add , Add from disk and then click No on the Online Catalog Connection window. Select all the files from the Exchange MP directory, by default C:\Program Files\System Center Management Packs (Figure 18), click Open and then click the Install button (Figure 19).

Figure 17: Import Management Packs

Figure 18: Select Management Packs to import

Figure 19: Import Management Packs

1. The Import Management Packs page appears and shows the progress for each management pack. After the import process is complete and the dialog box displays an icon next to each Management Pack that indicates success of the importation (Figure 20), click the Close button. Click View and then Refresh , or press F5, to see the Microsoft Exchange Server 2013 management pack in the list of Management Packs.

Figure 20: Import Succeeded

After importing the Exchange 2013 MP, it will start immediately discovering Exchange machines. So, if you browse to the Discovered Inventory pane on the Operations Console (Figure 21), all the Exchange 2013 servers should be listed. Notice that the Database Availability Group (DAG) is also listed, although its state is Not monitored . This is a normal behavior, since the physical nodes of the DAG are already being monitored.

Рассмотрим пример мониторинга состояния кластера DAG Exchange Server 2016 и баз данных в нем с помощью PowerShell. Мониторинг состояния DAG и баз почтовых ящиков, включенных в него является одной из важнейших задач администратора Exchange. Есть множество примеров ситуаций, когда администраторы после разворачивания DAG, решали, что теперь-то базы у них защищены. Но через какое-то время обнаруживали, что по факту пассивная копия неработоспобосна из-за проблем с репликацией и т.п. Этих проблем можно избежать за счет постоянного мониторинга (хотя бы раз в день) состояния кластера DAG.

Совет . Пример разворачивания DAG описан в статье

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

Разберем его вывод. В нашем случае у нас в DAG добавлена только одна база почтовых ящиков. Имеются две ее копии: копия на одном сервера активная (Mounted ), на втором – пассивная (Healthy ). Длина репликационной очереди (CopyQueue Length ) между активной и пассивной копией равно 0 (это хорошо), значит все изменения из активной базы реплицированы в пассивную копию. Очень важный параметр ContentIndexState , отображающий состояние индекса базы. У нас для обеих баз состояние индекса Healthy .

Чтобы проверить состояние конкретной базы в DAG, выполните:

Чтобы проверить состояние подсистем репликации конкретного сервера-члена DAG, выполните

Следующий командлет поможет получить длину очередей в DAG:

В этом примере очереди между серверами DAG отсутствуют.