Local update publisher на windows server 2016

Обновлено 03.08.2016

Для начала необходимо со страницы загрузки скачать дистрибутив Local Update Publisher.msi. Его необходимо установить на машине, на которой установлен WSUS SP2+ или хотя бы его консоль управления. После установки, надо запустить LUP от имени пользователя, входящего в группу Администраторы WSUS. При первом подключении появится диалог выбора сервера:

Вводим имя и хостнейм, подключаемся по SSL, если у нас SSL настроен для WSUS’а, иначе без него. В первую очередь необходимо создать самоподписанный сертификат в меню Инструменты -> Информация о сертификате.

Тут, к сожалению, есть особенность, что данный сертификат нельзя потом заменить. Сертификат будет использоваться для подписывания всех опубликованных обновлений, а потому его необходимо распространить на все компьютеры, включая сам сервер WSUS. Для этого надо его экспортировать через Инструменты -> Информация о сертификате -> Экспорт.

Экспортированный сертификат можно распространить на все компьютеры групповыми политиками. Сертификат должен быть включен в два хранилища — Доверенные корневые центры сертификации и Доверенные издатели.

Также, необходимо в групповой политике, указывающей клиентам на WSUS-сервер, выставить в Конфигурация компьютера -> Политики -> Административные шаблоны -> Центр обновлений Windows параметр Разрешить прием обновлений с подписью из службы обновления Майкрософт в интрасети в Включено.

Когда сертификат распространился, приступим непосредственно к созданию пакета обновления. Для примера будем распространять сам LUP. Выбираем в меню Инструменты -> Создать обновление. В появившемся окне нажимаем на обзор и выбираем Local Update Publisher.msi.

На следующем шаге выбираем тип обновления — Application, пишем название пакета и описание. Обязательно записываем вендора и название продукта, новые версии продукта будут складываться туда же. Остальное опционально. Тут же можно задать зависимости от других пакетов (нам это не нужно в данном случае) и какие пакеты это обновление заменяет (понадобится при разворачивании новой версии).

На следующем шаге надо задать правила, по которым будет понятно, что пакет уже установился и больше его ставить не надо. Для MSI-пакетов LUP всегда создаёт правило, основанное на версии установленного MSI-пакета. В данном случае этого достаточно.

На этом шаге необходимо задать правила, по которым будет понятно, необходим ли данный неустановленный пакет, можно ли его вообще установить на данной системе. Для MSI-пакетов LUP всегда создаёт правило с отрицанием, основанное на версии установленного MSI-пакета. Т.е. установить можно, если не было уже установлено. Нам этого достаточно.

На следующих шагах позволяется вручную отредактировать различные xml-файлы, но это не требуется и можно жать «далее» до самого конца и получения окошка с сообщением, что пакет удалось создать. В дереве пакетов должен появиться вендор и продукт, заданные в пакете. Если нажать на продукт, то будет видно созданный пакет. Т.к. созданные пакеты не отображаются в обычной консоли управления WSUS, то их нужно одобрить в LUP. Для этого надо жмакнуть правой кнопкой на пакете и выбрать «Одобрить».

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

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

Если клиентский компьютер был только что перемещен в эту группу, то он может долго кешировать принадлежность к группам и не находить обновлений. Форсировать можно при помощи команды wuauclt /resetauthorization /detectnow на клиенте.

С некоторым запозданием, как и с обычными обновлениями, клиенты сообщают статус установки пакетов в WSUS и их можно посмотреть на вкладке «Статус».

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

Вот так вот просто распространить программу при помощи WSUS и Local Update Publisher.

Материал сайта pyatilistnik.org

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

Как добавить не-Microsoft обновления в WSUS

WSUS (Windows Server Update Services) — это сервер обновлений операционных систем, серверных и прикладных программ. Он позволяет поддерживать продукты Microsoft в актуальном состоянии. Подробнее об этом полезном инструменты можно узнать на странице в Technet.

Кроме программ Microsoft, системные администраторы должны позаботиться и о продуктах других фирм. Большинство популярных, а поэтому потенциально уязвимых программ, таких как Adobe Flash, Adobe Reader, Mozilla Firefox, Google Chrome, умеют обновляться самостоятельно, но часто установщики требуют повышенных привилегий и у пользователя есть возможность их отключить.

Существует возможность централизовать установку сторонних обновлений через WSUS. Для этого можно воспользоваться одной из бесплатных программ, которые умеют работать с сервером обновлений через API:

— Local Update Publisher (перейти на сайт)
— WSUS Package Publisher (перейти на сайт)

