Недавно столкнулся с проблемой у одного из Заказчиков.
В образ, используемый в процессе OSD, был вшит клиент ConfigMgr без предварительного выполнения необходимых процедур что привело к следующей проблеме:
Машины имели одинаковый SMSUniqueIdentifier и пропадали в коллекциях ConfigMgr, клиенты не получали политик, как следствие, функционал продукта не работал.
Мне было необходимо их идентифицировать, чтобы понять масштаб проблемы.
Все машины имели файл smscfg.ini, который по-умолчанию размещается в папке C:\Windows, содержащий одинаковые значения.
Собственно, для этого был заготовлен скриптец ниже. Основой для анализа стали два поля SMSUniqueIdentifier и PreviousSMSUUID.
Качаем тут
В образ, используемый в процессе OSD, был вшит клиент ConfigMgr без предварительного выполнения необходимых процедур что привело к следующей проблеме:
Машины имели одинаковый SMSUniqueIdentifier и пропадали в коллекциях ConfigMgr, клиенты не получали политик, как следствие, функционал продукта не работал.
Мне было необходимо их идентифицировать, чтобы понять масштаб проблемы.
Все машины имели файл smscfg.ini, который по-умолчанию размещается в папке C:\Windows, содержащий одинаковые значения.
Собственно, для этого был заготовлен скриптец ниже. Основой для анализа стали два поля SMSUniqueIdentifier и PreviousSMSUUID.
Собственно, варианта решения три:
- Включение автоматического разрешения конфликтов клиентов;
- Разрешение конфликтов в ручном режиме;
- Полная переустановка агента с удалением ранее установленных компонентов, а так же удаление ПК в ConfigMgr.
На скриншотах видно, что много клиентов имеют одинаковый PreviousSMSUUID (выгрузка делалась после включения функционала разрешения конфликтов).
Качаем тут
Комментариев нет:
Отправить комментарий
Уважаемый коллега, Ваш комментарий пройдёт модерацию, чтобы избежать спам-атак в ленте. Спасибо за понимание.