С некоторых пор сервер под управлением операционной системы Windows Server 2012 R2 Standard, на котором установлен Azure AD Connect, начал здорово притормаживать. Диспетчер процессов указал на виновника: Microsoft.Online.Reporting.MonitoringAgent.Startup – процесс загружал систему на 100%:
Процесс Microsoft.Online.Reporting.MonitoringAgent.Startup входит в сервис Azure AD Connect Health Sync Monitoring, который вроде как собирает данные по локальной инфраструктуре сервера. Сервис наверняка важный, но на работу Azure AD Connect не влияет. Исходя из этого для решения загруженности процессора на сервере есть 2 варианта устранения проблемы.
Вариант первый. Убирает симптом, но не решает проблему. Нужно остановить сервис Azure AD Connect Health Sync Monitoring Service. Для этого идем запускаем контроль управления сервером и открываем окно со список сервисов системы. Ищем Azure AD Connect Health Sync Monitoring Service и останавливаем его:
Если такой вариант решения проблемы устраивает и далее не планируется ничего делать, то рекомендую установить режим запуска в состояние «Manual», иначе после перезагрузки сервера служба снова запустится, и проблема вернётся… ну разве что она сама собой не решится – такое, кстати, может произойти.
Но если сервис Azure AD Connect Health Sync Monitoring Service был установлен вместе с Azure AD Connect, то, наверное, не просто так. Поэтому лучше вернуть работоспособность сервиса, но после того как виновник будет найден. А для этого нужно понять что послужило причиной нарушения стабильности его работы. Если явным образом на сервере ничего не предпринималось и не устанавливалось никакого нового программного обеспечения, то, скорее всего, причиной стали обновления операционной системы.
Второй вариант устранения проблемы с загрузкой процессора как раз и заключается в поиске проблемного обновления. К сожалению, сейчас по данной проблеме в Интернете множество рекомендаций какое обновление повлияло на сервис Azure AD Connect Health Sync Monitoring Service. Каждый, кто решал эту проблему, указывает на какое-то своё обновление. Вот перечень этих обновлений от Microsoft, которые упоминаются в качестве решения проблемы (черный список):
- KB4103725
- KB4096417
- KB4095875
- KB4054566
- KB4338815
- KB4338419
- KB4340558
- KB4338605
- KB4339093
- KB4340006
- KB4338824
- KB4338814
Конечно же, если сервер не был предоставлен сам себе длительное время и совсем недавно проблемы не было, то поиск «подозреваемых» сужается до обновлений, установленных в недалёком прошлом. Из перечисленных «проблемных» обновлений в списке установленных недавно было только одно, и установлено оно было 22 июня: KB4338815. Остальных из списка выше я вообще не нашёл. Поэтому логично предположил, что виновник найден и я удалил его:
После перезагрузки операционной системы желаемого результата, к сожалению, не получилось. Поэтому было принято решение по очереди удалять все обновления от 22 июня в надежде разгрузить процессор от паразитного влияния программной ошибки. Таким образом последовательно были удалены ещё и следующие обновления в том порядке, как написаны: KB4345424, KB4339093, KB4338824. И только после удаления последнего обновления KB4338605, которое было установлено 22 июля, процесс Microsoft.Online.Reporting.MonitoringAgent.Startup перестал загружать систему. Является ли обновление KB4338605 корнем зла – трудно было сказать. Но я обратил внимание, что когда я по очереди удалял обновления – этими обновлениями пополнялся список потенциальных обновлений на установку. И лишь после удаления KB4338605 – оно в списке не появилось, а вместо него появилось обновление под номером KB4340006, которое, как Вы можете обратить – уже упоминалось и есть в черном списке, о котором я писал выше.
А главное теперь стало очевидно, что именно KB4338605 (оно же похоже и KB4340006) является корнем зла, т.к. в списках на установку висит обновление KB4340558, которое судя по названию, откатывает изменения обновления KB4338605 (KB4340006) и, которое, так же упоминается в черном списке выше!