Программы делают одно и тоже. На момент написания статьи чуть больше мог WSUS Package Publisher, поэтому…

Установка и настройка WSUS Package Publisher (WPP)

Требования

— В локальной сети должен быть развернут WSUS
— Установленный .Net Framework 4.0
— Для WSUS 3.0 SP2 должно быть установлено обновление KB2530678

Wsus Package Publisher можно устанавливать как на сервер WSUS, так и на рабочую станцию. В последнем случае на компьютере должна быть установлена административная консоль WSUS. Также пользователь должен быть локальным администратором и входить в группу «Wsus Administrators» на сервере. На компьютере под управлением Windows 8 должны быть установлены Remote Server Administration Tools (RSAT).

Установка

Скачиваем архив WPP с сайта и извлекаем файлы в папку.

Добавление сервера

Запускаем Wsus Package Publisher.exe. Если WPP находится на сервере WSUS, то он автоматически добавит локальный компьютер в список, в противном случае настраиваем самостоятельно:

— В меню Tools выбираем Settings

— Задаем параметры подключения (поля Server Name, Connection Port, Use SSL)
— Если WPP запущен на сервере WSUS, отмечаем галочку Connect to local server
— Нажимаем Add Server
— При необходимости добавляем другие сервера

В строке меню выбираем нужный сервер, нажимаем кнопку Connect/Reload

Настройка сертификата

Далее нужно настроить сертификат, которым будут подписаны пакеты для распространения через WSUS. В меню Tools открываем пункт Certificate

Здесь можно либо выпустить самоподписанный сертификат (кнопка Generate the certificate), либо загрузить свой, например, выпущенный локальным центром сертификации. Кнопка Load a certificate активируется после ввода пароля от файла с закрытым ключом в поле Password

Замечание: WSUS сервер на Windows Server 2012 R2 (и более поздних) больше не выпускает самоподписанные сертификаты. WPP может может сгенерировать его самостоятельно, но для этого он должен быть запущен на сервере WSUS.

Сохраняем сертификат (Save the certificate), чтобы затем распространить его на клиентские компьютеры.

Перезагружаем сервер WSUS. Достаточно перезапустить службы iis и wsusservice

iisreset /stop
net stop wsusservice && net start wsusservice
iisreset /start

Проверить, что сертификат был установлен правильно, можно через mmc оснастку «Сертификаты» для локального компьютера. Здесь нужно убедиться в его наличии в контейнерах «WSUS», «Доверенные издатели» («Trusted Publishers») и (для самоподписанного сертификата) в «Доверенные корневые центры сертификации» («Trusted Root Certificates Authorites»).

Важно: При замене сертификата нужно будет переподписать все опубликованные обновления.

Настройка клиентских компьютеров

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

Сертификаты

Если сертификат был сгенерирован WSUS или WPP (WSUS self-signed certificate), то его нужно поместить в контейнеры «Доверенные издатели» («Trusted Publishers») и в «Доверенные корневые центры сертификации» («Trusted Root Certificates Authorites») на локальном компьютере. Если сертификат был выпущен, например, доменным центром сертификации, то достаточно добавить его в папку «Доверенные издатели». При этом сертификат выпускающего центра должен находиться в «Доверенных корневых центрах сертификации».

Для компьютеров, которые входят в домен, сертификат можно распространить через групповую политику, добавив его в соответствующие узлы раздела Конфигурация компьютера Политики Конфигурация Windows Параметры безопасности Политики открытого ключа

Включение локальных обновлений

Для компьютеров, входящих в домен, нужно включить параметр групповой политики «Разрешить прием обновлений с подписью из службы обновления Майкрософт в интрасети» («Allow signed content from intranet Microsoft update service location»), который находится в разделе Конфигурация компьютера Политики Административные шаблоны Компоненты Windows Центр обновления Windows

Для компьютеров из рабочей группы нужно установить параметр в реестре HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAcceptTrustedPublisherCerts = 1

Если все сделано правильно, то клиентские компьютеры смогут принимать сторонние обновления, в противном случае появится ошибка Windows Update 800B0109.

Примеры

— Установка Firefox через WSUS

В соответствии с отчетами компаний, работающих на рынке информационной безопасности, Secunia, Symantec и McAfee, в первом квартале 2010 года больше всего уязвимых мест обнаружено в приложениях независимых поставщиков, даже больше, чем в операционной системе. Компания Microsoft предоставляет службы Windows Server Update Services (WSUS) в качестве бесплатного компонента Windows Server для обновления сторонних прикладных программ; аналогичное средство для пользователей — служба Windows Update. Но у небольших компаний, не имеющих доступа к системам управления корпоративного класса, нет простого способа обновлять сторонние приложения, установленные на компьютерах Windows.

