суббота, 25 сентября 2021 г.

Pre-provision Bitlocker во время OSD

Если вам захотелось сделать Pre-provision Bitlocker во время OSD и получить, например, зашифрованный OS Drive на выходе со стандартным ПИН-кодом, у меня для вас кое-что есть.

Мы имеем очень просто тестовый Task Sequence, SCCM 2107


Нас интересуют два шага:

  1. Pre-provision Bitlocker
  2. Enable Bitlocker
В документации (два пункта выше - кликабельны в офф документацию) есть описание этих двух шагов, но нет одной маленькой детали.

На шаге Enable Bitlocker имеем вот такую картину, ПИН-код установлен 9753 (менее 4х символов ПИН-код не принимается и подсвечивает красным:



Начинаем установку тестовой ВМ и получаем ошибку на шаге Enable Bitlocker


Идем смотреть в smsts.log и видим там немного подробностей



Ошибка в явном виде мало о чем говорит, но методом проб и ошибок выясняется, что на шаге Enable Bitlocker минимальная длина ПИН-кода все таки 6 символов, а не 4, после которых он начинает его принимать, так же визард спокойно примет ПИН-код 1234, но дальше вас тоже будет ждать разочарование.

В документации нигде не описана минимальная длина ПИН-кода для шага Enable Bitlocker, потому что в политике можно указать минимульную длину 4 символа и спокойно зашифровать раздел с ПИН-кодом 9753, визард так же не проводит никаких проверок, кроме минимальной длины в 4 символа.

Ради интереса я попробовал задеплоить политику Bitlocker, где явно указано, что длина ПИН-кода должна быть минимум 4 символа на коллекцию All unknown computers. Результата так же не дало.

четверг, 9 сентября 2021 г.

Циклы установки обновлений на рабочие станции

Я не являюсь фанатом использования окон обслуживания на рабочих станциях, т.к. если мы выбираем путь вообще не затрагивать пользователя в рабочее время, а это обеденный перерыв, время после 18-00 и выходные дни, то сталкиваемся с рядом проблем:
  • 1 часа в обеденный перерыв может быть недостаточно для установки обновлений
  • Пользователь выключает ПК после рабочего дня (особенно ноуты)
  • Пользователь выключает ПК на выходные
Как итог - имеем никогда не устанавливающиеся обновления, потому что доступного окна никогда нет. Если мы используем дедлайны и указываем, что при наступлении дедлайна принудительно устанавливать обновления - это опять таки немного выбивается из "не затрагивать пользователя в рабочее время".

Возможно, для каких-то групп рабочих станций/особенных пользователей есть смысл использовать окна обслуживания.

Итак, как мы знаем, Patch Thuesday происходит во второй вторник месяца. Мы запускаем ADR для рабочих станций каждое 15е число месяца в 06-00. 
Почему 15е число? Потому что 2й вторник бывает максимум 14го числа. У нас есть как минимум один день, что бы узнать, что какие-то обновления вызывают какие-то проблемы и притормозить цикл даже для первой волны.

Мы используем 3 волны обновлений:
  1. Тестовые виртуальные машины + несколько некритичных машин (это можеть быть моя вторая машина, например). На данном этапе мы проверяем только то, что обновление устанавливается, машина не падает в BSOD, возможны какие-то мелкие проверки. Я рекомендую НИКОГДА не использовать для первой волны тестирования машины технической поддержки. Это очень распространенная практика, но при таком раскладе можно получить ситуацию, что вся ТП останется без своих рабочих станций. Буквально недавно был случай с 1607 LTSB, которая после установки CU падала в BSOD.
  2. Вторая волна обновлений включает в себя около 10-15% рабочих станций организации. В идеале туда должны входить рабочие станции с ПО, которое необходимо проверять после установки обновлений, в случае неудачного обновления, что бы этим ПО можно было воспользоваться где-то еще в отделе, но это утопия. Вторая волна обновлений формировалась по принципу лояльности пользователей - мы выкатили патчи с available периодом в 1 неделю и посмотрели, кто ставит патчи вручную, среди этих пользователей и была сформирована вторая волна обновлений.
  3. Массовый деплой обновлений на все рабочие станции.

Сами циклы обновлений по расписанию (даты могут быть изменены, суть в количестве дней - 1, 7, 5 на добровольную установку):

Волна 1. 15 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 16 числа 06:00, далее дедлайн.

Выдерживаем паузу в 3 дня, что бы опять же почитать новости/community/посмотреть на машины первой волны.

Волна 2. 18 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 25 числа 06:00, далее дедлайн.

Волна 3. 25 число месяца в 06:00 по местному времени мы назначаем Required установку. Available период до 30 числа 06:00, далее дедлайн.

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

Так же мы обязательно выводим все уведомления для пользователя, что бы он всегда знал, что ему доступны обновления или что они в данный момент устанавливаются.

После установки обновлений мы не подавляем перезагрузку, а даем 12 часов на ребут (в политике агента Computer Restart). 


Бывает не очень удобно, когда цикл выпадает на выходные дни. Тут бы, конечно, могли помочь окна, но есть свои но. Всегда найдется кто-то, кто вышел поработать специально в выходной день, а мы тут со своим ребутом и патчами.