Информация по удалению, разумеется, есть и на сайте Microsoft

Согласно ей, помимо всего прочего, перед удалением Exchange требуется удалить все его базы (в самом простом случае это база почтовых ящиков и база public folders). Сначала необходимо удалять именно вторую базу, ибо если удалить базу почтовых ящиков, то подключиться к базе общих папок не выйдет.

На этапе удаления базы общих папок и возникает первый момент, о котором я хотел бы рассказать. Сама процедура удаления описана в http://technet.microsoft.com/en-us/library/cc164367.aspx и http://technet.microsoft.com/en-us/library/bb201664.aspx. Все бы ничего, но удаление не проходит, выдается сообщение про то, что в базе есть реплики для папок и сначала необходимо удалить их.

В интернете полно советов использовать в данном случае утилиту ADSIEdit, но лично у меня данный вариант не вызывает симпатии, по моему мнению удаление должно по возможности проходить штатными средствами. В данном случае речь идет, разумеется, о PowerShell.

В итоге после долгих поисков удалось найти нормальное, на мой взгляд, решение проблемы.

Вот команды, которые позволяют удалить public folders database:

Get-PublicFolder -Server <server_name> “\” -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <server_name> -Recurse -ErrorAction:SilentlyContinue

Get-PublicFolder -Server <server_name> “\Non_Ipm_Subtree” -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Server <server_name> -Recurse -ErrorAction:SilentlyContinue

Get-PublicFolderDatabase -Server <server_name> | Remove-PublicFolderDatabase -RemoveLastAllowed

После этого выполняем все остальные шаги, указанные в инструкции по удалению и запускаем процесс удаления Exchange с сервера через «установку и удаление программ».

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

Тут тоже есть одна тонкость. На самом последнем шаге удаления (удаление файлов exchange) процесс застывает в ожидании. Не стоит давать дополнительное время в надежде, что все сейчас заработает, толку не будет. Данная проблема тоже известна и описана в KnowledgeBase. Решение простое – удаляем через task manager процесс powershell.exe и удаление Exchange успешно завершается

Возможно, кому-нибудь будет полезна данная информация

Александр Бурцев aka Alexx_B

Почему вообще возникла идея создания подобного пакета? Когда приходится обслуживать несколько серверных, разнесенных географически, вопрос мониторинга питания встает с особой остротой. Никак не получится выбрать какой-нибудь один ИБП, мониторить его бесплатной утилитой APC, идущей в комплекте с ИБП и считать, что все остальные ИБП в серверной ведут себя примерно так же.

Итак, посмотрим на существующие решения, позволяющие мониторить ИБП. Так как в нашей организации внедрен SCOM, то различные пакеты под другие системы мониторинга нас не интересовали. Кроме того, далеко не все наши ИБП имеют установленную карту мониторинга окружающей среды, некоторые просто подключены к серверам через USB- или COM-порты. Разумеется, хотелось иметь универсальный инструмент для мониторинга, не зависящий от типа подключения ИБП. В итоге список рассмотренных нами вариантов такой:

• Можно настроить на каждом ИБП отсылку почтовых сообщений выбранным пользователям. Самый простой вариант, но он имеет кучу недостатков:

1) каждый ИБП должен иметь доступ к почтовому серверу

2) ИБП склонен генерировать сообщение за сообщением, если проблема не решается. Например, если температура датчика будет превышать разрешенную в течение получаса, в почтовый ящик свалится с десяток сообщений. Но в то же время уведомить оператора о решившейся проблеме ИБП не умеет, такой функциональности в ПО нет. Это принципиальный момент. Например, за ночь может произойти множество событий и с утра оператору важно будет в первую очередь уделить внимание тем, которые все еще остаются актуальными

3) необходимо настраивать уведомления (типы событий, получателей, почтовый сервер) на каждом ИБП в отдельности. Сами уведомления настраивать нельзя, это тоже является минусом. Например, при превышении установленной температуры ИБП просто пришлет сообщение, что температура превысила установленную отметку. О том, насколько превышена температура, оператор из сообщения не узнает.

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

5) данная система подходит только для ИБП, напрямую подключенных к сети