У многих распространенных программ, таких как Adobe Macromedia Flash Player и Google Chrome, есть собственные механизмы обновления, однако для них действует ряд ограничений. Например, сторонний механизм обновления может оказаться неспособным к принудительному обновлению или непригодным для централизованного управления. Кроме того, часто их пользователям требуются расширенные права.

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

WSUS или GPSI

В Active Directory (AD) предусмотрен механизм установки программ с использованием групповой политики (GPSI), предоставляющий администраторам элементарные средства для обновления и развертывания программ на клиентских компьютерах с применением файлов Windows Installer (.msi). Но GPSI не рассчитан на крупные сети, а компания Microsoft не развивала технологию в течение 10 лет, прошедших со времени выпуска AD.

Начиная с версии 3.0 службы WSUS располагают локальными API-интерфейсами публикации, которые впервые обеспечивают разработчикам возможность строить программы для публикации специальных обновлений в службах WSUS. Однако бесплатный инструментарий Microsoft для внедрения этих API-интерфейсов отсутствует, хотя методы локальной публикации доступны из сценариев Visual Basic и других языков программирования. Дополнительные сведения об инструментах локальной публикации приведены во врезке «Издатель обновлений System Center и каталоги партнеров служб обновления Windows Server». Несмотря на это, использование WSUS для развертывания сторонних программ и обновлений имеет много преимуществ перед GPSI, в том числе:

• наряду с пакетами. msi можно развертывать исполняемые файлы командной строки и драйверы, не назначая пользователям административных полномочий;
• служба Background Intelligent Transfer Service (BITS) обеспечивает передачу файлов установки клиентам во время простоев канала связи — идеальное решение для медленных сетей;
• службы WSUS проектировались как часть распределенной архитектуры крупной компании;
• в службах WSUS предусмотрены простые функции подготовки отчетов.

Локальные публикации WSUS

. Прежде чем выполнить процедуры, установите WSUS с настройками по умолчанию с помощью мастера Server Manager.

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

1. Зарегистрируйтесь на сервере Server 2008 R2 в качестве администратора домена.
2. Откройте оснастку Windows Server Update Services консоли управления Microsoft (MMC) из раздела Administrative Tools меню Start.
3. В панели навигации разверните сервер WSUS и нажмите кнопку Options.
4. В области Options прокрутите вниз список параметров настройки и щелкните Computers.
5. В диалоговом окне Computers установите флажок Computers и нажмите кнопку OK.
6. В области навигации разверните узел Computer, щелкните правой кнопкой мыши All Computers и выберите пункт Add Computer Group.
7. В диалоговом окне Add Computer Group дайте новой группе имя Local Updates и нажмите кнопку OK.

Настройка локальной политики компьютера для Windows Update. В производственной среде следующие параметры будут настроены в объекте групповой политики (GPO) и привязаны к организационной единице (OU), содержащей компьютеры, обновляемые с использованием WSUS. Ради простоты подготовим локальную политику компьютера для настройки Windows Update только на локальном компьютере.

1. Щелкните Start, введите MMC в поле поиска и нажмите клавишу Enter.
2. В новом окне консоли нажмите клавиши Ctrl+M, чтобы добавить новую оснастку.
3. В окне Add or Remove Snap-ins выберите редактор объектов групповой политики под элементом Available snap-ins и нажмите кнопку Add.
4. В диалоговом окне Select Group Policy Object подтвердите выбор по умолчанию (Local Computer) и нажмите кнопку Finish.
5. В окне Add or Remove Snap-ins нажмите OK.
6. На панели навигации MMC разверните Local Computer Policy, Computer Configuration, Administrative Templates, Windows Components. Дважды щелкните Windows Update.
7. На центральной панели дважды щелкните Configure Automatic Updates.
8. В окне Configure Automatic Updates выберите Enabled, а затем нажмите кнопку OK.
9. На центральной панели дважды щелкните Specify intranet Microsoft update service location, а затем Enabled.
10. В разделе Options в обоих полях введите http://, а следом имя локального сервера WSUS. Затем нажмите кнопку OK. В этом примере имя сервера WSUS — WINMEM1 и все службы находятся на одном сервере. Поэтому вводится http://winmem1 как для Set the intranet update service for detecting updates, так и для Set the intranet statistics server.
11. На центральной панели дважды щелкните Enable client-side targeting.
12. В окне Enable client-side targeting щелкните Enable. В поле Target group name for this computer введите Local Updates. Нажмите кнопку OK.
13. Дважды щелкните Allow signed updates from an intranet Microsoft update service location, щелкните Enable и нажмите кнопку OK.
14. Закройте оснастку MMC.
15. Откройте окно командной строки и запустите команду gpupdate/force, чтобы немедленно применить новые настройки к серверу.

