Быстрая загрузка обновлений в Windows 10


С выходом Windows 10 Creator компания Microsoft продолжила оптимизацию установки обнвлений и вернула быструю загрузку (Express download) обновлений.

Мы уже знакомы с ней — в WSUS быстрая загрузка поддерживалась многие годы. Суть быстрой загрузки в том, что клиент загружает не полный пакет обновления, а только нужную часть, которая может оказаться значительно меньше полного пакета. Это ускоряет загрузку и экономит место на диске. С учётом того, что сейчас обновления занимают по несколько гигабайт, «новшество» выглядит очень полезным. (Обновление до версии Creator с предыдущего preview у меня выглядело как перезагрузка вместо часовой переустановки системы. Если это станет правилом для последующих обновлений, то это будет замечательно.)

Теперь эта оптимизация работает не только на WSUS, но и на SCCM и Windows Update для последних версий Windows 10.

Корпоративные клиенты уже давно могут использовать преимущества BranchCache  для загрузки обновлений. В Windows 10 появилась Delivery Optimization, которая в отличие от Branch Cache позволила использовать внешние (находящиеся в Интернет) клиенты Windows 10 для загрузки обновлений.

Подробности в документации.

 

Изменения в модели обновлений Windows 7 и 8.1


Источник https://blogs.technet.microsoft.com/windowsitpro/2016/08/15/further-simplifying-servicing-model-for-windows-7-and-windows-8-1/

С октября 2016 года будут только кумклятивные обновления двух видов: кумулятивное обновление безопасности (включает все ранее выпущенные обновления безопасности) и полное кумулятивное обновление (включает все ранее выпущенные обновления безопасности и иные обновления).

Для .Net аналогично: будет только одно полное кумулятивное обновление (включает все ранее выпущенные обновления безопасности и иные обновления) для всех версий сразу и только одно обновление безопасности (включает все ранее выпущенные обновления безопасности) для все версий сразу. Эти пакеты будут только обновлеть установленные версии, но не будут ставить новые версии .Net.

Как видно, модель обновления максимально приближается к модели обновлений Windows 10. Размер обновлений ожидаем соответствующий.

WUAUCLT


Утилита wuauclt.exe существует давно. Основное её назначение – запустить поиск обновлений. Делается это так wuauclt /DetectNow Очень полезно бывает при установке новой системы, чтобы побыстрее накатить все обновления. Или удобно при удавленном подключении к компьютеру, например, с помощью WS-Management (winrs).

Собственно я этим и ограничивался. Чтобы запустить непосредственно установку обновлений, приходилось использовать GUI.

Случайно обнаружил у команды wuauclt недокументированные ключи для Windows 7 (и выше):

/DemoUI

/IdleShutdownNow

/ShowOptions

/ShowWUAutoScan

/UpdateNow

/SelfUpdateUnmanaged

/SelfUpdateManaged

/CloseWindowsUpdate

/ShowWindowsUpdate

/ShowWU

/ResetEulas

/ResetAuthorization

/ShowSettingsDialog

/RunHandlerComServer

/ReportNow

/DetectNow

 

Среди них есть ключ /UpdateNow – он запускает установку обнаруженных обновлений.

Теперь можно делать так: wuauclt /DetectNow /UpdateNow

Остальные полезные ключи выделил жирным.

Немного об обновлении серверов


Какую бы стандартную схему установки обновлений не предложила бы Microsoft, все равно она не подходит на все случаи жизни. Так в с недавних пор после установки обновлений на сервер по расписанию сервер не перезагружается, если есть открытый интерактивный сеанс. С одной стороны это удобно, потому администратор может выполнять на сервере критически важную задачу. С другой стороны стоит закрыть последнюю сессию – сервер тут же перезагружается. Если администратор вышел с сервера во время рабочего дня, то наступает аварийная ситуация. Напрашивается правило для администраторов: не открывать на серверах локальные интерактивные сессии. Но реально ли это? На практике всё равно придётся некоторые работы проводить локально на сервере. Значит при наличии большого числа серверов и большой группы администраторов неизбежно будут появляться «брошенные» сессии. Даже если их ограничить по времени, то все равно будут возникать ситуации непредсказуемой перезагрузки серверов в рабочее время, когда это крайне нежелательно.

