Андрей Смирнов
Время чтения: ~16 мин.
Просмотров: 2

Управление автоматическими обновлениями в Windows server 2008

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

Статья большая, но в ней много картинок (как любят писать на одном очень популярном в определённых кругах сайте – осторожно, трафик! 😉

Что такое WSUS?

Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. С его помощью можно обновлять как собственно операционные системы, так и многие другие продукты Microsoft (Office, Exchange, SQL и многие другие).

WSUS  — бесплатный продукт, его можно скачать с сайта Microsoft.

Зачем это нужно?

По умолчанию операционные системы обновляются самостоятельно с сервера Microsoft, который находится где-то в интернете:

Update without WSUS

Типичная схема обновления

Для малых организаций эта схема вполне приемлема, но если количество компьютеров организации больше, чем n (нет, n это мало, лучше m :)) и если софт от Microsoft не ограничивается только операционными системами, то количество скачиваний и следовательно трафика значительно увеличивается. Например в организации 100 компьютеров, на каждом из которых установлены Windows 7 и Office. Допустим выходят обновления для семёрки и офиса, размером по 1 МБ каждое. Так, чтобы обновить все компьютеры понадобится выкачать 200 МБ. В наш цифровой век для многих это уже проблема, но всё же зачем лишний раз “засорять эфир”.

Ещё одно неудобство автоматического обновления кроется в использовании какого-либо специфического софта, или драйверах, которые могут конфликтовать с обновлениями. Да и сам Microsoft не безгрешен, и время от времени обновления сами по себе вызывают конфликт с системой (например, проблема с SP1 для Windows 7, после установки которого некоторые системы работали нестабильно, а некоторые вообще вываливались в синий экран). В этом случае одним единственным обновлением можно “положить” все компьютеры организации.

Для предотвращения таких ситуаций может служить установка локального сервера обновлений под управлением WSUS.

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

Update with WSUS

Схема обновления с использованием WSUS

При желании/необходимости можно протестировать свежие обновления на тестовом компьютере, и только после успешной проверки обновлять всю сеть.

Ещё если сеть организации очень большая, и/или распределена территориально по разным городам, можно настроить так, чтобы был один главный сервер WSUS (upstream), и несколько других, которые будут загружать обновления с него (downstream), а клиенты в свою очередь будут обновляться с этих WSUS серверов. Но это уже детали, на них я останавливаться не буду.

Установка WSUS

Для нормальной работы потребуются следующие компоненты:

  • Windows Server 2003 SP1/2008
  • IIS 6.0+
  • Microsoft .NET Framework 2.0+
  • Microsoft Report Viewer
  • MS SQL 2005 SP1+, но в принципе можно обойтись Windows Internal Database (встроена в WSUS).

Установка WSUS не требует больших усилий; при установке нужно указать следующие параметры:

  • нужно-ли хранить все скачанные обновления локально (в этом случае нужно указать место хранения обновлений), или же использовать WSUS только в качестве прокси;
  • использовать-ли SQL Server или Windows Internal Database;
  • порт, на котором будет работать WSUS – по умолчанию выбран 80-й порт (для всех http-запросов), или же создать отдельный порт для WSUS (8530), что наверное предпочтительней.

Настройка WSUS

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

  • Имеющиеся типы обновлений;
  • Продукты, допускающие обновления;
  • Доступные языки.

WSUS - Connection to upstream server

WSUS — Подключение к вышестоящему серверу

После этой синхронизации можно выбирать что и для чего загружать.

А именно: языки:

WSUS - Choose Languages

Языки обновлений

продукты:

WSUS - Choose Products

Продукты

классы обновлений:

WSUS - Choose Classifications

Классы

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

На следующем этапе нужно указать расписание синхронизации с вышестоящим сервером – либо вручную, либо автоматически. Во втором случае нужно указать время первой синхронизации и количество синхронизаций в день:

WSUS - Set Syns Schedule

Расписание синхронизации

Все эти настройки можно настраивать как при первоначальной настройке, так и потом в любое время (на скриншотах как раз из варианта “потом”).

Теперь у нас всё готово для работы. После прохождения всех вышеописанных этапов открывается консоль WSUS:

WSUS - Main Window

Консоль WSUS

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

Так как сервер мы только настроили, и ещё не запускали синхронизацию, то в разделе “Общие сведения” сплошные нули.

Нажимаем “Синхронизировать сейчас” и ждём.

Примечание: Нужно отметить, что процесс получения обновлений сравнительно длительный процесс (особенно в первый раз) и зависит от тех настроек, которые мы рассматривали выше, а именно какие обновления качать, для каких продуктов, и на каких языках. За это время можно если не выпить, то налить чашку кофе точно 🙂

После завершения синхронизации в этом же окне можно ознакомиться с результатом синхронизации и с количеством выкачанных обновлений:

WSUS - Main Window after update

Консоль WSUS после синхронизации

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

WSUS - Main Window - Critical Updates

Обзор обновлений

А при двойном щелчке на обновлении подробная информация о нём открывается в отдельном окне, при условии, что был установлен Microsoft Report Viewer.

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

WSUS - Approve Updates

Одобрение обновлений

На этом настройка собственно WSUS заканчивается.

Настройка групповых политик

Далее если используется домен, на контроллере домена нужно создать групповую политику для обновления и привязать её к какому-либо подразделению (OU) либо же ко всему домену. Если домена нет, то нужно изменить групповую политику на клиентских компьютерах таким образом, чтобы сервером обновлений был WSUS.

Для этого в консоли Group Policy Managment нужно перейти в раздел Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Windows Update. В этом разделе содержатся настройки, относящиеся к обновлению.

В данном случае нас интересуют лишь некоторые параметры.

Настройка автоматического обновления:

 Group Policy - Configure Automatic Updates Properties

Свойства: Настройка автоматического обновления

Переключатель нужно поставить в положение Включён и настроить один из четырёх вариантов обновления

  • Уведомить о загрузке и установке
  • Автоматически загрузить и уведомить об установке
  • Автоматически загрузить и установить по расписанию
  • Разрешить локальному администратору выбрать параметр

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

Указать размещение службы обновлений Microsoft в интрасети:

Group Policy - Specify intranet Microsoft update service location Properties

Свойства: Указать размещение службы обновлений Microsoft в интрасети

Также включить, и указать полный путь к серверу в WSUS, и серверу статистики.

Частота поиска автоматических обновлений:

Group Policy - Automatic Updates detection frequency Properties

Свойства: Частота поиска автоматических обновлений

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

Также можно включить Разрешить пользователям, не являющимся администраторами, получать уведомления об установке.

Всё! Наконец-то всё настроено можно переходить к проверке.

Проверка на клиенте

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

Windows XP - Automatic Update

Свойства системы: автоматическое обновление

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

Значок в трее

Вернувшись в консоль WSUS можно наблюдать за процессом:

Процесс обновления

Напоследок хотелось бы сказать ещё пару слов о группах компьютеров.

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

Группы можно использовать, например, для тестирования обновлений до того, как развёртывать их на всю сеть. И если проверка прошла успешно применять обновления к группе “Все компьютеры”. Подробнее о группах компьютеров и о тонкостях работы с WSUS можно ознакомиться в пошаговом руководстве по началу работы с WSUS.

Ну что ж, вот и настала пора подружить Windows-обновления с миром Open Source. В этой статье разнообразим быт интеграцией Ansible со всеми возможными источниками обновлений Windows-машин. Хотя возможности системы значительно шире простой раскатки обновлений на серверы и рабочие станции, но ведь надо с чего-то начинать.

Про настройку Windows Server Update Services рассказывать я не буду, благо она тривиальна. Сосредоточусь на минусах.

Интерфейс WSUS почти не менялся на протяжении всей истории.

Невозможность установки по требованию. Действительно, для штатной работы WSUS подходит неплохо — обновления спокойно себе настраиваются и ставятся по локальной сети при выключении компьютеров. Но если нужно срочно установить патчи безопасности, то придется выкручиваться скриптами и решениями для запуска этих самых скриптов. В этом может помочь наш материал «1000++ способ запуска команд на удаленном компьютере».

Отсутствие штатного способа установки обновлений стороннего ПО. Если есть сервер обновлений, то выглядит разумным использовать его не только для обновлений программ MS, но для других решений. Например, в не к ночи упомянутом Adobe Flash Player уязвимости находятся с завидной регулярностью, да и радовать пользователей новыми возможностями FireFox тоже хотелось бы. Для того чтобы наладить установку обновлений через WSUS, приходится использовать сторонние решения вроде WSUS Package Publisher. Посмотреть примеры настройки можно в статье «Установка любого программного обеспечения средствами WSUS — 2».

Использование встроенной БД Windows. При стандартной установке WSUS использует WID — Windows Internal Database. По сути это маленький встроенный SQL Server с базой данных. В случае каких-то неполадок или конфликтов — к примеру, если у вас на одном сервере живет Remote Desktop Connection Broker и WSUS, — приходится чинить эту базу, настраивать права доступа и всячески развлекаться. Да и резервное копирование бы не помешало. По счастью, WSUS может использовать и классический SQL. Для переноса БД WSUS можно воспользоваться инструкцией Migrating the WSUS Database from WID to SQL от Microsoft.

Необходимость обслуживания и неочевидная настройка сбойных клиентов. Как это бывает с продуктами от Microsoft, рано или поздно WSUS начинает тормозить: клиенты долго не могут к нему подцепиться и скачать обновления. Сборник советов и оптимизаций есть в статье «Ускоряем работу WSUS» и в комментариях к ней.

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

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