Установка Local Update Publisher. Local Update Publisher — открытый инструмент, бесплатно загружаемый с сайта SourceForge по адресу sourceforge.net/projects/localupdatepubl. Единственное обязательное условие для запуска программы Local Update Publisher — наличие платформы. NET Framework 3.5, которую можно установить с использованием Server Manager on Server 2008 R2. Это можно сделать быстро, открыв окно PowerShell и выполнив следующие команды:

import-module servermanager
add-windowsfeature net-framework

После установки. NET Framework запустите инструмент Local Update Publisher на сервере WSUS. Затем выполните следующие действия.

1. Запустите инструмент Local Update Publisher из меню Start в разделе All Programs. Появится приглашение подключиться к серверу WSUS. Сервер WSUS — локальный, поэтому можно оставить поле Name пустым и нажать кнопку Connect.
2. В окне программы Local Update Publisher щелкните LOCALHOST в разделе Update Services.
3. Появится окно No WSUS Certificate found; нажмите в нем кнопку Yes.
4. В диалоговом окне Certificate Information щелкните Create Certificate. Откроется второе окно, указывающее, что самозаверяющий сертификат успешно подготовлен и должен быть установлен на всех локально обновляемых клиентах.
5. В окне подтверждения установки нажмите кнопку OK.
6. В диалоговом окне Certificate Information щелкните Export Cert, затем сохраните копию сертификата на компьютере.
7. Нажмите кнопку OK.

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

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

1. Нажмите кнопку Start, введите MMC в поле поиска и нажмите клавишу Enter.
2. В новом окне консоли нажмите комбинацию клавиш CTRL+M, чтобы добавить новую оснастку.
3. В диалоговом окне Add or Remove Snap-ins выберите Certificates в разделе Available snap-ins и нажмите кнопку Add.
4. В диалоговом окне Certificates snap-in выберите учетную запись Computer и нажмите Next.
5. Подтвердите выбор Local Computer, сделанный по умолчанию, и нажмите Finish.
6. В диалоговом окне Add or Remove Snap-ins нажмите кнопку OK.
7. На панели навигации MMC разверните Certificates (Local Computer), а затем узел Trusted Root Certification Authorities.
8. Щелкните правой кнопкой мыши Certificates, выберите пункт All Tasks и щелкните Import.
9. В мастере Certificate Import нажмите кнопку Next.
10. На странице File to Import нажмите Browse.
11. Выберите файл сертификата, сохраненный на компьютере, и нажмите кнопку Next.
12. На странице Certificate Store подтвердите настройки, выбранные по умолчанию, и нажмите кнопку Next.
13. Нажмите Finish.

По завершении импорта нажмите кнопку OK в поле оповещения. На центральной панели окна MMC отображается самозаверяющий сертификат WSUS Publishers. Повторите шаги с 7 по 13 для импорта того же сертификата в контейнер Trusted Publishers. Затем оснастку MMC Certificates можно закрыть.

Подготовка локального обновления. Для этого необходимо работать с файлом Windows Installer, так как инструмент Local Update Publisher автоматически строит правила для применения обновлений через WSUS. Если требуется использовать файл exe и если не удается извлечь из него пакет Windows Installer, необходимо изучить основные правила публикации обновлений System Center. Дополнительные сведения об этих правилах можно найти по адресу technet.microsoft.com/en-us/library/bb531004.aspx.

Чтобы установить новейшую версию Flash Player через WSUS, в первую очередь загрузите файл Flash Player Windows Installer из адреса fpdownload.macromedia.com/get/flashplayer/current/licensing/win/install_flash_player_10_active_x.msi. Затем выполните следующие шаги для создания локального обновления.

