Настройка wsus windows server 2019

Обновлено: 06.07.2024

Microsoft разработала Windows Server с целью упрощения задач управления, контроля и администрирования, поскольку благодаря своим ролям и услугам ИТ-администраторы получают универсальную, масштабируемую и простую систему конфигурации для расширения. решительно цели организации.

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

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

Таким образом, WSUS - это роль сервера Windows Server 2019, с которой в центральном пункте будет иметь возможность устанавливать, управлять и распространять обновления для всех компьютеров в домене, и, таким образом, это будет происходить автоматически, а не вручную. каждая команда

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

Централизованное управление обновлениями

Доступна автоматизация управления обновлениями

Имеет уровень конфиденциальности SHA256 для большей безопасности

У вас есть командлеты Windows PowerShell для управления десятью наиболее важными административными задачами в WSUS

Он предлагает разделение между клиентом и сервером, таким образом, версии агента обновления Windows (WUA) могут доставляться независимо от WSUS без необходимости применять их ко всем компьютерам.

Требования к оборудованию

Имеет процессор x64 с тактовой частотой 1, 4 ГГц, хотя рекомендуется использовать частоту 2 ГГц или более

WSUS требует дополнительно 2 ГБ минимальной оперативной памяти для Windows Server 2019.

Свободное место на диске 10 ГБ и рекомендуется 40 ГБ для размещения загруженных обновлений

Сетевой адаптер 100 Мбит / с или выше

1. Установите и используйте WSUS на Windows Server 2019

У администратора сервера нажмите на строку «Добавить роли и функции», расположенную на панели.

В диспетчере сервера перейдите в меню «Управление» и там выберите «Добавить роли и функции».

Шаг 2
Будет отображен следующий мастер:

Шаг 3
Там у нас есть краткое введение о действиях, которые мы можем выполнить, мы нажимаем Далее и в следующем окне активируем поле «Установка на основе функций или ролей»:

Шаг 4
Далее мы выбираем сервер, на котором должна быть установлена роль WSUS:

Шаг 5
Нажав кнопку «Далее» в окне «Роли сервера», мы находим строку «Службы обновления Windows Server»:

Шаг 6
При активации поля появится следующее всплывающее окно, где мы нажимаем кнопку «Добавить функции»:

Шаг 7
Мы видим, что окно WSUS активировано:

Шаг 8
Нажмите Далее и откроется окно «Функции», где мы можем активировать, если необходимо, некоторые дополнительные функции для сервера:

$config[ads_text6] not found

Шаг 9
В случае WSUS никакая функция не требуется, поэтому нажмите Next, и теперь мы увидим сводку о роли WSUS:

Шаг 10
Нажав Далее, мы увидим окно служб роли, где у нас будут следующие параметры:

WID Connectivity: это служба, которая отвечает за установку базы данных WID.

Службы WID. Это служба, которая отвечает за управление всеми службами WSUS.

Шаг 12
Как только мы активируем эти поля, которые уже выбраны по умолчанию, нажмите Next, и мы увидим следующее. Там мы должны активировать поле «Хранить обновления в следующем местоположении», чтобы определить маршрут, локальный или удаленный, где загруженные обновления должны быть размещены для последующего администрирования. Вверху мы видим, что требуется, чтобы этот маршрут был с NTFS файловая система и достаточно места.

Шаг 13
Как только путь к хранилищу определен, нажмите «Далее», и мы увидим следующую сводную информацию о ролях веб-сервера IIS (Internet Information Services):

Шаг 14
Нажмите Далее, и мы можем активировать ящики с необходимыми ролями:

Шаг 15
При определении этих ролей нажмите Далее, и мы увидим сводку ролей, которые будут установлены в Windows Server 2019:

Шаг 16
Нажмите «Установить», чтобы начать процесс установки WSUS на Windows Server 2019:

Шаг 17
После завершения установки мы увидим следующее:

СТАТЬЯ ПО ТЕМЕ Как отключить предложения Safari на Mac

В случае Safari, интегрированного браузера macOS High Sierra, предложения активны по умолчанию, и сегодня мы научимся отключать их простым способом.

Процессор: процессор x64 с тактовой частотой 1,4 ГГц (рекомендуется 2 ГГц или более быстрый)
Память: WSUS требует на 2 ГБ ОЗУ больше, чем требуется серверу и всем остальным службам или программному обеспечению.
Доступное дисковое пространство: 10 ГБ (рекомендуется 40 ГБ или более) реально 200-450гб
Сетевой адаптер: 100 мегабит в секунду (Мбит / с) или выше

