Інтеграція виправлень Windows у локальний WSUS за допомогою Local Update Publisher - Блог IT-KB

Може виникнути ситуація, коли є потреба в установці виправлення Windows (Hotfix ) недоступного черезWSUS на велику кількість комп'ютерів. Для автоматизації цієї задачі можна використовувати різні інструменти, такі якlogon -скрипти,GPO,SCCM. Розглянемо альтернативний метод поширення виправлення Windows за допомогою утилітиLocal Update Publisher на прикладі нещодавно випущеного оновлення, описаного в статті бази знань Microsoft -KB2647169 - Windows Fax and Scan 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 >CertificateInformation створимо самопідписаний сертифікат, який буде потрібно нам для підписання створюваного нами надалі пакета оновлення WSUS. У веб-документації проекту можна знайти інформацію про те, що замість самопідписаного сертифіката можна використовувати сертифікат, створений на основі локального довіреного ЦС, але мені так і не вдалося це зробити… можливо через те, щона своєму WSUS сервері я не використовую SSL, а може бути з якоїсь іншої причини... чесно кажучи, я сильно не заривався в цю тему. Тим більше я відразу зіткнувся з такою особливістю LUP, що при першому підключенні до сервера WSUS самопідписаний сертифікат створюється автоматично і змінити його надалі через UI неможливо, про що чесно написано в веб-документації. Оскільки підписаний сертифікат буде використовуватися для цифрового підписання створюваного оновлення, ми повинні поширити його на всі комп'ютери, що використовують WSUS, у тому числі і на сам сервер WSUS. Для цього експортуємо сертифікат через менюTools >Certificate Information >Export Certificate

локальний

Отриманий файл сертифіката ми можемо поширити на комп'ютери мережі, наприклад, за допомогоюGPO. Сертифікат повинен бути включений у два сховища –Trusted Root Certification Authorities таTrusted Publishers

wsus

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

Так як у своєму прикладі ми вирішили розглянути хотфікс описаний у статті KB2647169, завантажуємо за посиланням зазначеного в статті два відповідні файли файлу:

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

Розпаковуємо їх і отримуємо відповідно два файли Автономного інсталятора оновлень:

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

Розпаковуємо msu файли в різні підкаталоги. Зробити це можна як будь-яким архіватором наприклад7zip так і вбудованою у Windows утилітоюexpand

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

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. За допомогою кнопкиAdd Files додамо в пакет усі файли, які є в каталозіx86 за винятком самого файлу RunIt.exe

wsus

На наступному кроці майстра задамо основні налаштування пакета, а саме:

    Package Type :Update

Крім типу пакета Update в LUP є тип пакета Application, який дозволяє інтегрувати в WSUS навіть встановлення програм сторонніх виробників.

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

    З випадаючого списку можна вибрати інші значення класифікації. Але я вважаю, що бажано дотримуватися оригінальної класифікації оновлення,яку у своєму прикладі я підкреслив із файлу Windows6.1-KB2647169-x86-pkgProperties.txt

  • Vendor :Microsoft
  • Product :Windows
  • Article >2647169
  • Код статті в базі знань MicrosoftSupport URL :http://support.microsoft.com?kb >

    Посилання на статтю на базі знань Microsoft. Посилання також взяте з файлу Windows6.1-KB2647169-x86-pkgProperties.txtReboot Behavior :Never Reboots

    Режим вимоги перезавантаження після встановлення вибираємо виходячи з вимог, описаних у відповідній статті бази знань Microsoft

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

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

    • Rule Type :WMI Query
    • WMI Namecpase :rootcimv2
    • Query :Select HotFix

    інтеграція

    У нашому прикладі буде достатньо одного цього правила.

    виправлень

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

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

      Processor Architecture :x86

    Так як у даному прикладі ми створюємо пакет із файлів розрахованих лише на 32-бітові системи.Windows Version :Windows 7 (з 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

    локальний

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

    виправлень

    У процесі управління схваленнями ми оперуватимемо групами створеними на самому WSUS сервері. У прикладі ми зробимо схвалення на тестову групу комп'ютерів щоб перевірити коректність установки оновлення.

    інтеграція

    Після того як оновлення схвалено переходимо на випробувані клієнтські комп'ютери та запускаємо процедуру перевірки встановлення оновлення. Якщо ми все зробили правильно, то оновлення буде виявлено і успішно встановлено.

    windows

    Зведену статусну інформацію про хід встановлення оновлення на комп'ютерах ми зможемо бачити також у консолі LUP на закладкахStatus таReport, вибравши відповідний пакет.

    виправлень

    У цьому прикладі ми розглянули створення та розповсюдження пакета для 32-бітових систем. За аналогією можна створити пакет для 64-бітових систем з файлів, які ми на початку нотатки розпакували в каталогx64.

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

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

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