Устраивать холивар, что лучше из бесплатных систем — Ansible, Chef, Puppet или вовсе Salt, нет ни малейшего желания. Система Ansible выбрана за отсутствие необходимости использования агентов и за простоту настройки. И, конечно, из-за Python: ведь этот язык намного проще освоить начинающим автоматизаторам, в отличие от Ruby.

Стоит отметить, что помимо решения задачи, это будет неплохое подспорье для ознакомления с принципами работы подобных систем. Если, конечно, вы еще не развлекались установкой Streisand, особенно, когда что-то в процессе идет не так. А если вы уже используете Ansible или другие модные решения, то запросто сможете и обновления устанавливать. С азами Ansible я рекомендую ознакомиться в статье «Пособие по Ansible», а ниже — пошаговая инструкция по работе с обновлениями.

Для начала подготовим сервер Ansible. Подойдет практически любой GNULinux дистрибутив, но примеры команд я буду приводить для Ubuntu Server (так исторически сложилось).

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

apt-get install python-pip pip install --upgrade pip pip install --upgrade virtualenv

Затем нам понадобится установить пакет pywinrm для подключения к системам Windows и непосредственно систему Ansible:

sudo pip install pywinrm sudo pip install ansible

Проверить установку можно командой ansible —version.

Проверка установки.

Вместо пакета в теории pywinrm можно использовать любое другое средство для управления Windows с машины на Linux. Часть из них разобрана в статье «Перекрестное опыление: управляем Linux из-под Windows, и наоборот».

Теперь нужно разрешить подключение к Windows по WinRM. Для этого есть уже готовый скрипт ConfigureRemotingForAnsible.ps1, доступный на GitHub. Ну, а как запускать скрипты на удаленных машинах вы уже знаете.

Проверить подключение к Windows можно командой:

ansible windows -m win_ping

Проверка подключения успешна.

Теперь можно заняться созданием playbook. Нам облегчит жизнь тот факт, что разработчики Ansible уже подумали за нас и сделали модуль win_updates, как раз для решения таких задач.

Playbook — это «инструкция», которая говорит системе управления конфигурациями, что же ей делать. Разумеется, пошаговая.

Любой playbook является файлом в формате yml и представляет из себя набор директив — у каждого модуля они свои. Модуль winupdate позволяет использовать следующие директивы (жирным выделены значения по умолчанию):

Название Значение Описание
category_names Категория обновлений.
whitelist Номер обновления или шаблон имени. Непосредственно номер устанавливаемых обновлений вида KB01234 или шаблон имени в виде регулярного выражения PowerShell.
blacklist Номер обновления или шаблон имени. Непосредственно номер обновлений, которые не нужно устанавливать, вида KB01234 или шаблон имени в виде регулярного выражения PowerShell.
reboot Требуется ли перезагрузка после обновления.
reboot_timeout секунды, 1200 Сколько времени ждать машину после перезагрузки.
state Устанавливать ли обновления, или только искать.
log_path путь к файлу Журнал установки, при этом папка должна существовать.

Таким образом, для установки определенных обновлений подойдет следующий playbook:

- name: Install specific updates based on the KBs for those updates   win_updates:     category_name:     - SecurityUpdates      whitelist:     - KB4073819     - KB4074228

А если надо просто посчитать, сколько обновлений не хватает, playbook будет таким:

  – name: Check for missing updates           win_updates: state=searched           register: update_count

Для установки всех доступных обновлений с последующей перезагрузкой будет подобный playbook:

- name: Install all critical and security updates   win_updates:     category_names:     - CriticalUpdates     - SecurityUpdates     - UpdateRollups     state: installed   register: update_result          - name: reboot host if required           win_reboot:           when: update_result.reboot_required

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

[DCs] dc1.mydomain.local dc2.mydomain.local  [AppServers] app1.mydomain.local app2.mydomain.local  [DBServers] db1.mydomain.local db2.mydomain.local

И теперь для установки обновлений только на контроллеры домена можно использовать playbook:

- hosts: DCs   tasks:   - name: Choose which Windows updates to install   win_updates:     category_names:       - SecurityUpdates       - CriticalUpdates       - UpdateRollups

Команда, которая проделает все эти операции, будет такой:

ansible-playbook -i inventory.yml -s windowsupdates.yml

Внимательный читатель может спросить про источник скачиваемых обновлений. Источник будет тот, что настроен на компьютере: будь то Windows Update в интернете или локальный WSUS. Даже если до настройки WSUS руки не дошли, можно дать команду на установку нужных срочных апдейтов, особенно если детальки Lego под ноги уже высыпались.