1. В меню Tools щелкните Create Update.
2. В окне Import Update from File, показанном на экране 1, нажмите кнопку Browse. Затем выберите ранее загруженный msi-файл Flash Player. Все файлы упакованы в установщике Flash Player MSI.
3. Нажмите кнопку Next. На следующей странице, показанной на экране 2, уже содержится вся необходимая информация, за исключением сведений о поставщике и продукте.
4. В поле Vendor введите Adobe. В поле Product укажите Flash Player 10.1.85.3 или нужную версию программы.
5. Нажмите кнопку Next. При подготовке обновления вместе c msi-файлом применяется Local Update Publisher, поэтому правила автоматически заполняются на нескольких следующих страницах мастера установки. Впоследствии правила можно изменять или дополнять.
6. На странице Package Level — Installed Rules, показанной на экране 3, нажмите кнопку Next, чтобы принять правила по умолчанию.
7. Повторите шаг 6 на следующих страницах: Package Level — Installable Rules, Installation Item Level — Superseded Rules и Installation Item Level — Rule Metadata.
8. Просмотрите XML-информацию для обновления, затем нажмите кнопку Finish.

Экран 1. Импорт файла Windows Installer на сервер WSUS

Экран 2. Ввод сведений о программном пакете

Экран 3. Назначение правил установки

Спустя несколько секунд на экране должно появиться извещение об успешной публикации обновления во WSUS.

Утверждение локального обновления. Один из недостатков локальных обновлений заключается в том, что не отображается административная консоль WSUS; управлять обновлениями приходится каким-нибудь другим способом. Управлять и утверждать локальные обновления можно с помощью инструмента Local Update Publisher.

1. В Local Update Publisher разверните LOCALHOST, Updates, Adobe, Flash Player 10.1.85.3.
2. В области сведений щелкните правой кнопкой мыши на обновлении и нажмите кнопку Approve.
3. В диалоговом окне Approve Update (экран 4) щелкните No Approval справа от группы Local Updates, а затем Approved for Install.
4. В нижней части диалогового окна Approve Update нажмите кнопку Approve.
5. В ответ на запрос подтверждения нажмите OK.
6. Нажмите кнопку Close.

Экран 4. Подтверждение локальных обновлений

Проверка установки. Последний шаг — убедиться, что клиент Windows Update установил локальное обновление.

1. На сервере WSUS щелкните Start, введите Windows Update в поле поиска и нажмите клавишу Enter.
2. В результатах поиска щелкните Check for updates.
3. В разделе Windows Update панели управления вновь щелкните Check for updates (слева).
4. Приблизительно через одну минуту должен появиться элемент для установки важного обновления.
5. Щелкнув 1 important update is available, проверьте имя обновления. Это должно быть только что опубликованное локальное обновление.
6. Проверив обновление, щелкните Install updates для установки Flash Player.

В программе Local Update Publisher предусмотрены основные функции подготовки отчетов, с помощью которых можно увидеть, какие компьютеры в группе успешно получили обновления. В производственной среде нет причин устанавливать Flash Player непосредственно на сервере WSUS.

Отключение автоматических обновлений Flash Player. По умолчанию Flash Player проверяет наличие новых версий через каждые 30 дней. В корпоративной среде полезно отключить эту функцию и централизованно управлять обновлениями через WSUS. С помощью бесплатного инструмента, такого как Microsoft Orca, в базу данных MSI можно внести необходимый файл конфигурации. Однако эта процедура довольно сложна для пользователей, не имеющих опыта подготовки пакетов Windows Installer. Более простой вариант — создать файл конфигурации (mms.cfg) для отключения функции автоматического обновления. Процесс описан в статье «IT Administration: Configure Flash Player auto-update notification» по адресу kb2.adobe.com/cps/167/16701594.html. Затем следует использовать параметры групповой политики, чтобы скопировать файл в подходящее место на клиентских компьютерах.

Не отдавайте обновления на волю случая

В одном лишь обновлении для Adobe Acrobat Reader, выпущенном 10 октября 2010 года, заделано 23 лазейки в системе безопасности, через которые злоумышленник мог запустить вредные программы. Поэтому своевременное обновление широко распространенных программ нельзя оставлять на волю случая. Часто системные администраторы надеются, что пользователи будут применять обновления самостоятельно. Однако для локальных обновлений обычно требуются административные полномочия, предоставление которых увеличивает вероятность заражения.

Использование WSUS для публикации сторонних обновлений или даже собственных обновлений пользователя поможет существенно снизить вероятность заражения компьютера. Благодаря регулировке полосы пропускания в медленных сетях и возможности (при наличии соответствующей архитектуры) обслуживать ноутбуки, не всегда подключенные к корпоративной сети, WSUS — оптимальное решение для пересылки обновлений на все компьютеры компании.

