Обнаружение ресурсов в Configuration Manager - обзор, рекомендации, распространенные проблемы

Чтобы Configuration Manager мог работать с устройствами и пользователями, ему прежде всего нужно узнать о них, обнаружить тем или иным способом. Тема обнаружения ресурсов (Discovery) выглядит не очень обширной, она задокументирована и описана на русском языке во многих блогах в Интернете.

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

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

В этой статье я опишу наиболее подходящие для разных ситуаций настройки обнаружения, распространенные проблемы и наработки в эксплуатации Configuration Manager 2007 и в Configuration Manager 2012. Но, для начала, хочу напомнить, с какими методами обнаружения мы можем работать, и что они делают.

 

Configuration Manager 2007 R3

 

В Configuration Manager 2007 существует шесть методов обнаружения ресурсов. Четыре из них направлены на поиск пользователей, компьютеров и групп в Active Directory, один метод использует для поиска опрос сети, и еще один - пожалуй, самый важный - слушает "пульс" уже установленных на компьютерах клиентов. Кратко остановимся на каждом из них.

  

Active Directory User Discovery- обнаруживает учётные записи пользователей в Active Directory. Метод также обнаруживает, в каких группах состоят пользователи.

Описание метода и его настроек ( англ . / рус .), алгоритм работы ( английский и русский ).

Работа фиксируется в файле adusrdis.log.

Active Directory System Discovery - обнаруживает учётные записи компьютеров в Active Directory. Для нормальной работы метода, имя компьютера должно разрешаться в IP адрес при помощи DNS. Если это не так, AD System Discovery компьютер не обнаружит. Это сделано специально, чтобы исключить добавление неактивных компьютеров в базу данных.

Описание метода и его настроек ( англ . / рус .), алгоритм работы ( английский и русский ).

Работа фиксируется в файле adsysdis.log.

 Active Directory Security Group Discovery - обнаруживает группы в Active Directory.

Описание метода и его настроек ( англ . / рус .), алгоритм работы ( английский и русский ).

Работа фиксируется в файле adsgdis.log.

Active Directory System Group Discovery - обнаруживает дополнительнуюинформацию о том, в каких группах состоят компьютеры , обнаруженные методом AD System Discovery, и в каких OU они находятся . Данный метод не обнаруживает компьютеры сам по себе, а берет их из базы данных самого Configuration Manager, и опрашивает Active Directory о группах, в которых состоят эти ресурсы.

Описание метода и его настроек ( англ . / рус .) алгоритм работы ( английский и русский ).

Работа фиксируется в файле adsysgrp.log

 

Delta Discovery

С выходом R3 для Configuration Manager 2007, в описанные выше методы обнаружения из Active Directory добавилась возможность включить Дельта-обнаружение (Delta Discovery). Оно обнаруживает только изменённые в домене объекты, и за счет этого снижает нагрузку на сервер сайта. Вместо обработки данных о всех пользователях, компьютерах или группах, обрабатываются только новые или измененные. Таким образом, расписание Дельта-обнаружения можно сделать более агрессивным, по умолчанию оно настроено на каждые пять минут.

 У этой настройки есть очень важная особенность - Дельта-обнаружение в Configuration Manager 2007 R3 НЕ ОБНАРУЖИВАЕТ изменения членства компьютеров в группах. Только полный цикл AD System Group Discovery дает эту информацию.Таким образом, если у вас существуют коллекции, в которых компьютеры попадают на основании членства в группах AD, то коллекции смогут обновиться лишь после полного цикла AD System Group Discovery, а не Delta. Чтобы обойти эту особенность, можно одновременно с внесением компьютера в группу менять его атрибут, например, Description. Эта особенность устранена в Manager 2012.

 

Heartbeat Discovery - буквально "пульс" клиентов. В отличие от остальных методов, эта настройка действует на компьютеры с установленным клиентом Configuration Manager, а не на сервер сайта. Клиент раз в заданное время отправляет на сервер сигнал о том, что он все ещё работает. Можно сказать, что это самый важный метод обнаружения, потому что он даёт нам представление о реальном количестве "живых", работающих клиентов. Зачастую, именно Heartbeat Discovery не дает клиентам быть удаленными из базы данных при помощи задачи "Delete Aged Discovery Data". Если вы переименовываете компьютер, то Configuration Manager "узнает" об этом только после следующего цикла этого обнаружения, а не после очередной аппаратной инвентаризации.

