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

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

Механизм управляемой доступности встроенный в Exchange Server 2013 очень важен. О его критической важности я уже писал . Суть в том, что MA содержит не только код диагностики, но и код для восстановления работоспособности разных подсистем Exchange Server. Это само по себе способно порождать проблемы. Поэтому важно следить за исправностью подсистемы MA.

Managed Availability базируется на специальных почтовых ящиках мониторинга, через которые пропускается тестовый почтовый поток. Это ящики создаются автоматически. Если с ними возникают какие-то проблемы, то они создаются заново сервисом Microsoft Exchange Health Manager. Это может приводить со временем к накоплению «брошенных» объектов, которые больше не используются. К тому же Health Manager сервис выявляет не все проблемные ситуации возникающие с почтовыми ящиками мониторинга. В блоге разработчиков Exchange Server есть статья Exchange 2013 Monitoring Mailboxes , которая не только раскрывает разные тонкости почтовых ящиков мониторинга, но и описывает процедуру их полного восстановления, которая может выполняться только в исключительных случаях. Эта процедура реализована мной в виде скрипта на Powershell и опубликована в Галерее скриптов Reset Exchange 2013 Monitoring Mailboxes .

<# .Synopsis Reset Exchange 2013 Monitoring Mailboxes. .DESCRIPTION Reset Exchange 2013 Monitoring Mailboxes. The script stop Microsoft Exchange Health Manager service on all Exchange servers, disable Monitoring Mailboxes, remove accounts and start Microsoft Exchange Health Manager services. The script inspeared by Bhalchandra Atre"s article http://blogs.technet.com/b/exchange/archive/2015/03/20/exchange-2013-monitoring-mailboxes.aspx .EXAMPLE .\Reset-ExchangeMonitoringMailboxes #> function Reset-ExchangeMonitoringMailboxes { Begin { # Check RunAs Administrator if (-not (::GetCurrent()).IsInRole( "Administrator")) { throw("Please re-run this script with elevated rights - RunAs Administrator!") } $monmailboxes = Get-Mailbox -Monitoring # OU = LDAP://CN=Monitoring Mailboxes,CN=Microsoft Exchange System Objects,... $monroot = ("LDAP://" + ($monmailboxes.DistinguishedName -split ",",2)) if (-not ::Exists($monroot.Path)) { throw("Monitoring Mailboxes container doesn"t exist!") } # Find all Exchange Servers and show versions $exservers = Get-ExchangeServer Write-Host -Fore:Yellow "Destination servers:" $exservers | Select Name,AdminDisplayVersion,ExchangeVersion | Out-Host # Find all Health Manager services Write-Host -Fore:Yellow "Find all Microsoft Exchange Health Manager services" $HMservices = $exservers | % { Get-Service "Microsoft Exchange Health Manager" -ComputerName $_.Name -ErrorAction SilentlyContinue } # and stop them Write-Host -Fore:Yellow "Stop Microsoft Exchange Health Manager services" $HMservices | % { Write-Host -Fore:Yellow "Stopping" $_ | Select Status,MachineName,Name,DisplayName | ft -AutoSize $_.Stop() } # Disable all monitoring mailboxes Write-Host -Fore:Yellow "Disable all monitoring mailboxes" $monmailboxes | Disable-Mailbox -Confirm:$false # Delete all monitoring mailboxes Write-Host -Fore:Yellow "Delete all monitoring mailboxes" $monroot.Children | % { $_.DeleteTree() #$monroot.Children.Remove($_) } $monroot.CommitChanges() # Waiting inter-site replication Write-Host -Fore:Yellow "Waiting inter-site replication" Start-Sleep -Seconds 15 } End { # Start Microsoft Exchange Health Manager services Write-Host -Fore:Yellow "Start Microsoft Exchange Health Manager services" $HMservices | % { Write-Host -Fore:Yellow "Starting" $_ | Select Status,MachineName,Name,DisplayName | ft -AutoSize $_.Start() } Write-Host -Fore:Yellow "Waiting service start: 1 minute" Start-Sleep -Seconds 60 # Check Health Manager service status Write-Host -Fore:Yellow "Check Health Manager service status" $exservers | % { Get-Service "Microsoft Exchange Health Manager" -ComputerName $_.Name -ErrorAction SilentlyContinue } } }

