Файлы экспресс установки wsus

Обновлено: 04.07.2024

До недавнего времени я работал эникейщиком в крупной российской компании, имеющей множество офисов по всей стране. В моём ведении были одиннадцать площадок, находящихся в разных городах Дальнего востока (это важно). В каждом из этих офисов была своя, не связанная с другими, сетевая инфраструктура — свой домен AD, своя подсеть и т.д.

Однажды руководство поставило мне задачу организовать процесс автоматического обновления ОС и программ от MS и разрешило развернуть на подотчётных площадках WSUS.

Проблема

После того, как WSUS был развернут, политики привязки компьютеров к группам WSUS настроены, синхронизация каталогов содержимого с серверами MS проведена и т.п., возник вопрос: а кто же, и, главное, как, будет одобрять обновления?

Зачем изобретать велосипед

Читатель, имеющий опыт работы со WSUS, наверняка, спросит: а в чем же, собственно, проблема? В Microsoft всё предусмотрели: существует механизм репликации, при котором «нижестоящий» (подчиненный) сервер, называемый «репликой», скачивает как сами файлы обновлений, так и информацию о том, какие апдейты были одобрены для использования в тех или иных группах.

Действительно, это так. Однако в рассматриваемом случае использовать штатный механизм не получилось, т.к. для его работы требуется достаточно широкий канал между корневым сервером и его репликами. У меня такого канала не было. Зато было указание — ни при каких обстоятельствах не увеличивать расходы на ИТ.

«Нет, так нет!» — подумал я и начал прикидывать, как можно выкрутиться из этой ситуации. Во-первых, каждый из серверов WSUS так или иначе имел доступ либо к серверам WindowsUpdate от MS, либо к локальным серверам WSUS провайдеров, либо к серверам WSUS соседей по офису и т.д. Т.е. им было, откуда скачивать файлы обновлений, требовалось только указать, какие именно обновления требуется загрузить. Во-вторых, мне разрешили использовать Powershell.

Задумка была проста: необходимо реализовать механизм импорта / экспорта данных о том, какие обновления были одобрены. По старой традиции, сформировавшейся еще во времена обучения в университете, экспортировать я решил в простой XML-файл. Структура этого файла получилась примерно такой:

Администратор (или его доверенный помощник) в своей сети одобряет некоторые обновления для использования в определенных группах, убеждается, что всё хорошо, и выгружает файл с информацией о том, какие из них нужно применить к тем или иным группам компьютеров, например, на внутренний WEB-сайт;
Эникейщик на месте (я, например) настраивает скрипт, который скачивает сформированный администатором в п.1 файл и загружает его содержимое в локальную базу WSUS;
При наличии нескольких несвязанных серверов WSUS в зоне ответственности эникейщика — п.2 выполняется несколько раз

Что это даёт в итоге? Во-первых, эникейщик не принимает решение о том, какие обновления одобрить, а какие — нет: это решение принимает квалифицированный системный администратор, способный обоснованно спрогнозировать влияние каждого обновления на используемые в работе ~~кривые~~ оригинальные разработки, по всей видимости, сильно завязанные на конкретные ~~глюки~~ недокументированные возможности ОС, SQL-сервера и пакета MS Office.

Во-вторых, эникейщик не может ошибиться (забыть одобрить нужное обновление, случайно одобрить ненужное и т.п.)

В-третьих, администратор получает гарантию того, что во всех сетях компании одобрены к установке одни и те же обновления (т.е. вопрос «А какая версия офиса используется у нас в Замкадске?» теряет актуальность).

Кроме экспорта одобрений требовался механизм переноса прошедших испытания в тестовых группах обновлений на «боевые». Желательно, одной кнопкой / командой — «одобрить всё, что не запрещено и одобрено для использования в тестовой группе». Это нужно для того, чтобы исключить попадание непротестированных обновлений в продакшн в следствие ошибки исполнителя («ой, не то одобрил, не туда нажал!»).

