Типичные ошибки администраторов Configuration Manager и лучшие практики: часть 2

  • Article

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

Терминальные серверы:

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

Пользовательские политики

ConfigMgr начиная с 2012 позволяет таргетировать ПО на пользователя или группу, а также управлять некоторыми пользовательскими настройками (являясь своего рода заменой Active Directory для недоменных и мобильных устройств). Однако если с обычным устройством обычно работают единицы пользователей, то с терминальным сервером их количество заведомо больше.

Дизайн продукта таков, что если вы включите пользовательскую политику через клиентские настройки, то агент будет хранить в WMI политику для ВСЕХ пользователей, которые логинились на машину. Поэтому на терминальных серверах с большим числом пользователей включение пользовательской политики приводит к раздуванию размеров репозитория WMI до гигабайт и, как следствие замедлению работы WMI и всего того, что опирается на него. Усугубляется проблема в том случае, если в качестве терминального сервера используется непропатченная ОС Windows 2008 R2, для которой известно много проблем WMI (один из хороших списков есть в базе знаний Microsoft).

Также у репозитория WMI есть лимит размера 4 Гб, который нельзя изменить: при достижении этого размера любое ПО, попытающееся записать что-то в WMI получит ошибку WBEM_E_OUT_OF_DISK_SPACE. При этом какого-либо вменяемого способа уменьшить размер репозитория даже после выключения пользовательской политики не предусмотрено: только полный сброс, что может негативно отозваться на многом установленном ПО.

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

Инвентаризация:

Про опасность включения инвентаризации ряда классов WMI я уже писал, но для терминальных серверов тоже есть своя специфика.

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

Вновь я рекомендую выделить для терминальных серверов отдельную клиентскую настройку с отключенными опасными классами инвентаризации.

Software Metering

Малоизвестной особенностью Software Metering является то, что агент ConfigMgr мониторит запуски и завершения всех процессов на машине, на которой включена данная функциональность; при этом отчеты агрегируются и отправляются на сервер только для тех, которые задал администратор в консоли. Для терминальных серверов это может приводить к заметному замедлению работы ОС.

Поэтому я рекомендую включать Software Metering только на тех машинах, где это действительно требуется – и не на терминальных серверах.

Управление пользовательскими профилями

Относительно малоиспользуемым функционалом ConfigMgr является управление пользовательскими профилями через механизм Compliance Settings. Для терминальных серверов, как и включение пользовательской политики, включение функционала в клиентских настройках неизбежно приводит к проблемам с производительностью, поэтому убедитесь, что настройка "Enable User Data and Profiles" установлена в "No".

Общие рекомендации

В данном разделе я постараюсь описать некоторые важные моменты администрирования ConfigMgr не вошедшие в предыдущие разделы, в том числе не связанные с производительностью.

Задачи обслуживания сайта

Каждый сайт по заданному администратором расписанию производит ряд задач обслуживания. Убедитесь, что эти задачи сконфигурированы и выполняются (последнее, помимо лога и статусных сообщений, можно посмотреть в SQL-представлении vSQL_TaskStatus).

Среди этих задач особенно важны все задачи по очистке БД от устаревших ресурсов (Delete), а также реиндексация БД – без них база данных скоро перестанет работать так быстро, как хотелось бы. Последняя задача также может быть выполнена сторонними средствами, которые кажутся более приемлемыми вашим администраторам SQL.

Кроме того, не забывайте, что вспомогательные роли также требуют своего обслуживания, особенно это касается очистки и реиндексации БД WSUS.

Поддержание базы данных драйверов

Очередной соблазн начинающего администратора ConfigMgr – добавить в БД все драйверы устройств, которые он сможет найти, тем более диалог импорта способствует этому.

Однако такой подход приводит к целому ряду проблем. Во-первых, ConfigMgr при добавлении драйвера в пакет закачивает в БД контента все, что лежит в папке с драйвером. «Заботливые» производители драйверов могут положить туда маркетинговое видео на 300 мегабайт, и клиенты вашей инфраструктуры будут закачивать и его в процессе развертывания ОС. Поэтому поищите на сайте производителя очищенные от подобных «забот» драйверы или удалите лишнее сами (но на ваш страх и риск). Также многие драйверы (в очищенном виде!) теперь доступны для закачки в каталоге обновлений Microsoft, причем поддерживается поиск по Plug-n-Play ID устройства.