Мониторинг является ключевым компонентом для любого успешного развертывания Exchange. В предыдущих выпусках мы приложили много усилий для разработки обработчика корреляций и тесно сотрудничали с группой разработчиков System Center Operations Manager (SCOM), чтобы представить комплексное решение предупреждения для сред Exchange.

Раньше понятие мониторинга обычно включало в себя сбор данных и, если это требовалось, выполнение действий на основании этих данных. Например, в контексте SCOM использовались разные механизмы для сбора данных посредством Exchange Management Pack:

Задачи мониторинга Exchange Server 2013

Когда мы приступили к разработке Exchange 2013, ключевым аспектом было улучшение сквозного мониторинга для всех развертываний Exchange — от самого маленького локального развертывания до самого крупного развертывания в мире, Office 365. Мы ставили перед собой три задачи:

Предоставление наших знаний и опыта, связанных со службой Office 365, локальным клиентам Почти 6 лет назад группа разработчиков Exchange запустила Exchange Online. Используемая нами операционная модель называется операционной моделью разработчиков (DevOps). В ней сведения о неполадках эскалируются непосредственно разработчику компонента, если этот компонент работает в службе неправильно или клиент сталкивается с неизвестной проблемой. Независимо от источника проблемы эскалация напрямую разработчику привносит элемент ответственности в процесс разработки программного обеспечения благодаря устранению неполадок ПО.
Мониторинг на базе взаимодействия с пользователем Мы также узнали, что многие из тех методологий, которые мы использовали для мониторинга, на самом деле не помогают нам обеспечивать правильную работу среды. В результате мы пришли к концепции мониторинга, ориентированной на клиентов.
Для прошлых выпусков каждой группе разработчиков компонентов требовалось создать модель работоспособности, соединяя все компоненты в своей системе. Например, транспорт состоит из SMTP-IN, SMTP-OUT, агентов транспорта, классификатора, модуля маршрутизации, драйвера хранилища и т. п. После этого группа разработчиков компонентов создавала предупреждения по каждому из таких компонентов. В результате в Management Pack имеются предупреждения, которые позволяют вам узнать о сбое драйвера хранилища. Однако это предупреждение не сообщает о сквозном взаимодействии с пользователем или о том, что может быть нарушено в таком взаимодействии. Поэтому в Exchange 2013 мы пытаемся перевернуть указанную модель "вверх дном". Мы не собираемся отказываться от мониторинга на уровне систем, так как он имеет важное значение. Но действительно важным при управлении службой является то, что именно видят ваши пользователи. Поэтому мы видоизменили модели и с нетерпением ждем возможности оценить и проанализировать взаимодействие с пользователем.
Защита взаимодействия с пользователем посредством ориентации на восстановление В предыдущих выпусках Exchange мониторинг был ориентирован на систему и компоненты, в новой версии — на автоматическое восстановление взаимодействия с пользователем.

Мониторинг Exchange Server 2013 — управляемая доступность

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

Управляемая доступность ориентирована на пользователя. Мы хотим измерить три ключевых аспекта — доступность, взаимодействие с пользователем (которое для большинства протоколов измеряется по задержке) и наличие возникающих проблем. Чтобы лучше разобраться в этих трех аспектах, давайте рассмотрим в качестве примера пользователя, работающего с Outlook Web App (OWA).

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

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

Компоненты управляемой доступности

Управляемая доступность встроена в обе роли сервера в Exchange 2013. Она включает в себя три главных асинхронных компонента. Первый компонент — это подсистема зондов . Задача подсистемы зондов заключается в проведении измерений на сервере. Это подводит нас ко второму компоненту — монитору . Монитор содержит бизнес-логику, кодирующую все то, что мы считаем работоспособным состоянием. Вы можете рассматривать его как подсистему распознавания шаблонов — он отыскивает различные шаблоны в разных проводимых измерениях и затем может принять решение о том, можно ли считать что-то работоспособным. Наконец, есть подсистема ответчиков , которую на приведенной ниже схеме я отметил как "Восстановление". Когда что-то не является работоспособным, она прежде всего пытается восстановить этот компонент. Управляемая доступность предоставляет многоэтапные действия восстановления — первой может предприниматься попытка перезапуска пула приложений, второй — попытка перезапуска службы, третьей — попытка перезапуска сервера, а последней — попытка отключения сервера от сети, чтобы он больше не принимал трафик. Если эти попытки неудачны, управляемая доступность эскалирует данную проблему человеку через уведомление журнала событий.