Если нежелательно использовать бесплатные открытые программы для публикации обновлений на сервере WSUS, можно воспользоваться сценариями или подготовить собственное приложение. Кроме того, компания EminentWare (www.eminentware.com) предоставляет два коммерческих решения: WSUS Extension Pack для публикации локальных обновлений через WSUS и 3rd Party Updates Pack с непрерывно обновляемыми и проверяемыми каталогами сторонних приложений.

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами

Далее будет рассмотрен подробнейшим образом процесс подготовки всех компонентов системы для централизованного распространения обновлений. Разработал и протестировал данный метод, а также написал эту инструкцию мой коллега, за что ему огромное спасибо.

PDF-версия Local Update Publisher

1.     Подготовка к установке

Подразумевается, что WSUS уже настроен и функционирует.

Внесем дополнительные изменения в настройки Windows Update, создав новый GPO или отредактировав уже существующий:

Конфигурация компьютера Политики Административные шаблоны Компоненты Windows

Центр обновления Windows

«Разрешить прием обновлений с подписью из службы обновления Майкрософт в интрасети

(Allow signed updates from an intranet Microsoft update service location)» – ENABLED

Проверяем, что на сервере WSUS, где будет развернут Local Update Publisher, установлен компонент .NET Framework 3.5. Если не установлен, то можно быстро развернуть с помощью Powershell:

import-module servermanager

add-windowsfeature net-framework

2.     Установка Local Update Publisher