Только этот метод влияет на признак "Клиент = Да" в коллекциях консоли администратора. Метод может быть настроен только на первичных сайтах. Хотя на вторичных сайтах эти параметры можно изменять, фактически они никогда к клиентам не применяются, клиенты их никогда не получают.

Технически, это еще одна разновидность инвентаризации, можно сказать, мини-аппаратная инвентаризация. В ходе цикла Heartbeat Discovery на сервер присылается такая базовая информация, как имя компьютера, версия ОС, IP-адрес и т.п. Вручную его можно запустить при помощи действия Discovery Data Collection Cycle в окне управления клиентом.

Описание самого Heartbeat Discovery и его настроек : ( англ. . / рус .) Работа фиксируется на клиенте в файле InventoryAgent .log

в папке %Windir%\System32\CCM\Logs или %Windir%\SysWOW64\CCM\Logs.

 

Процесс сбора информации и собираемые классы WMI можно наблюдать на клиенте в логе InventoryAgent.log: 

  

 

Network Discovery - данный метод позволяет обнаруживать компьютеры в сети опрашивая серверы DHCP (в реализации Microsoft), ARP-таблицы маршрутизаторов, и устройства, работающие с SNMP. Данным методом можно также обнаруживать домены Active Directory и IP-подсети. В основном его применяют для поиска компьютеров, не состоящих в домене, и на которых ещё нет клиента. Рекомендуется использовать этот метод, когда описанные выше другие методы недоступны, в самом начале развёртывания Configuration Manager, и в дальнейшем отключить.

Описание самого метода и принципов его работы ( англ . / рус .), настройки метода ( английский и русский ).

Работа фиксируется файле netdisc.log.

Все методы обнаружения готовят информацию для одного компонента на сервере сайта - Discovery Data Manager (DDM). Подробней с алгоритмом работы этого компонента в Configuration Manager 2007 R3 можно ознакомиться по следующим ссылкам- английский / русский машинный. Discovery Data Manager обрабатывает файлы *.ddr, каждый из которых содержит запись об одном объекте от любого метода обнаружения. Файлы *.ddr поступают в папку <директория установки ConfigMgr>\inboxes\auth\ddm.box\. Работа этого компонента фиксируется в логе ddm.log . Отправляемая на сервер информация имеет объем около одного килобайта на один ресурс.

В целом, методы описаны в онлайн-документации на Technet в статье "Планирование обнаружения в Configuration Manager 2007".

 

Что нового в Configuration Manager 2012

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

Методы обнаружения в консоли Configuration Manager теперь настраиваются в меню Administration / Overview / Site Hierarchy / Discovery Methods.

 

Active Directory Forest Discovery - новый метод, которого не было в Configuration Manager 2007.Обнаруживает сайты и подсети Active Directory, затем автоматически создаёт границы (Boundaries) на основе этих данных. До появления этого метода границы сайта нужно было задавать вручную.

Метод может публиковать служебные данные Configuration Manager в другие леса Active Directory, если указана соответствующая учётная запись, и схема этих лесов расширена. Метод может быть включен на Центральном административном сайте (CAS) или первичном сайте, который не является дочерним.

Описание метода и его настроек ( англ . / рус .). Работа фиксируется в файле ADForestDisc .log, публикация объектов - в файлах hman.log и sitecomp.log.

Active Directory System Discovery - так же, как и раньше, позволяет обнаруживать компьютеры из Active Directory, однако теперь появилась удобная возможность игнорировать тех, что не связывались с доменом или не меняли пароль своей учётной записи дольше определённого времени (по умолчанию это 90 дней). С введением этой возможности стало гораздо проще бороться с неактивными компьютерами, которые портят статистику охваченных клиентами машин.

Active Directory User Discovery - Обнаруживает учётные записи пользователей в Active Directory. В отличие от ConfigMgr 2007, этот метод теперь не обнаруживает членство пользователей в группах, для этого предполагается использовать метод Active Directory Group Discovery.

