Может возникнуть ситуация, когда есть потребность в установке исправления Windows (Hotfix) недоступного через WSUS на большое число компьютеров. Для автоматизации этой задачи можно использовать разные инструменты, такие как logon-скрипты, GPO, SCCM. Рассмотрим альтернативный метод распространения исправления Windows с помощью утилиты Local Update Publisher на примере недавно выпущенного обновления, описанного в статье базы знаний Microsoft - KB2647169 - Windows Fax and Scan cannot send a fax if Internet Explorer 9 is installed in Windows 7 or in Windows Server 2008 R2 исправляющего проблему описанную в заметке Не работает консоль “Факсы и сканирование Windows” после установки IE9– Ошибка сценария 2107

Local Update Publisher (LUP) это свободно распространяемая утилита, которая позволит нам создать собственный пакет обновления и интегрировать его в инфраструктуру существующего локального сервера WSUS. По большому счёту LUP это упрощённый графический инструмент для работы с стандартными функциями WSUS API 

Итак, со страницы загрузки проекта скачаем программу установки Local Update Publisher.msi и набор вспомогательных файлов RunIt v5.zip

Установим LUP и первым делом в меню Tools > Certificate Information создадим само-подписанный сертификат, который потребуется нам для подписания создаваемого нами в дальнейшем пакета обновления WSUS. В веб-документации проекта можно найти информацию о том, что вместо само-подписанного сертификата можно использовать сертификат созданный на основе локального доверенного ЦС, но мне так и не удалось это сделать … возможно из-за того, что на своём WSUS сервере я не использую SSL, а может быть по какой-то другой причине … если честно, я сильно не зарывался в эту тему. Тем более я сразу столкнулся с такой особенностью LUP, что при первом подключении к серверу WSUS само-подписанный сертификат создается автоматически и изменить его в дальнейшем через UI не представляется возможным, про что честно написано в веб-документации. Так как само-подписанный сертификат будет использоваться для цифрового подписания создаваемого обновления, мы должны распространить его на все компьютеры использующие WSUS, в том числе и на сам сервер WSUS. Для этого экспортируем сертификат через меню Tools > Certificate Information > Export Certificate

Полученный файл сертификата мы можем распространить на компьютеры сети например с помощью GPO. Сертификат должен быть включен в два хранилища – Trusted Root Certification Authorities и Trusted Publishers

После того как сертификат распространён, приступим непосредственно к процессу создания и интеграции обновления в WSUS.

Так как в своём примере мы решили рассмотреть хотфикс описанный в статье KB2647169, скачиваем по ссылке указанной в статье два соответствующих файла файла:

441143_intl_i386_zip.exe – для 32-битных систем
441144_intl_x64_zip.exe – для 64-битных систем 

Распаковываем их и получаем соответственно два файла Автономного установщика обновлений:

Windows6.1-KB2647169-x86.msu
Windows6.1-KB2647169-x64.msu

Распаковываем msu файлы в разные подкаталоги. Сделать это можно как любым архиватором например 7zip так и встроенной в Windows утилитой expand

 

cd /d "C:TempKB2647169"

mkdir "x64"

expand "Windows6.1-KB2647169-x64.msu" -F:* "x64"

mkdir "x86"

expand "Windows6.1-KB2647169-x86.msu" -F:* "x86"

Из ранее загруженного архива вспомогательных файлов LUP копируем файл RunIt.exe в папку x86 и RunIt64.exe в папку x64.

В интерфейсе LUP в меню Tools > Create Update вызываем мастер создания обновления

Как вы уже наверно поняли, мы специально сделали два подкаталога с распакованными файлами обновления для того, чтобы создать два отдельных пакета WSUS в зависимости от разрядности клиентской ОС. Рассмотрим пример создания первого пакета для 32-битных систем.

На поле Update File выберем вложенный в каталог x86 вспомогательный файл RunIt.exe. C помощью кнопки Add Files добавим в пакет все файлы, которые есть в каталоге x86 за исключением самого файла RunIt.exe

На следующем шаге мастера зададим основные настройки пакета, а именно:

• Package Type: Update

  Помимо типа пакета Update в LUP есть тип пакета Application, который позволяет интегрировать в WSUS даже установку приложений сторонних производителей.
  

• Package Title: Hotfix….KB2647169
  
  Сюда введём название нашего обновления. Традиционно в название пакета входит номер статьи KB. Не будем отходить от этой традиции, так как именно это название будет отображаться на клиенте WSUS в процессе установки обновления.
  