Local Update Publisher — открытый инструмент, бесплатно загружаемый с сайта SourceForge по адресу sourceforge.net/projects/localupdatepubl ( http://sourceforge.net/projects/localupdatepubl ).

После установки программы на сервер WSUS выполните следующие действия:

• Запустите инструмент Local Update Publisher из меню Start в разделе All Programs. Появится приглашение подключиться к серверу WSUS. Сервер WSUS — локальный, поэтому можно оставить поле Name пустым и нажать кнопку Connect.
• В окне программы Local Update Publisher щелкните LOCALHOST в разделе Update Services.
• Появится окно No WSUS Certificate found; нажмите в нем кнопку Yes.
• В диалоговом окне Certificate Information щелкните Create Certificate. Откроется второе окно, указывающее, что самозаверяющий сертификат успешно подготовлен и должен быть установлен на всех локально обновляемых клиентах.
• В окне подтверждения установки нажмите кнопку OK.
• В диалоговом окне Certificate Information щелкните Export Cert, затем сохраните копию сертификата на компьютере. — Нажмите кнопку OK.

В производственной среде лучше использовать сертификат, изданный удостоверяющим центром (CA), который является частью инфраструктуры открытых ключей PKI компании.

Теперь необходимо установить самозаверяющий сертификат на сервере WSUS в «Доверенные корневые центры сертификации» (Trusted Root Certification Authorities) и «Доверенные издатели» (Trusted Publishers).

Для компьютеров, которые входят в домен, сертификат можно распространить через групповую политику, добавив его в соответствующие узлы:

Конфигурация компьютера Политики Конфигурация Windows Параметры безопасности Политики открытого ключа Доверенные корневые центры сертификации

Конфигурация компьютера Политики Конфигурация Windows Параметры безопасности

Политики открытого ключа Доверенные издатели

Если сертификат был выпущен доменным центром сертификации, то достаточно добавить его в «Доверенные издатели». При этом сертификат выпускающего центра должен находиться в «Доверенных корневых центрах сертификации».

Для компьютеров из рабочей группы нужно установить параметр в реестре

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAcceptTrustedPublisherCerts = 1

Если все сделано правильно, то клиентские компьютеры смогут принимать сторонние обновления, в противном случае появится ошибка Windows Update 800B0109.

3.     Создание пакета установки

3.1.          Adobe Flash Player

В первую очередь загрузите файл Flash Player Windows Installer из: http://www.adobe.com/products/flashplayer/distribution3.html

Затем выполните следующие шаги для создания локального обновления в Local Update Publisher:

• В меню Tools щелкните Create Update.
• В окне Import Update from File нажмите кнопку Затем выберите ранее загруженный msi-файл Flash Player. Все файлы упакованы в установщике Flash Player MSI.

• Нажмите кнопку Next. На следующей странице уже содержится вся необходимая информация, за исключением сведений о поставщике и продукте.

• В поле Vendor введите Adobe Systems, Inc.. В поле Product укажите Adobe Flash Player
• Нажмите кнопку Next. При подготовке обновления вместе c msi-файлом применяется Local Update Publisher, поэтому правила автоматически заполняются на нескольких следующих страницах мастера установки. Впоследствии правила можно изменять или дополнять.
• На странице Package Level — Installed Rules нажмите кнопку Next, чтобы принять правила по умолчанию.

• Нажмите кнопку Next на следующих страницах: Package Level — Installable Rules, Installation Item Level — Superseded Rules и Installation Item Level — Rule Metadata.
• Просмотрите XML-информацию для обновления, затем нажмите кнопку Finish.

Спустя несколько секунд на экране должно появиться извещение об успешной публикации обновления во WSUS.

Один из недостатков локальных обновлений заключается в том, что они не отображаются в административной консоли WSUS. Управлять и утверждать локальные обновления приходится с помощью инструмента Local Update Publisher:

• В Local Update Publisher разверните LOCALHOST, Updates, Adobe Systems, Inc., Adobe Flash Player.
• В области сведений щелкните правой кнопкой мыши на обновлении и нажмите кнопку Approve.

• В диалоговом окне Approve Update щелкните No Approval справа от группы Local Updates, а затем Approved for Install.
• В нижней части диалогового окна Approve Update нажмите кнопку Approve.
• В ответ на запрос подтверждения нажмите OK.
• Нажмите кнопку Close.

Отключение автоматических обновлений Adobe Flash Player. По умолчанию Flash Player проверяет наличие новых версий через каждые 30 дней. В корпоративной среде полезно отключить эту функцию и централизованно управлять обновлениями через WSUS. С помощью бесплатного инструмента, такого как Microsoft Orca, в базу данных MSI можно внести необходимый файл конфигурации.

В программе Local Update Publisher предусмотрены основные функции подготовки отчетов, с помощью которых можно увидеть, какие компьютеры в группе успешно получили обновления.

Загружаем Adobe Customization Wizard (для каждой версии Adobe Reader мастер свой):  ftp://ftp.adobe.com/pub/adobe/acrobat/win/11.x/11.0.00/misc/

Загружаем EXE дистрибутив Adobe Reader требуемой локализации:  ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.00/

Распаковываем EXE с помощью архиватора (например, 7-Zip или WinRAR).

Запускаем Adobe Customization Wizard и открываем в нем AcroRead.msi, получившийся в результате распаковки EXE.

Далее вносим следующие изменения:

• в разделе Personalization Options выбрать пункт Suppress display of EULA:

• в разделе Installation Options отметить пункты Installer will choose which product will be the default, Remove all version of Reader, Enable Optimization, Enable Caching of installer files, Silent Installation и Suppress reboot.

• в разделе Registry перейти к HKLMMicrosoftWindowsCurrentVersionRun. Правым кликом по параметру вызвать контекстное меню и выбрать Modify

• выбрать Remove Value

• в разделе Security в параметре Protected view выбрать All files

• в разделе Online and Adobe online services Features отключитьвсефункции

• в разделе Direct Editor выбрать таблицу InstallExecuteSequence. Далее выбирая параметры

CreateShortcut, InstallService и StartService, нажать правым кликом и выбрать из контекстного меню Drop Rows

• выбираем пункт File и нажимаем Save Package

• открываем AcroRead.msi с помощью Microsoft Orca и из таблицы Property копируем значение параметра ProductCode. Оно пригодится позже.

Затем выполните следующие шаги для создания локального обновления в Local Update Publisher:

• В меню Tools щелкните Create Update.
• В окне Import Update from File нажмите кнопку Затем выберите Setup.exe из ранее распакованного инсталлятора
• С помощью кнопки Add Files добавьте остальные файлы из распакованного инсталлятора

• Нажмите кнопку Next. На следующей странице уже содержится вся необходимая информация, за исключением сведений о поставщике и продукте.
• В поле Vendor введите Adobe Systems, Inc.. В поле Product укажите Adobe Reader

• На странице Package Level — Installed Rules нажмите кнопку Add Rule. В списке Rule Type выберите MSI Product Installed, в поле Product Code необходимо вписать значение параметра ProductCode, которое получили (см. выше) с помощью Microsoft Orca (значение вписать без фигурных скобок!)

• Нажмите кнопку Add Rule, затем Next. На странице Package Level — Installable Rules нажмите кнопку Add Rule. В списке Rule Type выберите MSI Product Installed, в поле Product Code необходимо вписать значение параметра ProductCode, которое получили (см. выше) с помощью Microsoft Orca (значение вписать без фигурных скобок!). Поставить галочку около Negation Rule

• Далее нажимаем несколько раз Next, затем Finish. Обновление подготовлено.
• Дальнейшее управление и утверждение локального обновления аналогично описанному в п. 3.1.

3.3.          Обновление для Adobe Reader

Скачайте файл MSP: ftp://ftp.adobe.com/pub/adobe/reader/win/

Затем выполните следующие шаги для создания локального обновления в Local Update Publisher:

• В меню Tools щелкните Create Update.
• В окне Import Update from File нажмите кнопку Browse и выберите скачанный файл MSP.
• Нажмите кнопку Next. В поле Vendor введите Adobe Systems, Inc.. В поле Product укажите Adobe Reader (содержимое этих полей должно совпадать с ранее созданным Adobe Reader. Совпадение ВАЖНО для группировки обновлений по производителю и продукту).
• На остальных экранах мастера публикации нажмите Next и Finish, т.к. файл MSP уже содержит свой набор правил.

Может сложиться ситуация, когда  кроме самого Adobe Reader уже были опубликованы файлы MSP (более ранние по сравнению с подготовленным сейчас). В этом случае, убедившись, что подготовленное сейчас обновление включает все изменения из предыдущих файлов MSP, необходимо выполнить следующее:

• нажать правой кнопкой на подготовленном сейчас обновлении и выбрать Revise

• в открывшемся окне нажмите Supersedes, затем Add, далее в списке Vendor выберите производителя Adobe Systems, Inc.. После этого выделите обновления, которые будут заменяться подготовленным сейчас и нажмите Select

• На остальных экранах мастера нажмите Next и Finish.
• В окне списка опубликованных обновлений статус замененных обновлений изменится на Superseded

• Дальнейшее управление и утверждение локального обновления аналогично описанному в п. 3.1.

3.4.          Java

В первую очередь скачиваем автономный установщик: https://www.java.com/ru/download/manual.jsp

Чтобы добыть пакет MSI, необходимо установить Java с помощью автономного установщика.

После успешной установки MSI можно найти здесь:

<User profile, who install Java>AppDataLocalLowSunJavajre<номер версии><здесь будет лежать msi> Этот MSI уже пригоден для распространения через Local Update Publisher.

Однако будет правильнее внести некоторые изменения. Например, отключить функцию проверки наличия обновления:

• в Microsoft Orca открываем MSI
• выбираем Transform, затем New Transform
• выбираем таблицу Property

• редактируем следующие свойства:

AUTOUPDATECHECK=0 (отключает добавление в автозагрузку планировщика обновлений JRE, т.е.

радикально отключает автообновление)

JAVAUPDATE=0 (отключает обновление, но не отключает предложение включить автообновление во время первого запуска, так же не отключает вкладку Update в Java Control Panel)

SYSTRAY=0 (отключает уведомление в трее о необходимости обновления)

• Сохраняем модификацию: Transform, затем Generate Transform…

Теперь можно публиковать обновление в Local Update Publisher:

• В поле Vendor введите Oracle. В поле Product укажите Java.
• Поскольку MSI уже содержит все необходимые правила установки, то можно просто нажать Next в остальных окнах мастера. Однако можно добавить и свои правила, воспользовавшись, например, фильтрами WMI:

В примере выше обновление будет установлено только на ПК под управлением 64-bit ОС, в которых проинсталлирована Java 32-bit или Java 64-bit:

WMI Namespace: rootcimv2

Query: SELECT * FROM Win32_Processor WHERE AddressWidth = «64»

WMI Namespace: rootcimv2

Query: Select * From win32_Directory where name=»c:\Program Files\Java»

WMI Namespace: rootcimv2

Query: Select * From win32_Directory where name=»c:\Program Files (x86)\Java»

Замечания по распространению обновлений Java:

1. Производитель заявляет, что:

начиная с Java 8 обновление 20 (8u20), на системах Windows инструмент удаления Java Uninstall Tool интегрируется с программой установки. Это позволяет удалять устаревшие версии Java из системы. Данное изменение применимо к 32- и 64-разрядным платформам Windows.

Однако Java Uninstall Tool отрабатывает только при установке руками и не запускается при распространении через Local Update Publisher.

В связи с чем необходимо будет выполнить отзыв предыдущего обновления во время распространения нового:

• нажать правой кнопкой на отзываемом обновлении и выбрать Approve

• в открывшемся окне напротив целевой группы WSUS в столбце Approval щелкнуть левой кнопкой мыши и выбрать Approve for Removal

• данная процедура позволит произвести деинсталляцию пакета обновления средствами WSUS.