Вы также могли заметить, что мы произвели децентрализацию некоторых аспектов работы. Раньше агент SCOM размещался на каждом сервере, и требовалось выполнять потоковую передачу всех измерений на центральный SCOM. Этот сервер SCOM оценивал все измерения, чтобы определить, является ли что-то работоспособным. В крупномасштабных средах сложная корреляция требует значительных ресурсов. Мы заметили, что на выдачу предупреждений требуется больше времени и т. п. Сбор всех данных в одном центральном расположении не подходит для масштабирования. Поэтому мы решили, что каждый отдельный сервер будет выступать в роли острова — каждый сервер выполняет свои собственные зонды, осуществляет мониторинг самого себя, предпринимает меры по самовосстановлению и, конечно же, при необходимости отправляет эскалации.

Рис. 1. Компоненты управляемой доступности

Зонды

Инфраструктура зондов состоит из трех отдельных платформ:

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

Мониторы

Собранные зондами данные попадают в мониторы. Между зондами и мониторами совсем необязательно имеется прямое соответствие; несколько зондов могут предоставлять данные в один монитор. Мониторы рассматривают результаты работы зондов и выносят заключение. Такое заключение является двоичным — монитор либо работоспособен, либо нет.

Как уже было упомянуто ранее, мониторинг Exchange 2013 ориентирован на взаимодействие с конечным пользователем. Для этого нам требуется осуществлять мониторинг на разных уровнях среды:

Рис. 2. Мониторинг на разных уровнях для проверки взаимодействия с пользователем

Как видно из приведенной выше схемы, мы используем четыре разных проверки. Первая проверка — это самопроверка почтового ящика; этот зонд проверяет, может ли локальный протокол или интерфейс обратиться к базе данных. Вторая проверка называется самопроверкой протокола и проверяет, работает ли локальный протокол на сервере почтовых ящиков. Третья проверка — это самопроверка прокси-сервера, которая выполняется на сервере клиентского доступа и проверяет, работает ли для протокола функция прокси-сервера. Четвертая и последняя проверка — это комплексная проверка сквозного взаимодействия с пользователем (доступ протокола через прокси-сервер к функциям хранения). Каждая проверка осуществляет обнаружение с разными интервалами.

Мы осуществляем мониторинг на разных уровнях, чтобы выявить зависимости. Поскольку в Exchange 2013 нет обработчика корреляций, мы стараемся разграничить зависимости с помощью уникальных кодов ошибки, соответствующих разным зондам, и зондов, которые не связаны с зависимостями. Например, если вы видите, что произошел одновременный сбой зондов самопроверки почтового ящика и самопроверки протокола, какой вывод вы сделаете? Что перестало работать хранилище? Необязательно; этот вывод заключается в том, что не работает экземпляр локального протокола на сервере почтовых ящиков. Если вы видите, что зонд самопроверки протокола работает, а зонд самопроверки почтового ящика нет, какой вывод вы сделаете? Эта ситуация указывает на наличие проблемы на уровне "хранилища", которая может заключаться в отключении хранилища или базы данных.

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

Ответчики

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

Доступно несколько типов ответчиков:

Ответчик перезапуска — завершает работу службы и перезапускает ее.
Ответчик сброса пула приложений — выполняет отключение и повторное включение пула приложений IIS.
Ответчик отработки отказа — выводит сервер почтовых ящиков Exchange 2013 из эксплуатации.
Ответчик проверки на ошибки — запускает проверку сервера на наличие ошибок.
Автономный ответчик — выводит протокол на компьютере из эксплуатации.
Ответчик эскалации — осуществляет эскалацию проблемы.
Специализированные ответчики компонентов