• Description

  Заполняется по желанию. Я в своём примере в качестве описания использовал название статьи KB и причину возникновения исправляемой проблемы.
  

• Classification: Hotfix

  Из выпадающего списка можно выбрать и другие значения классификации. Но я полагаю что желательно придерживаться оригинальной классификации обновления, которую в своём примере я подчерпнул из файла Windows6.1-KB2647169-x86-pkgProperties.txt
  

• Vendor: Microsoft
  
• Product: Windows
  
• Article ID: 2647169

  Код статьи в базе знаний Microsoft
  

• Support URL: http://support.microsoft.com?kbid=2647169

  Ссылка на статью в базе знаний Microsoft. Ссылка так же взята из файла Windows6.1-KB2647169-x86-pkgProperties.txt
  

• Reboot Behavior: Never Reboots

  Режим требования перезагрузки после установки выбираем исходя из требований описанных в соответствующей статье базы знаний Microsoft
  

• Command Line:  %windir%system32pkgmgr.exe /quiet /n:Windows6.1-KB2647169-x86.xml
  
  Командная строка непосредственной установки обновления с ссылкой на файл настроек xml который должен быть в составе распакованных файлов в папке x86

На следующем шаге мастера Package Level – Installed Rules мы должны определить правила проверки которые нам дадут информацию о том, что данное обновление уже установлено и не требуется. Воспользуемся примером приведённым в онлайн-документации к LUP и создадим правило проверки наличия обновления с помощью нехитрого WMI запроса:

• Rule Type: WMI Query
  
• WMI Namecpase: rootcimv2
  
• Query: Select HotFixID from win32_quickfixengineering where HotFixID = 'KB2647169'

В нашем примере будет достаточно одного этого правила.

 

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

На следующем шаге Package Level – Installable Rules мы должны определить состав условий которые должны быть соблюдены для того, чтобы обновление могло успешно установиться. Опять же воспользуемся примером приведённым в онлайн-документации к LUP и создадим ряд правил:

• Processor Architecture: x86

  Так как в данном примере мы создаем пакет из файлов рассчитанных только на 32-битные системы.
  

• Windows Version: Windows 7 (c SP1 и без него) с типом Workstation

  Эти два условия объединённых в группу OR говорят о том что мы можем устанавливать это обновление только на определённую клиентскую версию ОС с первым пакетом обновлений или без него (опять же чётко согласно требованиям статьи базы знаний Microsoft по этому обновлению)
  

• File Version: Xpsprint.dll ниже версии 6.1.7601.21866

  Это дополнительное условие основано на информации публикуемой в статье базы знаний по обновлению, где расписано то, какие файлы меняются данным обновлением и до какой версии. В нашем примере информация в KB вы глядит так:

 

В общей сложности мы создали 4 условия в общей группе условий по умолчанию AND, при этом внутри этой группы два условия объединены в группу OR

 

Следующие два шага Installation Item Level – Superseded Rules и Installation Item Level – Rule Metadata в нашем примере мы можем пропустить оставив без изменений.

На финальном шаге жмакаем Finish и дожидаемся пока наше обновление опубликуется в WSUS 

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

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

В процессе управления одобрениями мы будем оперировать группами созданными на самом WSUS сервере. В нашем примере мы сделаем одобрение на тестовую группу компьютеров чтобы проверить корректность установки обновления.

 

После того как обновление одобрено переходим на испытуемые клиентские компьютеры и запускаем процедуру проверки установки обновления. Если мы все сделали правильно то обновление будет обнаружено и успешно установлено.

Сводную статусную информацию о ходе установки обновления на компьютерах мы сможем видеть также в консоли LUP на закладках Status и Report выбрав соответствующий пакет.

 

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

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

Возможно, инструмент, кратко рассмотренный в этой заметке, поможет вам быстро решить вопрос развёртывания необходимого хотфикса, особенно если у вас нет возможности использовать более функциональные и мощные коммерческие продукты, такие как SCCM а механизмы развёртывания через GPO или скрипты могут оказаться либо очень громоздкими либо иметь отсутствие информации о состоянии хода развертывания.

Более полную информацию о работе LUP на английском языке можно найти на странице веб-документации проекта, в частности в статье Local Update Publisher - Distributing Hotfixes and MSUs with LUP