Active Directory Group Discovery -обнаруживает группы, а также членство компьютеров и пользователей в группах Active Directory. Этот метод многое упрощает, можно сказать, что в этом нём объединён функционал старых Active Directory System Group Discovery и той части User Discovery, что отвечала за группы пользователей. Если вы будете использовать этот метод, старайтесь, чтобы он запускался после того, как отработают AD System и User Discovery - это позволит методу работать более эффективно.

Delta Discovery

Недостаток предыдущей версии Дельта-обнаружения - невозможность обнаруживать членство компьютеров в группах - теперь устранён. Те администраторы, которые используют коллекции, наполняющиеся на основе групп Active Directory, смогут более оперативно получать результаты при минимуме затраченных ресурсов. Метод по-прежнему не выявляет удаление ресурсов из домена.

Heartbeat Discovery - этот важнейший метод остался неизменным с предыдущей версии продукта, он так же включен по умолчанию. Heartbeat Discovery настраивается на каждом первичном сайте иерархии.

Network Discovery - нет изменений по сравнению с предыдущей версией продукта. 

 

Какие методы обнаружения использовать?

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

Клиент Configuration Manager устанавливается методом Push Install сервером Configuration Manager, на предприятии используется Active Directory

В этом случае Configuration Manager может получать данные о существующих компьютерах из Active Directory, чтобы затем на каждый из них пробовать удаленно установить клиента. В этом случае рекомендуется использовать Active Directory System Discovery с включенным Delta Discovery.

Клиент Configuration Manager устанавливается групповыми политиками AD

В этом случае достаточно будет включенного по умолчанию Heartbeat Discovery. После установки клиенты сами выйдут на связь с сервером, и появятся в коллекциях.

Установка различного ПО назначается на коллекции, в которые включены группы пользователей или компьютеров.

В этом сценарии при необходимости установить какое-либо ПО пользователь или компьютер включается в группу AD, и работа с консолью Configuration Manager не ведётся. После включения в группу, сервер сайта Configuration Manager должен вначале получить информацию о новом составе группы, и лишь затем ПО будет назначено на этого пользователя или компьютера. Чтобы это произошло, в Configuration Manager 2007 необходимо использовать Active Directory Security Group Discovery для обнаружения самих групп, Active Directory User Discovery для обнаружения пользователей в группах, Active Directory System Discovery для обнаружения компьютеров, и, самое важное при установке ПО на группы с компьютерами, Active Directory System Group Discovery. Нужно заметить, что в этой версии ConfigMgr Delta Discovery не дает информацию об изменениях в группах, поэтому вам придется делать полный цикл обнаружения, чтобы быстрее устанавливать таким образом ПО.

Для выполнения тех же задач в Configuration Manager 2012 потребуется использовать AD Group Discovery, AD User Discovery и AD System Discovery. В этой версии Configuration manager Дельта-обнаружение стало лучше, и может обнаруживать изменения.

Установка ПО производится на коллекции пользователей

В данной ситуации все просто - Active Directory User Discovery с включенным Delta Discovery.

В Active Directory имеются некие дополнительные атрибуты, такие как этаж, на котором установлен компьютер, или номер телефона пользователя

На основании различных атрибутов AD можно строить коллекции, или устанавливать ПО. Даже для информации и учёта активов сбор этих атрибутов весьма полезен. В этом случае смогут помочь дополнительные настройки методов обнаружения Active Directory - в них можно задать любой нестандартный атрибут, и он попадет в базу Configuration Manager.

Клиент устанавливается методом Push Install с сервера Configuration Manager , на предприятии используются компьютеры в рабочей группе, либо из других доменов. Также присутствуют сетевые устройства, о которых нужно знать.

Если на этих компьютерах нет уже установленных "наших" клиентов, то в этом ситуации остается только Network Discovery. После обнаружения этих компьютеров в сети, можно посредством Client Push Installation установить на них клиентов, и управлять ими.

Также этот вид обнаружения позволяет делать простейший учет других сетевых устройств. Ими нельзя будет управлять при помощи этой системы, но они хотя бы будут обнаружены, и учтены Configuration Manager.

 