Автономный ответчик используется для прекращения использования протокола на серверах клиентского доступа. Этот ответчик разрабатывался как инвариантный к подсистеме балансировки нагрузки. При вызове этого ответчика протокол не подтверждает проверку работоспособности подсистемы балансировки нагрузки, таким образом позволяя этой подсистеме балансировки нагрузки удалить сервер или протокол из пула балансировки нагрузки. Также существует ответчик подключения к сети, который автоматически инициализируется, когда соответствующий монитор снова становится работоспособным (предполагается, что другие сопоставленные мониторы в неработоспособном состоянии отсутствуют); ответчик подключения к сети просто разрешает протоколу отвечать на проверку работоспособности подсистемы балансировки нагрузки, что позволяет этой подсистеме добавить сервер или протокол обратно в пул балансировки нагрузки. Автономный ответчик можно также вызвать вручную с помощью командлета Set-ServerComponentState. Это позволяет администраторам вручную перевести серверы клиентского доступа в режим обслуживания.

При вызове ответчик эскалации создает событие Windows, распознаваемое Exchange 2013 Management Pack. Это не обычное событие Exchange. Это не событие, которое сообщает, что OWA не работает или возникла ошибка ввода-вывода. Это событие Exchange, которое указывает, является ли набор работоспособности работоспособным или нет. Мы используем такие события отдельного экземпляра для управления мониторами внутри SCOM. И при этом мы берем за основу событие, создаваемое в ответчике эскалации, которое противопоставляется событиям, используемым в продукте. Другим походом к данной концепции является степень косвенности. Управляемая доступность решает, когда нам следует обратить монитор внутри SCOM. Управляемая доступность принимает решение о том, когда должна осуществляться эскалация, или, другими словами, когда в процесс следует вовлечь человека.

Ответчики также можно регулировать, чтобы не подвергнуть риску всю службу. Такое регулирование зависит от ответчика:

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

При осуществлении регулирования действие ответчика может быть отложено или просто пропущено (это зависит от ответчика).

Последовательности восстановления

Важно понимать, что мониторы определяют типы выполняемых ответчиков и график их выполнения, мы называем это последовательностью восстановления для монитора. Например, предположим, что данные зонда протокола OWA (самопроверка протокола) активирует для монитора неработоспособное состояние. При этом сохраняется текущее время (назовем его T). Монитор запускает конвейер восстановления, который основан на текущем времени. Монитор может определять действия по восстановлению с заданными интервалами в конвейере восстановления. В случае с монитором протокола OWA на сервере почтовых ящиков последовательность восстановления имеет следующий вид:

При T=0 выполняется ответчик сброса пула приложений IIS.
Если при T=5 минут монитор не возвратился в работоспособное состояние, запускается ответчик отработки отказа и базы данных перемещаются с сервера.
Если при T=8 минут монитор не возвратился в работоспособное состояние, запускается ответчик проверки на ошибки и выполняется принудительная перезагрузка сервера.
Если при T=15 минут монитор все еще не возвратился в работоспособное состояние, активируется ответчик эскалации.

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

Last Updated: January 1st, 2019 - netadmintools

Microsoft Exchange is one of the most popular and widely used email servers in the world. It is also a critical infrastructure for any organization because email is the primary form of communication at work.

Whether your employees want to setup a meeting or get notifications about vulnerability issues in the network, emails are the key. This is why every organization should take proactive steps to ensure that their Exchange server is in good health always.

2. PRTG Network Monitor by Paessler

PRTG Exchange Monitoring tool monitors many parameters of your Exchange Server, so there are no financial and productivity losses stemming from server problems.

Here’s a look at some of its features.

Continuously monitors exchange server availability and performance.
Ensures the smooth delivery of emails
Sends alerts when the mail server is down or when there are any issues with availability or performance. It sends these alerts through email, SMS or push notifications.
Monitors database capacity, load and traffic patterns.
Handles documentations such as event log entries.
Easy to setup and configure.
Comes with pre-configured sensors for Microsoft Exchange Server, so they are automatically in place when installation is complete.
A well-designed dashboard displays all the information about Exchange Server in a neat and comprehensive way.

Below is a list of sensors designed specifically for monitoring the Exchange server.

