Интеграция исправлений Windows в локальный WSUS с помощью Local Update Publisher

imageМожет возникнуть ситуация, когда есть потребность в установке исправления 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

image

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

image

После того как сертификат распространён, приступим непосредственно к процессу создания и интеграции обновления в 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 вызываем мастер создания обновления

image

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

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

image

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

  • 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

image

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

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

image

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

image

 

При создании нескольких правил помните что по умолчанию используется режим группирования 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 вы глядит так:

image

 

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

 

image

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

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

image

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

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

image

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

image

 

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

image

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

image

 

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

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

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

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

Всего комментариев: 12 Комментировать

  1. vicious /

    Отлично! Спасиббо. Давно соображал, как же это продукты третьих компаний обновлять через WSUS... я так полагаю, что всякие там адобе-ридеры тоже можно обновить через LUP?

    1. Алексей Максимов /

      Можно, по крайней мере на веб-узле проекта в онлайн-документации об этом написано и даже есть пример создания такого пакета.

  2. equinox (@equinoxnet) /

    Как всегда, четко, подробно и по делу. Отличная статья, спасибо!
    Про локализацию соглашусь: перевод надписи на кнопке "Закрыть" (Close) как "Близко" (одно из значений close, но в данном контексте неприменимое) сильно рассмешило!

  3. Обратная ссылка: Deploying third-party software using WSUS V3.x | Бизнес и IT /

  4. Сергей /

    Алексей, а Java с помощью LUP не пробовали обновлять? И еще, небольшой вопрос, у меня LUP работает, но каждый раз когда его запускаешь в логе WSUS появляется сообщение:

    "Не удается найти описание для идентификатора события 0 из источника WSusCertServer. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере.
    Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием.
    К событию были добавлены следующие сведения:
    Service started"

    1. Алексей Максимов /

      Нет. Не пробовал.

  5. Farid /

    Алексей, а как себя ведет LUP, если WSUS работает в режиме реплики? К примеру, есть один головной сервак и куча подчиненных, надо ли разворачивать LUP на каждом подчиненном или же можно управлять пакетами LUP-а с одной центральной консоли?

    1. Алексей Максимов /

      Насколько я помню, обновление я интегрировал в WSUS верхнего уровня и оно потом само реплицировалось на подчинённые сервера-реплики.

  6. Dmitriy /

    Добрый день.
    Спасибо за отличную статью! Сделал в точности по ней - работает на ура.

    Но вот в чем дело. Клиент устанавливает утвержденные обновления, все отлично, но после перезагрузки он их опять видит как "важные" и не установленные, и соответственно предлагает заново их установить.
    И так продолжается, пока я эти обновления не удалю из LUP.
    Тогда клиент говорит, что новых обновлений нет.

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

    1. Алексей Максимов / Автор записи

      Здравствуйте, Дмитрий.
      Я в своей практике использовал LUP всего для пары обновлений и подобных проблем не наблюдал.
      В вашем случае вариантов может быть несколько, ну например обновления по факту устанавливаются некорректно, ну допустим из-за неверной Comand Line; или же неверно составлены правила обнаружения обновления (Installed Rules). Как минимум надо изучить информациб, доступную в эвентлогах и логе клиента WSUS (WindowsUpdate.log). Более того, у pkgmgr есть ключ "-l" (включение логирования), - можно создать лог в процессе установки обновления и возможно этот лог даст больше информации для анализа ситуации.

  7. Сергей /

    Алексей, а чисто EXE-шники таким способом разворачивать можно?

    1. Алексей Максимов / Автор записи

      Я не пробовал, не было такой необходимости

Добавить комментарий