• Вполне логично обратиться к решению от APC. Речь идет о Powerchute Business Edition. Версия Basic достаточно интересна в данном случае, она позволяет наблюдать (и управлять) за 5 ИБП одновременно, но все проблемы, описанные выше (генерация кучи предупреждений, невозможность получения сообщения об устранении проблемы, отсутствие настроек уведомлений) остаются и здесь. Преимуществом по сравнению с предыдущим вариантом является лишь возможность мониторить ИБП, подключенные через USB- или COM-порты
• Продукт Power Management Packs for Operations Manager от Quest Software. Данный софт работает независимо от SCOM, по сути, на сервер ставится отдельная программа, а к SCOM делается коннектор. Из-за этого все настройки и конфигурирование происходят не в среде SCOM‘а, а в интерфейсе утилиты. Помимо очевидных вещей (например, оператору придется фактически изучать новый продукт в дополнение к уже используемому), это неудобно еще и тем, что мы лишаемся возможности управления через Powershell. Кроме того, начальная инсталляция системы довольно сложная
• Различные бесплатные пакеты для мониторинга ИБП APC от самостоятельных разработчиков. Все эти пакеты объединяет то, что они нацелены на работу с SNMP-трапами, отсылаемыми ИБП. Это плохо тем, что инициатором уведомления выступает сам ИБП, причем он никак не контролирует, доставлено ли уведомление

Таким образом, было решено создавать собственный пакет для мониторинга ИБП (в данный момент поддерживаются ИБП фирмы APC, в скором времени – и другие ИБП, соответствующие стандарту RFC1628). Задачи при создании пакета ставились следующие:

• мониторинг ИБП APC с помощью SCOM в native-режиме, без использования коннекторов к сторонним продуктам
• удобство использования для оператора: стандартный интерфейс, привычные для операторов функции типа моделей состояния (об этом ниже)
• широкие возможности по кастомизации – изменение порогов срабатывания алертов, частоты опроса параметров и т.д. В распределенной структуре любой организации это важно, т.к. параметры питания в разных серверных могут отличаться и можно гибко подстроить пакет под нормальное поведение конкретного ИБП в конкретной серверной
• поддержка мониторинга ИБП с разными типами подключения – Ethernet, COM, USB

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

Общий список устройств

На этом списке легко увидеть состояние всех мониторящихся ИБП сразу. Благодаря способу представления – таблице – на одном экране отображается большое число устройств. Например, при разрешении 1024х768 одновременно можно наблюдать порядка 30-40 ИБП:

Диаграммы

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

Если мы захотим получить чуть больше информации по ИБП, просто откроем его свойства:

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

Возвращаясь к диаграмме устройств – явно, что у некоторых ИБП есть проблемы. Чтобы понять точнее, раскрываем заинтересовавшее нас устройство:

Это Smart-UPS 5000 с установленной картой управления / мониторинга (Environmental monitoring card).  Видно, что с системой мониторинга окружающей среды все хорошо, а вот по батарее есть какие-то предупреждения.

Диаграммы вполне можно считать основным рабочим интерфейсом оператора. Они позволяют через контекстные меню быстро открыть любые другие виды SCOM (например, графики производительности или список алертов), при этом оператор получит только те данные, которые соответствуют выбранному элементу. Например, если выбрать вид «графики производительности» для ИБП – то откроются все доступные для данного ИБП графики. Если же сделать аналогичное действие на батарее данного ИБП – то число графиков заметно уменьшится, останутся только те, которые соответствуют батарее данного ИБП.

Модель состояния

Выяснив по диаграмме, что проблема кроется в батарее ИБП, мы захотим выяснить, в чем же именно она заключается. Для этой цели нам больше всего подходит Health Explorer или Модель состояния. Вот что мы увидим для данной батареи:

Сразу видно, в чем проблема – ожидаемое время, в течение которого ИБП сможет поддерживать текущую нагрузку, опустилось ниже порога срабатывания алерта. Можно увидеть значение, при котором сработало уведомление и время, когда это произошло. В списке видны все события по данному инциденту в прошлом, что может помочь выявить проблему и то, как часто она бывает.

Алерты

Модель состояния хороша, если требуется просмотреть список текущих событий. Однако для анализа закрывшихся событий удобнее использовать Alert View. Тут сразу можно окинуть взором все, что происходило за выбранный интервал времени как с конкретным ИБП (или даже его батареей), так и со всеми ИБП сразу. Например, мы можем видеть, что за выбранный нами интервал времени было 2 события от одного из ИБП, одно из них уже не актуально, а второе все еще активно:

Графики

Еще одним средством анализа проблем можно считать графики. Естественно, графики могут быть только для тех параметров, которые можно как-то измерить. Вот, например, график изменения входного напряжения на ИБП, собранный за несколько часов:

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

А вот более интересный график связи ожидаемого времени работы ИБП (фиолетовый график) и текущей нагрузки (желто-зеленый график):

События

Для событий, которые важны лишь в случае многократного повторения (например, попытка подбора пароля), удобнее использовать Event View:

Уведомлять оператора логично лишь когда число повторов события превысит критическую величину за определенный интервал времени

Оповещения

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

Графики и алерты/уведомления

В настоящий момент пакет поддерживает ведение следующих графиков (естественно, все зависит еще и от самого устройства):

• Input Voltage, V
• Input Frequency, Hz
• Output Voltage, V
• Output Frequency, Hz
• Output Current, A
• Output Load, %
• Battery Capacity, %
• Battery Current, A
• Battery Voltage, V
• Battery Time Remaining, m
• Battery Temperature, C
• Probe Temperature, C
• Probe Humidity, %

Поддерживаются следующие уведомления и алерты:

Availability

UPS Basic Status

Если ИБП изменил свой статус (например, на Hardware Failure Bypass и т.д.,
всего различаются все 12 статусов)

UPS DC Fan

В случае отказа вентилятора

UPS has switched to
battery backup power

В случае переключения ИБП на встроенную батарею

UPS Link check

В случае отсутствия n ответов от ИБП за m промежуток времени

Battery replace indicator

В случае, если ИБП требует замену батареи

Test Calibration Results

В случае, если результаты последней калибровки неизвестны или она прошла с ошибкой

Test Diagnostic Results

В случае, если результаты последней диагностики неизвестны или она прошла с ошибкой

Performance

Input Line Voltage

В случае, если входное напряжение выше или ниже установленных порогов

Input Line Frequency

В случае, если частота напряжения на входе выше или ниже установленных порогов

Output Load

В случае превышения допустимого порога нагрузки на ИБП

Output Voltage

В случае, если выходное напряжение выше или ниже установленных порогов

Battery Capacity

В случае, если емкость батареи ниже установленного порога

Battery Runtime Remaining

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

Battery Temperature

В случае превышения заданного порога встроенным датчиком температуры

Output contact

В случае замыкания контакта

Input relays

В случае срабатывания реле

Probe temperature

В случае превышения заданного порога внешним датчиком температуры

Security

UPS Password

В случае смены пароля на ИБП

UPS HTTP Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через HTTP

UPS Console Access

В случае ввода n числа неверных паролей за m интервал времени при доступе к ИБП через консоль

В настоящее время менеджмент-пак активно развивается, в частности в ближайшее время планируется расширение числа поддерживаемых устройств за счет ИБП сторонних фирм (не APC), соответствующих RFC1628. Но уже сейчас можно отметить отдельные моменты пакета:

• Установка пакета практически не отличается от установки большинства других пакетов для SCOM, практически никаких предварительных действий не требуется. Не требуется и установка какого-либо стороннего ПО. После установки пакет сам находит ИБП APC среди присутствующих сетевых устройств в SCOM, сам разбирается, установлена ли в ИБП плата мониторинга окружающей среды и т.д.
• Поддерживается мониторинг как ИБП, подключенных напрямую в сеть, так и работающих через USB- и COM-порты
• Все алерты сделаны максимально кастомизируемыми, можно гибко подстроить пакет под конкретный ИБП

Александр Бурцев aka Alexx_B

]]> http://alexxb.wordpress.com/2009/05/04/apc-scom/feed/ 2 Alexx_B All devices list Diagram View - all devices APC UPS Properties Diagram View - UPS Health Explorer Alerts Input Voltage Graph Temperature Graph Time Remaining and Output Load Graphs Event View Security Alert Runtime Remaining Alert