Реализация

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

После этого — создать функцию, которая возвращала бы объект, представляющий сервер WSUS, установленный локально:

Поскольку постановка задачи предполагает работу с группами WSUS, необходимо научиться получать их представление. Я использовал примерно такой код:

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

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

В общем-то, всё довольно просто. Экспорт осуществляется аналогично импорту (желающие могут найти соответствующую функцию в полном тексте сценария).

Интерфейс пользователя

Так как сценарием должен был пользоваться не только я, но и мои коллеги — такие же эникейщики в других регионах, было решено снабдить его графическим интерфейсом пользователя:

Я постарался соблюсти минимализм в облике основного окна и избегал включения параметров работы сценария в интерфейс, только ~~хардкор~~ хардкод. Поскольку WPF установлен далеко не на всех компьютерах, на которых используется это сценарий, графический интерфейс реализован с использованием System.Windows.Forms, а не более подходящего для таких задач XAML.

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

DoImportFromFile — Путь к файлу, из которого нужно импортировать информацию об одобрениях. Если этот параметр пуст, импорт не происходит;
DoExportToFile — Путь к файлу, в который следует выгрузить информацию об одобрениях. Аналогично, при отсутствии значения этого параметра, экспорт не выполняется;
ServersCopyTestApprovals — Одобрить все обновления, разрешенные для использования в тестовой группе серверов, для использования в на «боевых» серверах (см. далее);
WorkstationsCopyTestApprovals — Аналогичен предыдущему, но для рабочих станций;
PathToLog — Путь к файлу журнала (по умолчанию создается во временной папке "%Temp%")

Мероприятия по внедрению

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

Первоначально в каждой сети была выделена, по меньшей мере, одна тестовая рабочая станция и хотя бы один тестовый сервер. По возможности, мы старались включать в тестовые группы некритичные для основного бизнеса узлы. Прежде, чем обновления будут одобрены для использования по всей сети, они несколько дней (на усмотрение системного администратора) проверяются на тестовых компьютерах. Те обновления, которые вызывают какие-либо проблемы, исключаются (decline), остальные, по окончании тестирования, одобряются для использования в боевых группах. Для копирования одобрений используется описываемый сценарий.

gWSUS_srv_test — тестовые серверы;
gWSUS_wks_test — тестовые рабочие станции;
gWSUS_srv_prod — «боевые» серверы;
gWSUS_wks_prod — критичные для бизнеса рабочие станции;

Раз в несколько дней (на усмотрение системного администратора) специально назначенный эникейщик в тестовой сети выполняет одобрение новых (еще не одобренных и не отмененных) обновлений. После получения разрешения от системного администратора он выгружает список одобрений в виде XML-файла на специальный сайт внутри сети.

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

Заключение

Разумеется, описанное решение не лишено определённых недостатков: сценарий не обеспечивает проверку востребованности загружаемых одобрений (а нужно ли одобрение сервиспака для SQL в сети, если этой СУБД там нет?), сценарий требует наличия доступа к вышестоящему серверу WSUS (или серверу WindowsUpdate), да и сам код, наверняка, далёк от идеала.

Однако поставленная задача была успешно решена, а практика, как известно, — критерий истины. Надеюсь, описанное решение пригодится еще кому-нибудь.

Загружаемые обновления Windows 10 могут быть большими, так как каждый пакет содержит все ранее выпущенные исправления для простоты и обеспечения согласованности.

Начиная с версии 7, Windows позволяет уменьшить размер загружаемых Центром обновления Windows файлов с помощью функции экспресс-доставки. По умолчанию все клиентские устройства поддерживают эту функцию, но на устройствах Windows 10 Корпоративная требуется служба Windows Server Update Services (WSUS).

Как корпорация Майкрософт поддерживает функцию экспресс-доставки

Экспресс-доставка в автономной службе WSUS