6.1)>Диспетчер серверов добавим целевой сервер MSK01-SRV01

6.2)Диспетчер серверов\ Все серверы на MSK01-SRV01 нажмём добавить роли и компоненты

6.3)Выбор целевого сервера

6.4)Выбор ролей сервера, Добавляем роли сервера Сдужбы Windows Server Update Services

Через Windows Admin Center

powershell

7)Запуск консоли wsus.msc Средства администрирования службы Windows Server Update Services

7.2)Настройка прокси-сервера для доступа в сеть интерне

7.4)Выбор классов : Критические обновления ,Обновления системы безопасности

7.6)Запустить первоначальную синхронизацию

8)Creating WSUS Computer Groups and Setting up Group Policy

8.1)Update Services создаём группу компьютеров

8.2)Консоль dsa.msc Active Directory – пользователи и компьютеры

создаём OU Servers , и перемещаем в неё объект MSK01-SRV02

8.3)Консоль управление групповой политикой gpmc.msc

Создаём политику Servers на OU Servers

Enable client-side targeting (Разрешить клиенту присоединение к целевой группе):

9)Выполним обновления политики в Windows и отчет результата

Применённые объекты групповой политики (Applied Group Policy Objects)

10)Утверждение обновлений Approving WSUS Updates

параметры\Автоматические утверждения\Создать правило

10.1)Ручное утверждение обновлений , выделить тип обновления , фильтр Утверждение: не утверждено

выделить , Утвердить, выбрать группу компьютеров ServerS , установить OK

11) Windows defender ОБНОВЛЕНИЯ

Параметры, продукты и классы

12)wsus client fix cmd

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

08.02.2019

Групповые политики

комментариев 50

В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.

Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).

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

В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers. Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).

Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.

Групповая политика WSUS для серверов Windows

Начнем с описания серверной политики ServerWSUSPolicy.

Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).

В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля PSWindowsUpdate) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:

Enable

. 3 – Auto

download

and

notify

for

install

(Автоматически загружать обновления и уведомлять об их готовности к установке)

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

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).

Совет. Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).

Назначаем политики WSUS на OU Active Directory

Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).

Совет. Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций), в больших распределенных доменах можно привязывать различные WSUS сервера к сайтам AD, или же назначать GPO на основании фильтров WMI, или скомбинировать перечисленные способы.

Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.

Совет. Не забудьте про отдельную OU с контроллерами домена (Domain Controllers), в большинстве случаев на этот контейнер следует привязать «серверную» политику WSUS.

Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.

Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:

Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.

Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://srv-wsus.winitpro.ru:8530"
"WUStatusServer"="http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000 –
"AUOptions"=dword:00000003
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:00000003
"ScheduledInstallEveryWeek"=dword:00000001
"UseWUServer"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001

Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.

И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.

Примечание. Если на клиенте обновления не появляются, рекомендуется внимательно изучить на проблемном клиенте лог службы обновлений Windows (C:\Windows\WindowsUpdate.log). Обратите внимание, что в Windows 10 (Windows Server 2016) используется другой формат журнала обновлений WindowsUpdate.log. Клиент скачивает обновления в локальную папку C:\Windows\SoftwareDistribution\Download. Чтобы запустить поиск новых обновлений на WSUS сервере, нужно выполнить команду:

Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:

wuauclt /detectnow /resetAuthorization

В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.

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

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

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

Про настройку 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. Подойдет практически любой GNU\Linux дистрибутив, но примеры команд я буду приводить для Ubuntu Server (так исторически сложилось).

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

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

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

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

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

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

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

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

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

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

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

Название	Значение	Описание
category_names	Application Connectors CriticalUpdates DefinitionUpdates DeveloperKits FeaturePacks Guidance SecurityUpdates ServicePacks Tools UpdateRollups Updates	Категория обновлений.
whitelist	Номер обновления или шаблон имени.	Непосредственно номер устанавливаемых обновлений вида KB01234 или шаблон имени в виде регулярного выражения PowerShell.
blacklist	Номер обновления или шаблон имени.	Непосредственно номер обновлений, которые не нужно устанавливать, вида KB01234 или шаблон имени в виде регулярного выражения PowerShell.
reboot	yes no	Требуется ли перезагрузка после обновления.
reboot_timeout	секунды, 1200	Сколько времени ждать машину после перезагрузки.
state	installed searched	Устанавливать ли обновления, или только искать.
log_path	путь к файлу	Журнал установки, при этом папка должна существовать.

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

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

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

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

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

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

Внимательный читатель может спросить про источник скачиваемых обновлений. Источник будет тот, что настроен на компьютере: будь то 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.

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

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