Com

Я тут ском чиню

те что 3rd party catalog

для любых апдейтов нужно: https для контента, может быть http/https/ftp или вообще локал фолдер

но ведь на ажур дне ты говорил как он хорошо работает)))

Вчерашний индус в английском чате мне напомнил картинку

Это откуда такое? Не видел раньше

@quantum_yupiter Паш? А еще вопрос когда у коллекции юзеров - директом сама группа АД добавлена, CI/CB не прилетает, так задумано?

Сереж, у меня в коллекцию ползателей добавлены АД группы, в которые в свою очередь иногда добавлены другие АД группы. Дельта дискавери отрабатывает норм. Тридцать минут и в ЦПО.

Скорее надо у пользователя запросить адешная группа задискаверилась или нет. Ну т.е. есть ли в списке AD групп у пользователя искомая, добавленная в коллекцию

Скорее надо у пользователя запросить адешная группа задискаверилась или нет. Ну т.е. есть ли в списке AD групп у пользователя искомая, добавленная в коллекцию

и кстати ключ то вроде другой надо для КMS - https://docs.microsoft.com/ru-ru/windows-server/get-started/kmsclientkeys

пофегу, все равно тоже самое пишет

The MP will perform a user group lookup against AD for each user policy request, getting the current list of group SIDs and passing that to SQL when running the sproc to get policy

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

Коллеги, предупреждение небольшое: если у вас есть коллекции по User OU Name или отчёты - и вместе с тем у вас есть русскоязычные OU - не торопитесь ставить 1902 или 1810 HFRU2

Ооо. Сорян. У меня коллекции компов по оу

Таки интересно - много у кого есть коллекции пользователей по OU в этом чатике? 😊

1902 или 1810 не ставили?

Вроде были когда то. 1902 стоит. @purgenerator не жаловался. Но все на английском.

Лонгрид кулстори (или не кул) для чата. Дисклеймер: В рассказе может быть сложно проследить сюжет. Чукча не писатель, чукча читатель. Свежачок, с прошлой недели. Дано: иерархия на 55 тысяч компов, один праймари сайт и инфраструктура на 270 серверов. Почти 2 недели назад обновили мы, значит, винду на primary site server с 2012 на 2016. Дерьма выхватили, конечно (это вообще отдельная стори), но доблестно пофиксили новые баги, после чего вернулись к починке старых. Так вот, один из старых багов это неработающий SMS Provider (на одном из двух серверов с соответствующей ролью). Дело было в понедельник, неделю назад. Из Бразилии подняли кейс в Майкрософт и почти сразу получили инженера из USA. Стали ему шарить скрин, логи показывать, всё такое. Смотри, мол, в консоли показывает что провайдера 2, а работает только один по факту. Инженер выслушал, всё посмотрел и предложил запустить Configuration Manager Setup, в визарде выбрать Modify SMS Provider configuration, дабы посмотреть что визард думает про количество провайдеров в иерархии, мол, мы только посмотреть, рид онли то есть. Как ни странно, визард думал, что провайдер у нас один... Признаться, я хз в какой момент и почему что-то пошло не так, но в итоге во время этого скрин шэринга под чутким руководством инженера была запущена реконфигурация сайта. Эпично, что ни инженер, ни наш аналитик этого не заметили... Ещё более эпично, что она (реконфигурация) зафейлилась, не успев завершиться. Служба sms_site_component_manager хоть и значилась в статусе running, не работала от слова совсем. И верх эпичности, что он успела снести нам почти все Management Points и мониторинг на хер убила. Тревогу забили в четверг, потому что статусы деплойментов долго не отображались и после установки ОС клиенты в большинстве случаев не могли нормально коммуницировать с центральной инфраструктурой. Начинал я это всё раскуривать как проблему с MP, а выяснил в итоге, что у нас реконфигурация сайта в процессе... Что там реконфигурируется никто не догадывается. Опять же из Бразилии подняли ещё один кейс в майкрософт и опять получили инженера из USA (но уже другого). Предварительно, я погасил sms_site_component_manager от греха подальше. Но startup type не менял (идиота кусок), ибо рестарт по плану только в выходной. Хотели совместно с инженером понять можно ли реконфигурацию отменить (нет, нельзя), можно ли посмотреть что мы там вообще реконфигурируем (тоже нельзя), и как бы нам вернуть к жизни MPs, чтобы обслуживать клиентов и дотянуть до выходных, а там уж хоть сайт резет (а это можно). Решили руками поставить MP на одном из серверов. Вроде как поставили, но что-то не до конца завелось и инженер такой, а давай сайт сервер ребутнем и оно просрется... Напомню, что для site_component_manager я startup type не менял, и при ближайшем старте сервиса сайт ожидала запланированная ранее хз какая реконфигурация. Собсна, так и произошло. Но ни инженер MS, ни наш аналитик не поняли что ящик пандоры открыт и реконфигурация набирает обороты. После рестарта сервера наш аналитик поехал домой (пока он ехал, реконфигурация шла полным ходом) и уже оттуда посмотрел,что MP заработал. Чирканул мне кратенько в ватсапе, что всё стало лучше, а детали завтра обсудим (у него уже ночь была). Он даже написал письмо с перечислением того, что они сделали и что в итоге получилось и со спокойной душой и чувством выполненного долга закрыл ноутбук. Только вот закрыл быстро и письмо не отправилось... Утром я пришел и был приятно удивлен тому, как хорошо всё работает, ибо ещё день назад всё было очень плохо. Не обнаружив письма я начал смотреть по логам что же они там делали и увидел, что имело место быть реконфигурация. Подумал, что небось инженер смекалистый попался и всё как-то шустро починили а для удобства сделали сайт резет (ну мало ли как там всё шло). Ждал бразильца, чтобы он рассказал историю подвига, предотвратившего трагедию. Только вот с его точки зрения они чинили руками один сервер, и не осознавали, что починили вообще всё... Такие дела... Длинная история получилась... Дабы как-то подытожить написанное выше скажу,

что хуевертить в SCCM можно не только в одиночку. Даже работа под чутким руководством premier support инженера в рамках Severity A кейса, не обезопасит вас от нежданчиков. В нашем случае, всё закончилось хорошо, хоть мы и дестабилизировали сервисы на 4 бизнес дня... Спасибо всем, кто дотянул до конца и смог понять этот лонгрид 🙂

Support Center OneTrace (Preview)

Мониторинг бы всю почту засрал