Алексей Максимов писал(а):Да действительно, похоже, что это трафик control channel
Посмотри здесь эту ветку. Там есть ссылка сюда на старую статью по тюнингу, но попробовать думаю можно и с 2012 R2, хотя трудно представить как себя потом поведёт сам VMM.

Спасибо, сейчас попробую. Скорее всего хуже не будет.

Собственно вот.

192.168.200.184 это сервер VMM. Порт как видно 5985. Трафик тоже видно. Это трафик суммарный за недельный период.

Алексей Максимов писал(а):А почему подозрение именно на VMM? По каким портам идёт трафик?

В отчете netflow фигурирует сервер VMM. На сервере кроме VMM собственно больше ничего не установлено. Сейчас проконсультируюсь с сетевиком на счет получения детального отчета по портам.

Коллеги, нарисовалась у меня следующая проблема. Развернут у нас SCVMM 2012 R2. Управляет он как локальным кластером, так и хостами Hyper-V в филиалах. Как выяснилось он генерирует 25% нашего ежемесячного VPN трафика с филиалами. Вопрос мой в следующем - можно ли как-то уменьшить частоту опроса VMM ...

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

Алексей Максимов писал(а):А разве это не здесь? - в консоли SCOM Authoring > MP Objects >Obj Discoveries > правило "DPM server discovery" где прописан VBS скрипт выполняющийся каждые 6 часов.

Почитал логи, этот скрипт тоже вроде как выполняется корректно.

Тогда можно предположить что обнаружение все таки работает, однако возвращает данные о старой версии DPM. Чтобы понять что именно в системе опрашивается в процессе обнаружения служб DPM надо уже разбирать сам MP. Да там простейшая проба на базе powershell скрипта <ProbeActionModuleType ID="Mic...

Проблема еще и в том что DPM разворачивали коллеги. Делали это не пойми как, без всяческого соблюдения Best Practice - в итоге там Windows Server 2008 R2 Russian =(

Алексей Максимов писал(а):Если удалить агента SCOM с проблемного сервера, так чтобы в консоли SCOM на вьюхе c DPM-серверами этот сервер больше не отображался. Затем заново установить агента, неужели он появляется в этой вьюхе с информацией о том что там старая версия DPM ??

Именно так. =(

В общем скрипт в ProbeActionModuleType ID="Microsoft.SystemCenter.DataProtectionManager.2011.Discovery.DPMServerAvailabilityModule" отрабатывает на ура. Проверил уже. Почему-то либо агент не может передать COM Object $bag на SCOM сервер либо SCOM не может его принять. Вопрос только почему ...