Если исходить из того, что сама стандартная модель автоматического обслуживания в принципе устраивает (сервер перезагружается, когда фактически он не используется), то остается вопрос: как нивелировать влияние «брошенных» сессий? Логично закрывать сессии вручную (после проверки, что она не используется) и перезагружать сервер в допустимое время. Остаётся вопрос: как найти серверы в состоянии «pending reboot», т.е. серверы которые ожидают перезагрузки. Надо отметить, что консоль WSUS не всегда показывает в отчётах, что сервер находится в состоянии «pending reboot»: это состояние может вызвать не только установка обновлений, но и компонент системы или программ третьих фирм.

Поможет скрипт Get-PendingReboot — Query Computer(s) For Pending Reboot State. Для удобства его (после небольшой доработки) можно запускать на серверах с помощью SCCM и его механизма Compliance.

Схема работы:

  1. Смотрим отчёт SCCM на текущее время окна обслуживания.
  2. Берем сервер, который попадает в это окно обслуживания, и проверяем есть ли на нём открытые сессии.
  3. Если есть, то проверяем можно ли их закрыть. Закрываем и перезагружаем сервер.
  4. Если нет, то просто перезагружаем сервер.

Опыт внедрения Internet Explorer 11 в корпоративной среде – Часть 2.


Продолжение Опыт внедрения Internet Explorer 11 в корпоративной среде.

После одобрения установки IE11 на рабочие места через некоторое время на WSUS стало видно, что есть некоторое число компьютеров с ошибкой установки. Для пользователей это плохо ещё и потому, что IE11 пытается установиться раз в сутки повторно, замедляя работу компьютера.

В логе IE11_Main.log (находится в c:\windows) обнаружились строки:

01:17.782: ERROR: WMI query for Hotfixes timed out. Query string: ‘Select HotFixID from Win32_QuickFixEngineering WHERE HotFixID=»KB2729094″‘ Error: 0x00040004 (262148).

01:18.016: INFO: KB2729094 could not be download is not installed.

Читать далее

Обновления для Microsoft Visual C++ Redistributable Package


Логическая бомба с установкой обновлений безопасности. На WSUS сервере выбраны продукты, которые используются: система, Office и т.п. Обновления безопасности для них ставятся везде, где нужно.

Выполняем проверку сканером MBSA, и он показывает необходимость установки обновлений безопасности для Microsoft Visual C++ Redistributable Package. В WSUS эти обновления не приезжают, потому что продукты Visual Studio не одобрены! – нет такого продукта у пользователей.

Импортировал в WSUS обновления:

Kb 973923 Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package

Kb 2538243 Microsoft Visual C++ 2008 SP1 Redistributable Package

Kb 2565063 Microsoft Visual C++ 2010 Service Pack 1

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

Вот такая интересная засада может случится – пользуйтесь почаще Microsoft Baseline Security Analyzer.

Миграция с WSUS на SCCM


Установка обновлений через WSUS достаточна проста. Если тщательно проработать группы и правила автоматического одобрения, то установка обновлений становится совсем не обременительной для администраторов. Более того, можно использовать скрипты для управления установкой обновлений, чтобы еще более повысить гибкость и удобство. Для небольших компаний такой подход идеальный.

Если же инфраструктура усложняется и растет в объемах, появляются многочисленные группы серверов и пользователей требующих особого подхода, то гибкости WSUS может уже не хватать. Обычно в такой инфраструктуре появляется Configuration Manager, и через какое-то время все процессы управления начинают тяготеть к SCCM. В том числе это касается установки обновлений.

И тут начинается ломка сознания: как жалко ломать настроенный и отлаженный механизм WSUS и заново отстраивать новый в SCCM! А сколько сил и времени это займет!

Оказывается, не все так ужасно – все уже написано до нас! Мне попалась статья Migrating from WSUS to Configuration Manager, в которой описаны скрипты миграции. Первый скрипт выгружает из WSUS список групп и одобренных для них обновлений, а второй импортирует эту информацию в SCCM, создавая в нем группы и включая в них нужные обновления. Эти скрипты не сделают всю работу за нас, но саму черновую да! Администратору остается (всего лишь!) продумать и реализовать процедуры установки обновлений, используя все расширенные возможности SCCM, которых нет в WSUS.