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

Я не являюсь фанатом использования окон обслуживания на рабочих станциях, т.к. если мы выбираем путь вообще не затрагивать пользователя в рабочее время, а это обеденный перерыв, время после 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). 

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