Практический опыт в иерархии

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

Только необходимое для работы

Совет не новый, но не лишним будет напомнить - старайтесь обнаруживать только то, что действительно нужно. В настройках обнаружения из Active Directory указывайте только те контейнеры, которые необходимы. 

Очередность работы методов

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

Движение обнаруженных объектов

В Configuration Manager 2007 обнаруженные на родительских сайтах ресурсы никогда не отправляются вниз по иерархии, только вверх. Таким образом, если у вас есть несколько сайтов, настраивайте обнаружение так, чтобы оно шло на дочерних первичных (Primary), тогда все обнаруженные записи будут обрабатываться и появляться в коллекциях на каждом вышестоящем первичном сайте, и стекаться в базу данных центрального сайта. Настраивать обнаружение на вторичных сайтах не имеет смысла, потому что эта информация все равно будет пересылаться на родительский первичный сайт.

В Configuration Manager 2012 обратная ситуация - информация обо всех обнаруженных ресурсах реплицируются сверху вниз. Если вы настраиваете обнаружение на нижних сайтах, то сведения о новых обнаруженных ресурсах будут просто пересылаться в виде файлов *.ddr на верхний первичный сайт либо Центральный административный сайт, где они будут обработаны, и при помощи SQL-репликации будут отправлены обратно на нижние первичные сайты. Только тогда эти ресурсы появятся в базе данных этих нижних сайтов. Это не касается Heartbeat Discovery, который будет обрабатываться локально на каждом первичном сайте, и данных об уже обнаруженных ранее объектах - они остаются на том первичном сайте, куда пришли.

С этим связан один крупный подводный камень - при потере связи с CAS записи о новых ресурсах во всей иерархии создаваться не будут! Как уже было сказано, CAS заносит информацию с нижних сайтов в свою базу данных, а затем уже реплицирует её вниз по иерархии. Таким образом, лучше настраивать обнаружение как можно выше в вашей системе, если это позволяет топология Active Directory, чтобы избежать лишней пересылки данных. В связи с этим я советую особенно тщательно резервировать канал и сам сервер центрального административного сайта.

Работа Discovery Data Manager

В больших иерархиях иногда приходится следить за тем, чтобы интервал обнаружения ресурсов не превышал возможности Discovery Data Manager. Если вы управляете иерархией с сотнями тысяч компьютеров, помните о том, что поддерживаемое системой количество клиентов - до 300 000 для ConfigMgr 2007 R3 и до 400 000 для ConfigMgr 2012 - рассчитывалось с учётом тех интервалов обнаружения, что заданы по умолчанию, то есть раз в неделю.

Представьте себе крупную иерархию с сотнями тысяч клиентов. Некоторые администраторы сайтов строят свой процесс установки ПО на ежечасном полном обнаружении групп и компьютеров из Active Directory. Другие устанавливают ежечасный Heartbeat Discovery. Третьи не стали мелочиться, и опрашивают все контейнеры в Active Directory на наличие компьютеров, пользователей и групп. В результате, на центральном сайте этой иерархии в служебных папках Discovery Data Manager скапливаются миллионы необработанных файлов *.ddr, которые задерживают появление в базе действительно новых объектов. В этом случае приходится сначала проверять производительность DDM и сервера SQL, и, если с ними все в порядке, менять настройки обнаружения во всей иерархии. Лучше провести аудит настроек и производительности до того, как придется ломать сложившиеся процедуры.

Еще одним часто встречающимся препятствием работе Discovery Manager является антивирусное ПО, в котором не настроены исключения на папку <директория установки ConfigMgr>\inboxes\auth\ddm.box\. В случае, если On-access Scan антивируса обрабатывает эту папку, могут возникать проблемы со своевременным появлением ресурсов в базе данных сайта. Симптомом такой проблемы может быть наполнение папки BAD_DDRs и записи в логе ddm.log о том, что процесс не смог получить доступ к файлу <имя>.ddr. Настройки исключений для Configuration Manager 2007 описаны здесь, Configuration Manager 2012 по этой ссылке.

Клоны