Экспресс-доставка на устройствах, подключенных к Центру обновления Windows

Клиентские устройства поддерживают экспресс-доставку через клиент Центра обновления Windows, который проверяет, скачивает и устанавливает обновления. На этапе скачивания клиент Центра обновления Windows запрашивает пакеты экспресс-доставки и скачивает соответствующие диапазоны байтов.

Корпоративные устройства, управляемые с помощью Центра обновления Windows для бизнеса , также могут воспользоваться экспресс-доставкой обновлений без дополнительной настройки.

Как независимые поставщики программного обеспечения могут воспользоваться экспресс-доставкой

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

Сервер WSUS требуется для проверки и синхронизации обновлений (подробнее).

Для размещения содержимого обновлений мы рекомендуем использовать файловый кэш независимого поставщика программного обеспечения, где хранятся CAB-файлы обновлений и PSF-файлы экспресс-пакетов.

Должен быть установлен накопительный пакет обновления для выпуска Windows 10 версии 1607 (или более поздней) от января 2017 г. (KB3213986 (сборка ОС 14393.693).

Агент клиента независимого поставщика программного обеспечения определяет, какие обновления будут утверждены, скачаны и установлены.
Клиент Центра обновления Windows определяет диапазоны байтов для скачивания и инициирует запрос на скачивание.

Шаг 1. Настройка WSUS

Служба WSUS выступает в качестве интерфейса Центра обновления Windows и управляет всеми метаданными с описанием скачиваемых экспресс-пакетов. Если вам нужно выполнить развертывание, см. описание службы Windows Server Update Service версии 3.0 с пакетом обновления 2 (SP2). После развертывания службы WSUS следует принять решение, нужно ли хранить содержимое обновлений локально на сервере WSUS. Мы рекомендуем при настройке служб WSUS не настраивать локальное хранение обновлений. При этом предполагается, что у вас уже есть программное обеспечение для управления развертыванием пакетов в локальной среде. Дополнительные сведения о настройке локального хранилища WSUS см. в руководстве по выбору расположения для хранения обновлений.

Шаг 2. Указание и заполнение файлового кэша независимого поставщика программного обеспечения

Указание файлового кэша независимого поставщика программного обеспечения

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

Имя	Описание
Настройте альтернативное расположение для скачивания обновлений.	Здесь определяется другой сервер в интрасети, на котором будут размещаться обновления из Центра обновления Майкрософт. Вы сможете применить эту службу обновления для автоматического обновления компьютеров в локальной сети.

Имя

Описание

Настройте альтернативное расположение для скачивания обновлений.

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

Есть два варианта настройки альтернативного расположения для скачивания файлового кэша независимого поставщика программного обеспечения.

Укажите локальный узел.

В этом варианте клиент Центра обновления Windows будет отправлять запросы на скачивание локальному узлу. Так агент клиента независимого поставщика программного обеспечения будет самостоятельно обрабатывать эти запросы и перенаправлять их для выполнения запроса на скачивание.

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

Заполнение файлового кэша независимого поставщика программного обеспечения

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

Чтобы заполнить файловый кэш независимого поставщика программного обеспечения, сделайте следующее:

С помощью API WSUS получите путь и имя файла обновления для службы Центра обновления Майкрософт.

Скачайте файлы в Центре обновления Майкрософт и сохраните их в файловом кэше независимого поставщика программного обеспечения с помощью одного из следующих двух методов:

Сохраните файлы в той же папке, которая используется в службе Центра обновления Майкрософт.

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

Шаг 3. Настройка агента клиента независимого поставщика программного обеспечения для управления операциями клиента Центра обновления Windows

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

Агент клиента независимого поставщика программного обеспечения вызывает клиент Центра обновления Майкрософт для проверки сервера WSUS.

Результатом проверки является набор обновлений, применимых к этому клиенту Центра обновления Майкрософт.

Клиент независимого поставщика программного обеспечения определяет, какие обновления будут утверждены, скачаны и установлены.

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

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

Варианты рабочего процесса скачивания обновлений

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

Как работает экспресс-доставка

Для обновлений операционной системы, которая поддерживает экспресс-доставку, в службе сохраняются следующие две версии файла полезных данных:

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

Экспресс-версия содержит разностные данные, которых достаточно для исправления существующих двоичных файлов прямо на устройстве.

Полная версия и экспресс-версия упоминаются в метаданных обновления, которое скачивается на клиент во время фазы сканирования.

Экспресс-доставка работает следующим образом:

Клиент Центра обновления Windows сначала пытается скачать экспресс-версию, а в некоторых ситуациях при необходимости возвращается к полной версии файла (например, если запрос идет через прокси-сервер, не поддерживающий запросы диапазона байтов).

Когда клиент Центра обновления Windows инициирует скачивание экспресс-версии, клиент Центра обновления Windows сначала скачивает заглушку, которая входит в пакет Express.

Клиент Центра обновления Windows передает эту заглушку установщику Windows, который использует заглушку для локальной проверки, сравнивая разностные данные файла на устройстве и необходимые элементы для получения последней версии предлагаемого файла.

Затем установщик Windows обращается к клиенту Центра обновления Windows для скачивания диапазонов, которые были определены как обязательные.

Клиент Центра обновления Windows скачивает эти диапазоны и передает их установщику Windows, который в свою очередь применяет диапазоны и определяет, нужны ли дополнительные диапазоны. Это повторяется, пока установщик Windows не сообщит клиенту Центра обновления Windows о том, что все необходимые диапазоны уже скачаны.

На этом этапе скачивание завершено и обновления готовы к установке.

Как оптимизация доставки снижает нагрузку на сеть

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

По умолчанию в Windows 10 Корпоративная и Windows 10 для образовательных учреждений оптимизация доставки поддерживает одноранговый обмен данными только в локальной сети компании, но вы можете изменить это поведение с помощью параметров групповой политики и управления мобильными устройствами (MDM).

Windows Server Update Services или WSUS предназначен для распространения обновлений внутри сети. Он позволит скачивать все пакеты для их установки на один сервер и распространять данные пакеты по локальной сети. Это ускорит процесс получения самих обновлений, а также даст администратору контроль над процессом их установки.

В данной инструкции мы рассмотрим пример установки и настройки WSUS на Windows Server 2012 R2.

Перед установкой

Рекомендуется выполнить следующие действия, прежде чем начать установку WSUS:

Настраиваем статический IP-адрес.
При необходимости, добавляем компьютер в домен.
Устанавливаем все обновления Windows.

Также нужно убедиться, что на сервере достаточно дискового пространства. Под WSUS нужно много места — в среднем, за 2 года использования, может быть израсходовано около 1 Тб. Хотя, это все условно и, во многом, зависит от количества программных продуктов, которые нужно обновлять и как часто выполнять чистку сервера от устаревших данных.

Установка роли

Установка WSUS устанавливается как роль Windows Server. Для начала запускаем Диспетчер серверов:

В правой части открытого окна нажимаем Управление - Добавить роли и компоненты:

На странице приветствия просто нажимаем Далее (также можно установить галочку Пропускать эту страницу по умолчанию):

На следующей странице оставляем переключатель в положении Установка ролей или компонентов:

Далее выбираем сервер из списка, на который будем ставить WSUS:

В окне «Выбор ролей сервера» ставим галочку Службы Windows Server Update Services - в открывшемся окне (если оно появится) нажимаем Добавить компоненты:

Среди компонентов оставляем все по умолчанию и нажимаем Далее:

Мастер запустит предварительную настройку служб обновления — нажимаем Далее:

Среди ролей службы можно оставить галочки, выставленные по умолчанию:

Прописываем путь, где WSUS будет хранить файлы обновлений:

* в нашем примере был прописан путь C:\WSUS Updates. Обновления нужно хранить на разделе с достаточным объемом памяти.

Запустится настройка роли IIS — просто нажимаем Далее:

Среди служб ролей оставляем все галочки по умолчанию и нажимаем Далее:

В последнем окне проверяем сводную информацию о всех компонентах, которые будут установлены на сервер и нажимаем Установить:

Процесс установки занимаем несколько минут. После завершения можно закрыть окно:

Установка роли WSUS завершена.

Первый запуск и настройка WSUS

После установки наш сервер еще не готов к работе и требуется его первичная настройка. Она выполняется с помощью мастера.

В диспетчере сервера кликаем по Средства - Службы Windows Server Update Services:

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

. и ждем завершения настройки:

Откроется стартовое окно мастера настройки WSUS — идем далее:

На следующей странице нажимаем Далее (при желании, можно принять участие в улучшении качества продуктов Microsoft):

Далее настраиваем источник обновлений для нашего сервера. Это может быть центр обновлений Microsoft или другой наш WSUS, установленный ранее:

* в нашем примере установка будет выполняться из центра Microsoft. На данном этапе можно сделать сервер подчиненным, синхронизируя обновления с другим WSUS.

Если в нашей сети используется прокси-сервер, задаем настройки:

* в нашем примере прокси-сервер не используется.

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

. и дожидаемся окончания процесса:

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

Внимательно проходим по списку программных продуктов Microsoft и выбираем те, которые есть в нашей сети, и для который мы хотим устанавливать обновления:

* не стоит выбирать все программные продукты, так как на сервере может не хватить дискового пространства.

Выбираем классы обновлений, которые мы будем устанавливать на компьютеры:

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

Настраиваем синхронизацию обновлений. Желательно, чтобы она выполнялась в автоматическом режиме:

Мы завершили первичную настройку WSUS. При желании, можно установить галочку Запустить первоначальную синхронизацию:

После откроется консоль управления WSUS.

Завершение настройки сервера обновлений

Наш сервис установлен, настроен и запущен. Осталось несколько штрихов.

Установка Microsoft Report Viewer

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

Продолжаем установку и завершаем ее.

После выполняем установку приложения и перезапускаем консоль WSUS — отчеты будут доступны для просмотра.

Донастройка WSUS

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

1. Группы компьютеров

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

В консоли управления WSUS переходим в Компьютеры - кликаем правой кнопкой мыши по Все компьютеры и выбираем Добавить группу компьютеров. :

Вводим название для группы и повторяем действия для создания новой группы. В итоге получаем несколько групп, например:

2. Автоматические утверждения

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

В консоли управления WSUS переходим в раздел Параметры - Автоматические утверждения:

Кликаем по Создать правило:

У нас есть возможность комбинировать условия, при которых будут работать наши правила. Например, для созданных ранее групп компьютеров можно создать такие правила:

Для тестовой группы применять все обновления сразу после их выхода.
Для рабочих станций и серверов сразу устанавливать критические обновления.
Для рабочих станций и серверов применять обновления спустя 7 дней.
Для серверов устанавливать обновления безопасности по прошествии 3-х дней.

3. Добавление компьютеров в группы

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

В консоли WSUS переходим в Параметры - Компьютеры:

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

Настройка клиентов

И так, наш сервер готов к работе. Клиентские компьютеры могут быть настроены в автоматическом режиме с помощью групповой политики Active Directory или вручную в реестре. Рассмотрим оба варианта. Также стоит отметить, что, как правило, проблем совместимости нет — WSUS сервер на Windows Server 2012 без проблем принимает запросы как от Windows 7, так и Windows 10. Приведенные ниже примеры настроек являются универсальными.

Групповая политика (GPO)

Открываем инструмент настройки групповой политики, создаем новые политики для разных групп компьютеров — в нашем примере:

Для тестовой группы.
Для серверов.
Для рабочих станций.

Создаем GPO для соответствующих организационных юнитов. Открываем данные политики на редактирование и переходим по пути Конфигурация компьютера - Политики - Административные шаблоны - Компоненты Windows - Центр обновления Windows. Стоит настроить следующие политики:

* 8530 — сетевой порт, на котором по умолчанию слушает сервер WSUS. Уточнить его можно на стартовой странице консоли управления WSUS.

Ждем применения политик. Для ускорения процесса некоторые компьютеры можно перезагрузить вручную.

Настройка клиентов через реестр Windows

Как говорилось выше, мы можем вручную настроить компьютер на подключение к серверу обновлений WSUS.

Для этого запускаем редактор реестра и переходим по пути: HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\WindowsUpdate. Нам необходимо создать следующие ключи:

Теперь переходим в раздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Polices\Microsoft\Windows\WindowsUpdate\AU. Если он отсутствует, создаем вручную. После нужно создать ключи:

AUOptions, REG_DWORD — значение 2
AutoInstallMinorUpdates, REG_DWORD — значение 0
NoAutoUpdate, REG_DWORD — значение 0
ScheduledInstallDay, REG_DWORD — значение 0
ScheduledInstallTime, REG_DWORD — значение 3
UseWUServer, REG_DWORD — значение 1

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

Автоматическая чистка WSUS

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

Саму чистку можно сделать в панели управления сервером обновления в разделе Параметры - Мастер очистки сервера.

Также можно воспользоваться командлетом в Powershell Invoke-WsusServerCleanup — целиком команда будет такой:

Get-WSUSServer | Invoke-WsusServerCleanup -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles -CompressUpdates -DeclineExpiredUpdates -DeclineSupersededUpdates

Для автоматизации чистки создаем скрипт с расширением .ps1 и создаем задачу в планировщике. Чистку стоит делать раз в неделю.

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

Автор: Денис Васильев

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

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

Установка WSUS

В рамках ОС Windows Server 2008 существует роль сервера Windows Server Update Services(рис. 1).

Для Windows Server 2003 следующие системные требования к установке WSUS 3.0 SP1:

Несмотря на то, что служба практически не требовательна к процессору и оперативной памяти, ей необходима изрядная доля дискового пространства. Желательно 40 Гб и более. В конечном итоге, размер занимаемого дискового пространства будет зависит от количества продуктов, которые необходимо обновлять, и количества требуемых обновлений в инфраструктуре.
Если при установке сервер не удовлетворяет системным требования, то появится окно предупреждения, в котором будет описано что необходимо установить (рис. 2).

Настройка сервера WSUS

Для нормальной работы сервера необходимо указать ряд параметров, которые делаются с помощью «Мастер настройки Windows Server Update Services»

В окне «Выбор вышестоящего сервера» необходимо указать пункт «Синхронизировать с Центром обновлений Майкрософт» (рис. 3).

При применении к корпоративной среде прокси-сервера в окне «Настройка прокси-сервера» необходимо указать IP адрес, номер порта и параметры аутентификации на прокси-сервере(рис. 4).

В окне «Выбор языков» необходимо выбрать пункт «Загружать обновления только на следующих языках» обязательно выбрать «Английский». Выбор остальных языков необходимо делать исходя из систем, установленных в компании, обычно ещё добавляют «Русский» (рис. 5). Нет необходимости выбирать «Загружать обновления на всех языках, включая новые», так как это увеличит количество обновлений, хранящихся на дисковом пространстве.

В окне «Выбор продуктов» необходимо указать продукты, установленные в рамках корпоративной среды. ВНИМАНИЕ! Никогда не устанавливаете все продукты, так как это может привести к увеличению размера хранимых обновлений, при этом обновления не будут использоваться. Необходимо методично и последовательно выбрать только те продукты которые используются в рамках корпоративной среды (рис. 6).

В окне «Выбор классов» необходимо указать только те классы которые требуют обновлений. Так как указание лишних классов в значительной степени увеличивает размер хранимых обновлений (рис. 7).

В окне «Настройка расписания синхронизации» необходимо выбрать время синхронизации (рис. 8). В рамках WSUS синхронизации не предполагает загрузку обновлений. В данном случае синхронизация будет производить только обновление информации с сервера Центра обновлений Майкрософт».

После первой синхронизации необходимо открыть консоль WSUS и выбрать «Параметры». В «Параметры» открыть пункт «Файлы и языки обновлений» ( рис. 9)

Во вкладке «Файлы обновлений» окна «Файлы и языки обновлений» необходимо указать каким образом будет осуществляться хранение файлов обновлений. Так как мы хотим уменьшить размер Интернет трафика, то необходимо выбрать «Хранить файлы обновлений локально на этом сервере» и ОБЯЗАТЕЛЬНО! выбираем пункты «загружать файлы обновлений на сервер только после одобрения обновления» и «Загружать файлы экспресс - установки» (рис. 10). Пункт «Загружать файлы обновлений на сервер только после одобрения обновления» необходим, так как по умолчанию сервер загрузить ВСЕ обновления, которые он посчитает необходимым для выбранных продуктов. Однако так как с течением времени очень многие обновления аккумулируются в Service Pack, то вероятнее всего они не будут нужны и займут дисковое пространство.

После всех настроек необходимо добавить компьютеры в службу WSUS.

Добавление компьютеров в службу WSUS

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

Это делается следующим образом «Пуск – Администрирование – Управление групповой политикой». Выбираем ту политику, которая действует в домене (по умолчанию Default Group Policy). Кликаем правой кнопкой и выбираем «Изменить».

В окне «Редактор управления групповыми политиками» заходим «Конфигурация компьютера – Политики – Административные шаблоны – Компоненты Windows – Центр обновления Windows». Выбираем пункт «Указать размещение службы обновлений в Интрасети » (рис. 11)

Также необходимо определить политику обновлений. Это делается через пункт «Настройка автоматических обновлений» (рис. 13).

В окне «Свойства: Настройка автоматических обновлений» указываем параметр «Включен» и параметры «Настройка автоматического обновления», «Установка по расписанию – день», «Установка по расписанию – время». В окне «Объяснение» есть описание всех параметров для серверов и желательно устанавливать параметр «2 –уведомления о загрузке и установке», что позволит администраторам выбирать время установки обновлений на сервера(рис. 14).

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

В командной строке набираем gpedit.msc и проделываем те же операции, которые были описаны выше для групповой политики в домене.

Через некоторое время компьютер появится в окне «Компьютеры – Все компьютеры – Не назначенные компьютеры» при «Состояние: Любой» (рис. 15).

Управление обновлениями

Для того чтобы увидеть и одобрить необходимые обновления нужно в «Обновления – Все обновления» выбрать следующие пункты фильтра: «Одобрение: Неодобренные» и Состояние: Требуется» и нажать «Обновить»(рис. 16). ВНИМАНИЕ! для проверки необходимых обновлений всегда обращайте внимание, чтобы настройки фильтра стояли в положениях «Одобрение: Неодобренные» и Состояние: Требуется», иначе вы рискуете загрузить ненужные вам обновления, или не загрузить их вообще. В случае, если фильтр в настройках «Одобрение: Неодобренные» и Состояние: Требуется» показал пустое поле, то все необходимые обновления для компьютеров уже одобрены и находятся на сервере.

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

Достаточно часто существует необходимость принудительной проверки обновлений на сервере обновлений со стороны компьютера. Для этого существует программа wuauclt.exe, которая запускается через командную строку. Для проверки обновлений её необходимо запускать с ключом /detectnow (wuauclt.exe /detectnow). Для посылки отчета о состоянии (очень часто необходимо при первом подключении к серверу обновлений) необходимо запускать с ключом /reportnow (wuauclt.exe /reportnow).

Читайте также: