SCCM вкрай загадковий інструмент. Скільки з ним працюю, а він не перестає мене дивувати. Ось недавно у нас з ним знову виникло повне нерозуміння в моїх бажаннях і його можливості.
Відразу хочу сказати велике спасибі Олександру петлеву за моральну підтримку і кілька корисних посилань.
Отже, я приступив до нервового вивчення логів. Перше, що перевірили - коли агенти останній раз повідомляли про себе через Heartbeat Discovery. Для цього необхідно відкрити в будь-якої колекції будь-який комп'ютер, відкрити його властивості і по Agent Name знайти відповідний запис Agent Time.
У моєму випадку розбір "польотів" проходив 28го числа, а дата останнього Heartbeat Discovery була датована 14м числом. Упевнившись, що настройка Clear Insatall Flag варто в 10 днів (це можна зробити тут: Site Database -> Site management ->% SITE_CODE% -> Site Settings -> Site Maintance -> Tasks -> Clear Instal Flag -> Properties), причина видалення прапора IsClient стала зрозуміла: heartbeat не прийшов, завдання Clear Instal Flag чесно зробила свою справу. Залишалося "мале" - знайти причину, по якій агенти не повідомляли про свій стан.
Після швидкої перевірки логів, з'ясувалося, що весь функціонал SCCM працює штатно - за день до цього на кілька десятків комп'ютерів був успішно розгорнуто Office, OSD працювало штатно, всі інші Discovery теж працювали штатно. Тобто зламано була тільки Heartbeat Discovery.
1. Згідно з розкладом, агент формує XML-файл. Файл зберігається в приблизно такому вигляді:% windir% \ system32 \ CCM \ Inventory \ Temp \ d0c06056-6363-41ce-9a2e-5409e7702cbe.xml
2. Після формування файл відправляється за допомогою BITS на сервер SCCM (Management Point). На півночі все XML-файли потрапляють в папку% SCCM_DIR% \ inboxes \ auth \ ddm.box \
3. Після цього сервер обробляє отримані файли і записує отримані дані в базу.
Всі процеси, пов'язані в Heartbeat Discovery можна подивитися в лог-файлах, на строне агента це% windir% \ system32 \ CCM \ Logs \ InventoryAgent.log, на стороні сервера це% SCCM_CCM% \ Logs \ MP) Ddr.log.
Після вивчення логів, я просто впав у ступор - як на агентах, так і на сервері в логах були тільки записи про успішну обробці файлів. Жодної помилки в них не було. Прийшла ідея подивитися, що ж там в папці inboxes \ auth \ ddm.box \. І ось тут мене чекав сюрприз - в цій папці знаходилося близько 140000 файлів. Найраніший файл був якраз датований часом останнього повідомлення агентів про себе. При цьому в папці inboxes \ auth \ ddm.box \ BAD_DDRS, куди потрапляють збійні пакети, нічого не було. Швидкий пошук в Гуглі особливої інформації не дав.
Явною причиною проблеми було порушення процесу обробки пакетів DDR, тому з'явилася ідея видалити кілька самих ранніх файлів з папки inboxes \ auth \ ddm.box \. Після видалення приблизно 100 файлів і перезапуску служби SMS_EXECUTE на сервері, сталося диво - процес обробки файлів DDR став знову працювати, і число файлів в inboxes \ auth \ ddm.box \ досить швидко скоротилося до нуля. Версію про те, що процес порушився через збійних файлів DDR підтвердило появу в папці inboxes \ auth \ ddm.box \ BAD_DDRS близько 1500 файлів.