Если на предприятии для "заливки" компьютеров используется ПО, которое клонирует жесткий диск (такое как Acronis True Image, Norton Ghost), то будьте осторожны - после установки системы таким способом без специальных процедур могут возникнуть проблемы. Помимо повторяющихся Windows SID, в случае, если на эталонном компьютере стоял работающий клиент Configuration Manager, снятые с него образы будут содержать клиент с тем же SMSGUID. Так как Configuration Manager различает клиентов только по этому идентификатору, все клонированные компьютеры будут для него одним. Таким образом, клоном можно считать компьютеры с разными именами, но с одинаковым SMSGUID.

Как это выглядит? Первый установленный клон виден в консоли с признаками Client = Yes, Active = Yes и, на первый взгляд, вполне нормален. Однако на его счёт записываются практически все данные, полученные от остальных его клонов. Последнее выполненное назначение, какой пользователь заходил, сколько оперативной памяти на компьютере - все это меняется по мере поступления информации от других компьютеров. Для Configuration Manager эти клоны остаются машинами без клиентов, в консоли они имеют признак Client = No. Данные Heartbeat Discovery ото всех клонов записываются на один и тот же компьютер. При этом, все эти компьютеры получают политики и выполняют все задачи, назначенные хотя бы на одного из них - а это очень опасная ситуация.

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

Дубликаты компьютеров

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

Компьютеры с переустановленной ОС не представляют какой-либо проблемы, потому что будут со временем удалены задачей по обслуживанию сайта Delete Aged Discovery Data. Эту и другие задачи мы рассмотрим ниже.

Часто дубли образуются благодаря тому, что компьютеры обнаруживаются из Active Directory перед тем как на них будет установлен клиент. Когда клиент на такие компьютеры устанавливается не при помощи Push Install, то в системе появляются две разные записи - одна обнаруженная из Active Directory без клиента, другая - зарегистрировавшийся на Management Point компьютер с клиентом. Это часто встречается там, где клиент устанавливается вручную администраторами, либо там, где настроен очень маленький интервал Delta Active Directory System Discovery.

В последнем случае будет сложно успеть установить клиент на компьютер до того, как дубль появится в базе, и будет появляться множество дублей. Плохая особенность таких записей в том, что, скорее всего, их придется удалить из базы вручную. Задачи по чистке старых данных не будут удалять их, потому что записи из AD будут обнаруживаться каждый раз, и привязываться к тому компьютеру в базе, который был когда-то обнаружен первым, когда на нем не было клиента. "Настоящий" компьютер с клиентом будет посылать на сервер данные Heartbeat Discovery, которые будут привязываться к другой записи. Оба компьютера с одинаковым именем будут вполне нормальными ресурсами, с точки зрения Configuration Manager.

Это ожидаемое поведение, остается только подстроить интервалы дельта-обнаружения, и удалять дубли, создав соответствующую коллекцию. Подробней эта проблема и ее решение описана здесь.

Как клиенту пережить чистку базы?

Говоря об обнаружении новых ресурсов, следует упомянуть и об их удалении. В любой системе рано или поздно образуются неактивные записи, и лучше избавляться от них своевременно. Такие записи автоматически удаляются при помощи задач по обслуживанию сайтов (Site Maintenance Tasks). Подробное описание задач можно найди по следующим ссылкам для Configuration Manager 2007 и 2012.

Задача Delete Aged Discovery Data удаляет записи о компьютерах, которые не обнаруживались ни одним методом в течение определённого времени. По умолчанию это 90 дней. Особенность её в том, что даже если компьютера физически больше нет, но его учётная запись в Active Directory все еще есть, он не будет удален из базы Configuration Manager, пока не будет удалён из AD.

Другая особенность в том, что эта задача удаляет из базы данных информацию о существовании компьютеров из дочерних сайтов иерархии. Так как на верхнем сайте может быть не настроено обнаружение из доменов или OU тех нижестоящих сайтов, то для верхнего сайта единственным признаком существования компьютеров там остается Heartbeat Discovery. В случае, если задача Delete Aged Discovery Data будет работать чаще, чем компьютеры дочерних сайтов присылать Heartbeat, численность клиентов в базе данных родительских сайтов будет постоянно меняться, внося путаницу в управление иерархией.

Что можно сделать?

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