Проблема: В консоли Microsoft Operations Manager долго не завершается процесс обнаружения новых устройств (discovery).
- Симптомы
- Причины
- Решение
- FAQ
- Безопасно ли удалять папку Health Service State? Не пропадут ли настройки агента?
- Как предотвратить зависание Discovery в будущем?
- Подходит ли это решение для SCOM 2019, 2022 и более новых версий?
- Что делать если очистка кэша не помогла и Discovery все равно зависает?
- Сколько в норме должен длиться процесс Discovery в SCOM?
Симптомы
Допустим вы хотите установить новых агентов мониторинга на серверы Windows из консоли SCOM. Вы запускаете стандартным образом мастер обнаружения (Computer and Device Management Wizard), выбираете серверы для установки и запускаете процесс обнаружения (discovery). Но процесс discovery длится бесконечно долго и никак не завершается.

В результате вы не можете установить агентов из консоли Operations Manager. Проблема встречается как в версии SCOM 2007, так и в SCOM 2012.
Решение протестировано и актуально для версий SCOM 2012 R2, 2016, 2019, 2022.
Причины
Одной из известных мне причин этого может служить антивирусное программное обеспечение, которое установлено на серверах управления Operations Manager.
Решение
1. Попробуйте для начала временно отключить, а лучше совсем удалить антивирусное ПО на том сервере управления SCOM, через который вы запускаете обнаружение. Если помогло, то переходите к следующему пункту. Если нет, то видимо проблему нужно искать в чем-то другом и скорей всего данное решение вам не поможет, но попробовать все равно стоит, так как это быстро и безопасно.
2. Настройте рекомендованные Microsoft исключения в антивирусном ПО для серверов управления Operations Manager.
3. Далее на сервере управления остановите службу HealthService.
Это можно сделать в консоли Computer Management (Управление компьютером):
Примечание. Отображаемое имя (display name) службы HealthService менялось в Operations Manager от версии к версии:
- В версии SCOM 2007 служба называлась «OpsMgr Health Service».
- С версии SCOM 2007 R2 она стала называться «System Center Management».
- В версии SCOM 2012 R2 ее переименовали в «Microsoft Monitoring Agent».
Имейте это ввиду при остановке HealthService с помощью консоли Управление компьютером.
Чтобы избежать путаницы, можно остановить службу командой, например так: net stop HealthService
4. Удалите папку Health Service State (по умолчанию путь такой — «C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Health Service State»), сделав предварительно ее копию. Или, например, просто ее переименуйте.
5. Запустите обратно службу HealthService.
Команда: net start HealthService
6. Проверьте, что служба удачно запустилась и что папка Health Service State создалась заново.
Совет. Самый простой, на мой взгляд, способ проконтролировать, что все в порядке, это просмотреть содержимое каталога «C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Health Service State\Management Packs». В нем должны начать появляться файлы xml c названиями установленных пакетов управления.
7. Проверьте, что все серверы имеют зеленый статус в консоли SCOM.
8. После этого заново попробуйте запустить процесс Discovery.
В заключение хочу сказать, что еще одна из возможных причин долгого обнаружения устройств рассматривается здесь.
Читайте также другие статье по системе мониторинга SCOM на нашем сайте.
FAQ
Безопасно ли удалять папку Health Service State? Не пропадут ли настройки агента?
Да, это безопасно. При удалении папки Health Service State (C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State) удаляется только локальный кэш данных мониторинга. Все настройки агента хранятся в реестре Windows и на сервере SCOM. После перезапуска службы Health Service агент автоматически загрузит актуальную конфигурацию с management server. Единственный минус — временная потеря исторических данных о производительности за последние часы.
Как предотвратить зависание Discovery в будущем?
Для профилактики проблемы рекомендуется:
Настроить исключения в антивирусе для папок SCOM (Health Service State, Program Files\Microsoft Monitoring Agent)
Регулярно очищать кэш агента (раз в 3-6 месяцев на загруженных системах)
Проверять DNS и reverse DNS зоны перед запуском Discovery
Исключать из сканирования недоступные подсети
Увеличить таймауты Discovery в настройках Management Server при работе с медленными сетями.
Подходит ли это решение для SCOM 2019, 2022 и более новых версий?
Да, метод универсален. Очистка кэша Health Service State работает одинаково во всех версиях System Center Operations Manager: 2012 R2, 2016, 2019, 2022 и новее. Расположение папок и название службы (HealthService или Microsoft Monitoring Agent) могут незначительно отличаться, но принцип работы идентичен. В SCOM 2019+ служба может называться «Microsoft Monitoring Agent» вместо «Health Service», но процедура остановки и очистки остается прежней.
Что делать если очистка кэша не помогла и Discovery все равно зависает?
Если стандартная очистка не решила проблему, проверьте:
Логи Operations Manager в Event Viewer (Application and Services Logs → Operations Manager) — ищите ошибки с Event ID 21000-21999
Доступность портов 5723 (агент) и 5985/5986 (WinRM) между Management Server и целевыми устройствами
Корректность учетных данных RunAs Account — у них должны быть права локального администратора на обнаруживаемых устройствах
MTU сети — при проблемах с фрагментацией пакетов уменьшите MTU до 1400
Попробуйте запускать Discovery по одному устройству вместо массового сканирования подсети
Если проблема сохраняется — включите трассировку (tracing) для компонента Discovery через PowerShell: Set-SCOMTrace -Component Discovery -Level Verbose
Сколько в норме должен длиться процесс Discovery в SCOM?
Обычно процесс обнаружения устройств занимает от 5 до 30 минут в зависимости от количества сканируемых IP-адресов и сложности сети. Если Discovery выполняется более 1-2 часов и прогресс не двигается — это признак проблемы. Чаще всего процесс «зависает» на этапе сканирования конкретного устройства из-за недоступности по ICMP/SNMP или проблем с DNS.














Добрый день! А что если все равно долгий discovery?
Здравствуйте! В конце статьи указана ссылка еще на одно решение, связанное с SQL Server Service Broker. Попробуйте его.