System Center Configuration Manager и как с ним бороться

ConfigMgr Client Troubleshooter — ещё одна утилита, показывающая состояние клиента SCCM. Кроме информации о состоянии сервисов и просмотра логов, можно получить информацию об операционной системе, установить клиента, обновить политики, перезапустить назначенные объявления и т.д.
Скачать утилиту и получить полную информацию о ней можно в дневнике разработчика.

В случае, если ваш SCCM не получает данные о компьютерах, которые требуют обновлений, нужно просмотреть класс Win32_WindowsUpdateAgentVersion на клиентах. Чтобы узнать, заполняется он или нет, достаточно выполнить PowerShell-запрос: Get-WmiObject -Namespace ‘root\cimv2\sms’ -Class ‘Win32_WindowsUpdateAgentVersion’ -ComputerName имя_компьютера.
Если в классе ничего нет, то проверьте на клиенте логи ScanAgent.log:

CScanTool::Execute- Failed at AddUpdateSource, error = 0x80040692
Scan Failed for ToolUniqueID={0E1584FB-B2F8-4AA3-B610-56C02C91A059}, with Error=0x80040692

и WUAHandler.log:

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://ваш_сервер_WSUS and Policy ENABLED
Failed to Add Update Source for WUAgent of type (2) and id ({0E1584FB-B2F8-4AA3-B610-56C02C91A059}). Error = 0x80040692.

Вышеуказанные в логах строки означают, что групповые политики, отвечающие за обновления, не выключены и клиент SCCM «не видит» настроек сервера. Соответственно, SCCM не может определить наличие и версию Windows Update Agent на клиентах.
После отключения групповых политик и прохождения цикла инвентаризации класс заполнится и данные передадутся на сервер:

Спасибо участникам System Center Configuration Manager Russia за идеи.

При создании Deployment Packages из обновлений, которые находятся локально, мастер может выдать в финале следующую ошибку:

Посмотрите статус пакета: Site Database — Computer Management — Software Updates — Deployment Packages — имя вашего пакета — Package Status — Package Status — ваш сайт.
Если вы видите следующее —

— то всё нормально, не стоит пугаться: в данный момент пакет формируется и чуть позже будет скопирован на Distribution Point.

Иногда на клиентских компьютерах возникают проблемы с WMI-репозиторием, вследствие чего агент SCCM 2007 не устанавливается или работает с ошибками (например, не отправляет отчёты по инвентаризации или не даёт установить программное обеспечение). Приходится делать repairing/rebuilding WMI. В одиночных случаях могут помочь утилиты для работы с клиентом SCCM, но в большой сети на несколько сот или тысяч компьютеров нужно как-то автоматизировать процесс.
Leandro Farom на форуме TechNet выложил отличный скрипт, который удаляет WBEM-репозиторий, создаёт новый, перерегистриует .dll’s, удаляет и устанавливает клиента SCCM 2007. Настройка скрипта под свои нужды занимает меньше часа и экономит кучу времени.

Ссылки по теме:
WMI Corruption
WMI Troubleshooting Tips

Александр Андреев в своём обзоре утилит для SCCM 2007 забыл упомянуть про SCCM Client Check (скачать можно здесь).
С помощью этой утилиты мы можем:
— «проверить» клиентский компьютер (наличие администраторских прав, доступность (ping), настройки WMI и BITS, принадлежность к сайту);
— просмотреть логи (инсталляция клиента SCCM, нахождение MP и DP, принадлежность к сайту, и пр.);
— выполнить администраторские действия (привязать клиента к другому сайту, открыть оснастку «Управление компьютером» и т.д.).
В этом примере Main log показывает, что наш клиент жив и здоров:

Успешная установка клиента SCCM:

Утилита полезна при траблшутинге: