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

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.

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

Figure 1: Solution topology used in this article

Server Name		Software
SC2K12-SCOM	Root Management Server	Windows Server 2012 SQL Server 2012 SP1 System Center 2012 Operations Manager SP1 + UR4
E2K13-MBX1	Domain Controller	Windows Server 2012 Exchange Server 2013 + CU2
E2K13-MBX2		Windows Server 2012 Exchange Server 2013 + CU2

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 отсутствуют.

Каждому администратору, обслуживающему систему 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 и заблаговременно устранять небольшие проблемы.

System Attendant на каждом сервере. Отслеживание отдельных сообщений выполняется с помощью компонента Message Tracking Center (МТС), который входит в оснастку Exchange System .

Включение отслеживания сообщений для сервера

Перед тем как использовать на сервере отслеживание сообщений, эту функцию необходимо активизировать. Щелкните правой кнопкой мыши на сервере в System Manager и выберите Properties (Свойства). На вкладке General (Общие) окна свойств выберите опцию Enable message tracking (Включить отслеживание сообщений). Exchange проинформирует о том, что для отслеживания сообщений необходимо сначала предоставить доступ на чтение из общего расположения по адресу \\имя_сервера\\имя_сервера.log всем пользователям, которым требуется осуществлять отслеживание сообщений. Кроме того, с помощью опций на вкладке General (Общие) можно настроить автоматическое удаление файлов журнала по прошествии определенного числа дней (это позволит сохранить небольшой размер файлов журнала) и изменить расположение самого файла журнала.

Как только для сервера будет включено отслеживание сообщений, все сообщения, передаваемые этим сервером, будут фиксироваться в журнале отслеживания сообщений. Для поиска данных в журнале используется Message Tracking Center (Центр отслеживания сообщений).

Использование Message Tracking Center (Центр отслеживания сообщений)

Чтобы запустить МТС, нужно сначала перейти к контейнеру Message Tracking Center в оснастке Exchange System и выделить этот контейнер, как показано на рис. 6.15 . Поиск сообщений можно осуществлять по идентификационному номеру сообщения, отправителю, серверу, получателям и датам сообщения (или по комбинации любых из перечисленных данных). Следует заметить, что необходимо указывать сервер, на котором должен осуществляться поиск.

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

Введите информацию или щелкните на любой кнопке слева от полей, чтобы перейти к объектам - пользователям или серверам. После указания критерия поиска нажмите кнопку Find Now (Найти), чтобы выполнить поиск. На рис. 6.16 показаны все сообщения, отправленные пользователю Jim Hance.

Рис. 6.15.

Рис. 6.16.

Как только отобразятся сообщения, отвечающие указанному критерию, можно открыть историю любого сообщения, просто щелкнув на нем. Образец диалогового окна Message History (История сообщения) показан на рис. 6.17 . Как видите, это диалоговое окно отображает базовую информацию и историю сообщения.

Рис. 6.17.

Использование System Monitor

System Monitor - это средство, включенное в Windows ; оно находится в папке Administrative Tools ( Администрирование ). System Monitor приводит в графическом виде диаграммы производительности для сотен отдельных параметров системы на компьютере, работающем под управлением Microsoft Windows Server 2003. После инсталляции Exchange Server 2003 на сервере Windows можно вывести несколько счетчиков, связанных с Exchange . Подробное описание System Monitor приводится в гл. 29.

Использование SNMP и MADMAN MIB

Протокол Simple Network Management Protocol ( SNMP ) - это стандартный незащищенный протокол передачи данных , используемый для сбора информации от устройств в сети TCP/IP . SNMP был разработан интернет-сообществом для мониторинга работы сетевых устройств, таких как маршрутизаторы и шлюзы. С тех пор использование и поддержка SNMP значительно выросли. С помощью SNMP теперь можно выполнять мониторинг многих устройств, включая компьютеры, работающие под управлением Windows .

Как действует протокол SNMP

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

• SNMP Agent (Агент SNMP) - это устройство в сети, по которому выполняется мониторинг. Таким устройством обычно является компьютер, на котором установлено программное обеспечение SNMP Agent. Windows Server 2003 содержит программное обеспечение SNMP Agent в форме службы Microsoft SNMP Service. (Чтобы инсталлировать службу SNMP Service, нужно использовать Add/Remove Windows Components [Добавить или удалить компоненты Windows] в панели управления Add/Remove Programs [Установка и удаление программ].);
• SNMP Management System (Система управления SNMP) - это компонент, выполняющий фактический мониторинг в среде SNMP. В Windows нет компонента SNMP Management System. Существуют системы SNMP Management System от сторонних фирм, такие как OpenView фирмы Hewlett-Packard и Net View фирмы IBM;
• Management Information Base (База управляющей информации) -централизованная база данных для всех значений, по которым можно проводить мониторинг устройств в системе SNMP. Для мониторинга различных типов устройств и систем поставляются различные MIB . Windows Server 2003 поставляется с четырьмя MIB : Internet MIB II, LAN Manager MIB II, DHCP MIB и WINS MIB . Эти четыре MIB позволяют осуществлять удаленный мониторинг и управление большинством компонентов Windows.

Exchange Server 2003 и MADMAN MIB

Exchange Server 2003 содержит специальную базу MIB , используемую для активизации системы SNMP Management System, которая управляет многими функциями Exchange Server 2003. Эта база