Exchange mailbox (powershell) sensor – Monitors the mailbox size, logins and the latest emails.
Exchange database (powershell) sensor – Monitors database availability group (DAG) status.
Exchange backup (powershell) sensor – Verifies if Exchange backups are performed at scheduled intervals.
Exchange mail queue (powershell) sensor – Monitors the number of emails that are currently in the mail queue.
Exchange public folder (powershell) sensor – Monitors Exchange Server’s public folders, including its size, access, etc.
WMI Exchange server sensor and WMI Exchange transport queue sensor – Queries important information through WMI
SMTP and IMAP round trip sensor – Checks the response time of SMTP and IMAP servers.
SMTP and POP3 round trip sensor – Monitors end-to-end delivery of emails.
POP#, IMAP and SMTP sensors – Monitors the availability of email servers

Pricing:
The cost depends on the number of sensors you choose.

100 sensors – free
500 sensors – $1600
1000 sensors – $2850
2500 sensors – $5950
5000 sensors – $10500
XL1 Unlimited: Unlimited sensors for one core installation – $14500
XL1 Unlimited: Unlimited sensors for five core installations – $60000

The above prices include a one-year maintenance. To renew, the price is 25% of the original license.
Download:

3. ManageEngine OpManager

OpManager from ManageEngine helps you to stay on top of your Exchange server’s performance.

It allows you to do the following:

Check for inactive mailboxes and remove them for better performance.
Keep a check on your mailbox performance counters to ensure that your database storage capacity is within acceptable limits.
Troubleshoot outlook connectivity by examining various parameters such as number of requests per second, average response time, etc.
Streamline all voice messages and emails into a single mailbox, so it is easy to identify access issues.
Monitor critical information like scan time, the number of scan requests rejected, blocked recipients and more, to provide better security against spam and viruses.
Plan for capacity based on the inputs from this tool.
Create stellar reports using the built-in templates.
Get a list of all the servers and database status copies that are a part of the database availability group (DAG).

Pricing:
Free Trial as well, but this product starts at $945.
Download:

4. Foglight for Exchange

5. Nagios Exchange Server Monitoring Tool

6. Netwrix Auditor for Exchange

Conclusion

To conclude, Exchange monitoring Software and Tools are essential to protect your Exchange servers from going down, along with Managing and Monitoring Datastores and important Exchange Services that should never go down. The above explained tools come with good features to give you complete control over the health, performance and availability of this critical resource.

We suggest you download a few of them and test them in your network to get a better feel of what they are compatible of – If you want our Top picks, We suggest one of the top 3 list above – either Solarwinds , or by ManageEngine!

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. Эта база

Published on Январь 27, 2009 by · Один комментарий

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

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

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

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

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

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

Вернитесь обратно в папку, куда устанавливали 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 (обоим требуется сертификат):

Для одобрения ждущего запроса сертификата войдите на компьютер, содержащий службу сертификации (Certificate Services) в качестве администратора и откройте консоль администрирования центров сертификации (Certification Authority). Разверните вкладку имени вашего ЦС, а затем нажмите на Ждущие запросы (Pending Requests) . В появившейся панели правой клавишей нажмите на ждущем запросе с предыдущей процедуры, наведите курсор на Все задачи и выберите Издать (Issue) .
Для получения сертификата войдите на компьютер, на который устанавливаете сертификат (и с которого вы выполняли запрос). Запустите обозреватель 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) после того, как увидите сообщение Ваш новый сертификат был успешно установлен , закройте обозреватель.
Поскольку оба сервера должны доверять ЦС, выпустившему сертификаты, нам необходимо импортировать сертификат ЦС на обе машины (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), а затем снова нажмите Сохранить . Закройте обозреватель.
Выполните MMC и добавьте оснастку Сертификаты (в диалоговом окне оснастки сертификатов выберите для учетной записи компьютера , а затем нажмите Далее . Убедитесь, что выбран Локальный компьютер и нажмите Завершить ). Разверните Сертификаты (локальный компьютер) , разверните Доверенные корневые центры сертификации (Trusted Root Certification Authorities) , правой клавишей нажмите Сертификаты , выберите Все задачи и нажмите Импортировать . Найдите место, в которое вы сохранили файл.P7B и импортируйте сертификат.
Для импортирования сертификата используйте 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

Просмотров