Остается добавить, что не обязательно использовать именно Ansible. Например, для системы управления конфигурациями Chef можно использовать Cookbook Wsus Client или более навороченный boxstarter. Аналогичные модули существуют и для Puppet. В общем-то практически любая система управления конфигурациями может что-то подобное, в том числе и MS SCCM.

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

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

Patch Management от Comodo. Система установки обновлений для Windows и другого ПО. В отличие от других решений — бесплатна.

Интерфейс Comodo Patch Management.

Opsi. Бесплатная, интересная система, поддерживающая установку не только обновлений, но и операционных систем, заодно с инвентаризацией.

BatchPatch. Единственная из платных систем, попавшая в список. Позволяет устанавливать ПО, обновлять его, как и Windows, и многое другое. Отличается олдскульным дизайном, а также стоимостью не за количество обслуживаемых хостов, а за пользователей программы, т.е администраторов. Пожалуй, это одно из немногочисленных решений, позиционирующих себя как аналог WSUS. Цена начинается от $400.

Интерфейс BatchPatch.

В комментариях добавляйте свои любимые инструменты для работы с обновлениями и не только.

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

Архитектура решения

Имеется центральный офис и несколько территориально распределенных площадок связанных между собой виртуальными частными каналами (VPN). Site A является центральным сайтом, который осуществляет загрузку обновлений и раздачу подчиненным сайтам (Site B, Site C). Подчиненные сервера отправляют на центральный сайт всю информацию о состоянии своих клиентов. В качестве сервера базы данных будем использовать выделенный сервер MS SQL сервер.

Shema-pervichnogo-i-vtorichnogo-wsus-servera.png

Реализация

На территории центрального офиса развернем Windows Server 2012 R2 с ролью служба Windows Server Update Service (WSUS), для этого в диспетчере серверов необходимо выбрать установку роли и компоненты.

Windows-server-2012-R2-dobavit-roli-i-komponenty.png

Тип установки: установка ролей или компонентов.

Windows-server-2012-R2-ustanovka-rolej-i-komponentov.png

Выберем локальный сервер, на котором разворачиваем роль WSUS сервера.

Windows-server-2012-R2-vybor-servera.png

Установим галку напротив службы Windows Server Update Service.

Windows-server-2012-R2-sluzhba-Windows-Server-Update-Service.png

Добавим необходимые компоненты.

Windows-server-2012-R2-dobavit-komponent.png

Нажимаем Далее.

Windows-server-2012-R2-roli-servera.png

На этапе выбор компонентов необходимо отказаться от установки внутренней базы данных Windows.

Windows-server-2012-R2-vnutrennya-baza-dannyh-Windows.png

Удалим компоненты.

Windows-server-2012-R2-udalit-vnutrennyuyu-bazu-dannyh-Windows-.png

На скриншоте ниже, мы видим, что компонент внутренняя база данных Windows не будет установлена. Нажимаем Далее.

Windows-server-2012-R2-ustanovka-wsus.png

На экране службы ролей предлагается на выбор две базы данных. Одна из них WID Database и База данных. WID Database не что иное, как Windows Internal Database — один из вариантов SQL Server Express 2005, входящий в состав Windows Server 2008, а также поставляемый с некоторыми другими бесплатными продуктами Microsoft. Так как мы, согласно нашей архитектуре, планируем использовать внешнюю базу выберем База данных.

Windows-server-2012-R2-baza-dannyh-wsus.png

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

Windows-server-2012-R2-hranilishhe-obnovlenij.png

На этапе экземпляр БД укажем адрес SQL сервера и нажмем клавишу проверка подключения.

Windows-server-2012-R2-vneshnij-sql-server.png

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

Windows-server-2012-R2-proverka-podklyucheniya-sql.png

Дополнительных настроек или установки компонентов служба ролей Веб-сервер не требует, поэтому просто нажмем Далее.

Windows-server-2012-R2-iis.png

Насладимся процессом установки……

Windows-server-2012-R2-protsess-ustanovki-wsus.png

После чего нажмем кнопку Закрыть.

Windows-server-2012-R2-ustanovka-zavershena.png

И перейдем к настройке первичного сервера обновлений.  Для этого откроем средства, и из выпадающего списка выберем служба Windows Server Update Service.

Windows-server-2012-R2-zapusk-posleustanovochnyh-zadach.png

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

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

Настройка подчиненного сервера

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

Windows-Server-Update-Services-podchinennyj-server.png

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

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

Windows-Server-2012-R2-podchinennyj-server.png

Итог

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

Используемые источники:

  • https://smearg.wordpress.com/2011/09/02/развёртывание-локального-сервера-об-4/
  • https://habr.com/post/414751/
  • https://blog.eaglenn.ru/razvorachivaem-server-obnovlenij-wsus-v-bolshoj-kompanii/

Рейтинг автора
5
Подборку подготовил
Максим Уваров
Наш эксперт
Написано статей
171
Ссылка на основную публикацию
Похожие публикации