Во-вторых, исходную папку драйвера лучше не менять: иначе при обновлении пакета с драйверами или загрузочного образа, содержащего драйвер, вы получите ошибку. Продумайте и реализуйте схему хранения драйверов и впредь её придерживаетесь, чтобы избежать этого, а также не удаляйте драйвер из исходной папки пока не удалите его из консоли (папки пакетов драйверов обслуживаются сами).

В третьих, помните о таймауте 8 минут при авто-поиске драйверов. Шаг авто-поиска (Auto apply drivers) собирает данные об устройствах в XML и отправляет их на сервер для поиска драйверов. Сервер же выполняет хранимую процедуру в БД SQL и возвращает результаты поиска. В том случае, если в БД слишком много драйверов, база давно не индексировалась или просто производительность SQL недостаточна, то шаг Auto Apply Drivers завершится ошибкой по таймауту – и на этом ваше развертывание ОС закончится, либо продолжится без установленных драйверов. Поэтому отключайте и удаляйте ненужные драйверы, а также пользуйтесь категориями для лимитирования поиска. В качестве временного решения в ConfigMgr 1610 и выше можно пользоваться переменной Task Sequence SMSTSDriverRequestReceiveTimeOut.

Что касается драйверов для загрузочных образов (WinPE): проверьте на сайте производителя оборудования не выложил ли он для них отдельных драйверов в формате INF и без лишних файлов. Например, HP поддерживает полноценный пакет драйверов для WinPE, причем для всех моделей сразу.

Патчи, патчи и еще раз патчи

Больших продуктов без ошибок в коде не бывает и ConfigMgr в этом плане не исключение. Поэтому не забывайте поддерживать его в актуальном состоянии, чтобы при обращении в службу поддержки не получить банальное предложение поставить последнее обновление. Напомню, современные версии ConfigMgr Current Branch умеют обновляться прямо из консоли, для версий же 2012 SP2/R2 SP1 можно установить Servicing Extension для консоли. Кроме того, начиная с версии 2012 SP2/R2 SP1 CU1 клиенты умеют автоматически обновляться на последнюю версию, в том числе в процессе переустановки ОС.

Однако ошибки бывают не только в коде ConfigMgr, но и в коде вспомогательных технологий: таких, как WSUS и Windows Update Agent. Поэтому не забывайте про установку последних обновлений как на серверную часть, так и на клиентскую, чтобы избежать таких массовых проблем, как сканирование обновлений на Windows 7 приводит к чрезмерному потреблению ресурсов.

Напомню также про описанные выше проблемы с WMI на Windows Server 2008 R2: они актуальны и для многих других случаев – например, работы точки распространения (Distribution point) на данной ОС.

Внесение изменений в БД и бэкап снепшотами VM

В заключение хотел бы указать на две вещи, которые не надо делать никогда.

Во-первых, не надо изменять настройки или содержимое БД SQL вручную, даже  если эта рекомендация приведена на нашем Форуме технета. Когда у вас что-то перестанет работать, и вы откроете кейс в поддержке, то инженер вряд ли узнает о том, что вы что-то когда-то поменяли вручную, но решить проблему может быть уже поздно. Общее правило таково: вносите изменения в БД только в том случае, если вы абсолютно уверены в том, что делаете, и сможете это протестировать – или это вам порекомендовал инженер Microsoft. Детально правила поддержки можно почитать здесь.

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

Заключение

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

Comments

  • Anonymous
    January 19, 2017
    Павел, спасибо за отличную серию статей. Но вот как быть с постоянными ошибками БД в таблице INSTALLED_SOFTWARE_DATA? Ошибка постоянно проявляется у многих, по слухам в релизе 1511 она осталась (https://social.msdn.microsoft.com/Forums/ru-RU/b4ef06b6-87e2-4063-87a2-d195035aac7b/sql-2012-sp1-8152-string-or-binary-data-would-be-truncated-dinstalledsoftwaredata?forum=sqlru). Изменять базу нельзя, переставлять ОС не всегда возможно. Что делать?
    • Anonymous
      February 16, 2017
      Добрый день,У меня, к сожалению, нет лабораторного окружения 1511 под рукой, но в 1610 проблема точно решена (колонку ServicePack00 в INSTALLED_SOFTWARE_HIST расширили до 255 символов).В R2 SP1 проблема точно НЕ решена.Если проблема сохраняется после обновления на 1610, то имеет смысл открыть кейс в поддержке - скорее всего это другая проблема.