Wsus импорт обновлений вручную из файла
Обновлено: 02.07.2024
Итак цель написания данного опуса - это установка, настройка и обновление сервера обновлений, а также возможность переноса баз и файлов обновлений с помощью переносного жесткого диска или при помощи ноутбука, с установленной W2003 + WSUS.
Есть еще WSUS FAQ. Стоит почитать - очень рекомендую.
Содержание
Установка WSUS 3.1
Серер может устанавливаться только на сервера W2003 или выше.
Синхронизация с сервера Microsoft
Если у Вас это первый сервер WSUS, то сначала надо загрузить для него файлы с сервера Microsoft.
Для этого:
Идем в Параметры и запускаем Мастер настройки сервера Wsus и с помощью его настраиваем наш сервер для получения обновлений с сервера Microsoft.
Я остановлюсь только на ключевых моментах данной настройки.
- Во вкладке Выбор вышестоящего сервера выбираем Синхронизировать с Microsoft Update.
- Если не используется прокси сервер, то следующую вкладку можно пропустить.
- В следующей вкладке пробуем подключиться к серверу.
- После подключения, в следующей вкладке, выбираем языки обновлений. Обычно Английский и Русский. Я для себя выбрал только Русский, и объем выкачанный апдейтов составил около 20Гб.
- Далее выбираем Программные продукты, которые поддерживаются Microsoft и на которые можно получать обновления.
Вобщем настраиваем все по порядку - вроде ничего сложного нет и все понятно.
После настройки в назначенное Вами время произойдет синхронизация с сервером Microsoft и будут выкачаны все обновления для тех продуктов и языков, которые Вы указали.
Синхронизация с сервера WSUS
Можно новый сервер синхронизировать с другого сервера WSUS.
Для этого:
- Во вкладке Выбор вышестоящего сервера выбираем Синхронизировать с другим сервером Windows Server Update Services и указываем имя и порт сервера, с которого мы будем брать обновления и жмем далее.
- Пропускаем вкладку по настройке прокси сервера.
- В следующей вкладке жмем Начать подключение и когда станет активной кнопка Далее, жмем ее.
- Жмем Далее до Настройка рассписания синхронизации и выбираем Синхронизировать вручную (Вообще тут Вы можете установить, что хотите. Синхронизация с помощью данного режима хоть и самая простая, но занимает намного больше времени).
Вот и все с этим режимом.
Перенос баз WSUS копированием файлов
Можно перенести файлы базы данных и апдейтов, простым копированием с рабочего сервера WSUS.
Копирования файлов с сервера
Копирование файлов на новый сервер
Переназначение пути к файлам обновлений
Если имена папок или дисков WSUS на рабочем сервере и на новом совпадают, тогда ничего больше делать не нужно, если нет, то изменяем место хранения файлов обновлений WSUS:
Где g:\WSUS путь до WSUS на новом сервере.
После этого надо зайти в программу, удалить все старые группы и сами компьютеры и создать новые.
Это самый простой и быстрый способ переноса сервера WSUS.
Перенос базы данных с помощью утилиты wsusutil.exe
Перенос состоит из двух частей:
Перенос базы данных
1. Поднять новый сервер wsus 2. Экспортировать БД на "старом": 3. Перенести на "новый" директорию с обновлениями 4. Импортировать БД на "новом"
Перенос файлов обновлений
1. Скопировать файлы из директории WSUS\WsusContent старого сервера в одноименную директорию нового 2. Если имена дисков и папок на старом и новом сервере совпадают, то делать больше ничего не нужно. 3. Если нет, то изменяем место хранения файлов обновлений WSUS (может и не нужно, но хуже не будет.): Где g:\WSUS путь до WSUS на новом сервере. 4. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый серверОдобрение обновлений
После переноса базы и файлов нужно настроить WSUS.
Для этого надо создать группы компьютеров для обновлений и одобрить все обновления (после переноса базы через wsusutil.exe, все обновления на новом сервере не одобрены)
Недостатки метода
У меня после переноса базы таким способом, некоторые обновления почему то отметились, как не выкачанные, а так качать было уже неоткуда, то они устанавливаться не будут.
Запуск обновлений на клиентах, которые не подключены к домену
С помощью групповых политик
C помощью reg файла
Создаем reg файл, например swus.reg
Надо только поменять параметры WUServer и WUStatusServer и запустить его на клиенте в сети.
Как удалить WSUS, если он не запускается, и процедура uninstall не работает
Предыстория
Устанавливал я WSUS 3.0 SP1 и, после переноса вручную баз,случилась беда - он перестал запускаться. И самое смешное, что процедура стандартного удаления, не работала - вылетала с ошибкой. Я очень долго мучался при удалении WSUS вручную. Улалил все файлы, почистил клинером реестр. Потом вручную из реестра удалял все ссылки на WSUS и Uptate Services. Но все равно при попытке установить WSUS заново, выскакивали ошибки и у меня ничего не получалось.
Тут я наткнулся на замечательную инструкцию в форуме по удалению WSUS. Естественно проверил на опытной машине - все замечательно отработало. Привожу это описание ниже с моим кривым переводом
Ручное удаление WSUS
1. Выкачайте и установите Windows Installer Clean Up, что бы получить MSIZAP.
Вообще данное средство может быть использовано для удаления остатков программ. Более подробно можно прочитать тут.
2. Из командной строки наберите:
3. Из командной строки наберите:
4. Снова, Из командной строки наберите:
5. Из командной строки наберите:
Ключ "T", при запуске MSIZAP, удаляет всб информацию для данного кода продукта, те для For WSUS 3.0:
Для Microsoft SQL Server 2005 Embedded Edition
Если папка \MSSQL\Data заблокирована, Вы можете удалить "Windows Internal Database" из Установка и удаление программ Панели управления.
Не все фиксы, исправления и обновления для продуктов Microsoft доступны для установки в консоли Windows Server Update Services WSUS. Например, у вас в настройках может быть отключена синхронизация обновлений для определенного продукта, версии Windows или класса обновлений. Также в консоли WSUS отсутствуют обновления, которые предназначены для решения конкретной проблемы и не подразумевают массовой установки всем пользователям. Однако, если вы можете вручную добавить (импортировать) во WSUS или SCCM (Configuration Manager) любое обновление, доступное в каталоге обновлений Microsoft (Microsoft Update Catalog).
Импорт обновления во WSUS с помощью Internet Explorer
Таким образом на WSUS сервер можно импортировать любые обновления из каталога Microsoft, в том числе драйвера, Service Pack, Feature Packs и т.д.
Ошибки импорта обновлений и драйверов во WSUS
В WSUS запущенном на Windows Server 2019/2016 при импорте обновлений вы можете столкнуться с ошибкой:
Должна получиться примерно такая ссылка:
Добавление обновление во WSUS с помощью PowerShell
Вы можете добавить обновления на сервер WSUS с помощью PowerShell. Для этого нужно скачать файл обновления из каталога обновлений Microsoft и получить его GUID.
Найдите нужную вам KB в консоли WSUS и щёлкните по его названию. Откроется веб страница с описанием обновления. Скопируйте значение updateid, скачайте MSU файл обновления на локальный диск.
Подключитесь к серверу WSUS из консоли PowerShell:
$WsusSrv = Get-WsusServer (если вы запустили консоль PowerShell непосредственно на сервере WSUS)
$WsusSrv = Get-WsusServer -Name msk-wsus -PortNumber 8531 –UseSsl (если вы подключаетесь к серверу WSUS удаленно)
Теперь можно добавить скачанное обновление на WSUS. Используется следующая команда импорта:
Можно проверить, что обновление импортировано успешно:
Просмотреть информацию про обновление можно так:
При импорте обновления через PowerShell может появится ошибка:
Здесь также причина в том, что PowerShell пытается установить подключение к сайту через TLS 1.0, которое блокируется сервером WSUS. Для решения проблемы нужно добавить параметр SchUseStrongCrypto на сервере WSUS (и перезагрузить его):
После этого импорт обновления на сервер WSUS из PowerShell будет работать корректно.
До недавнего времени я работал эникейщиком в крупной российской компании, имеющей множество офисов по всей стране. В моём ведении были одиннадцать площадок, находящихся в разных городах Дальнего востока (это важно). В каждом из этих офисов была своя, не связанная с другими, сетевая инфраструктура — свой домен 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), да и сам код, наверняка, далёк от идеала.
Однако поставленная задача была успешно решена, а практика, как известно, — критерий истины. Надеюсь, описанное решение пригодится еще кому-нибудь.
Начиная с июля 2020 г. у пользователей возникли проблемы синхронизации и импорта WSUS с конечными точками обновления Windows (WU) или Microsoft Update (MU).
В этой статье описывается устранение некоторых распространенных проблем. Некоторые из этих методов устранения неполадок (например, захвата сети) можно использовать и для многих других проблем.
Конечные точки
В настоящее время WSUS использует следующие конечные точки для синхронизации метаданных:
Большинство серверов WSUS должны синхронизироваться с этой новой конечной точкой. Начиная с июля 2020 г. эта конечная точка принимает только подключения безопасности транспортного слоя (TLS) 1.2. Некоторые шифры были отключены.
Эта старая конечная точка будет в конечном итоге списана. Дополнительные сведения см. в рублях End of synchronization for WSUS 3.0 SP2. Эта конечная точка поддерживает подключения TLS 1.2, TLS 1.1 и TLS 1.0.
Эта старая конечная точка списалась с эксплуатации, подключение к ней завершится сбой.
При проблеме синхронизации WSUS или ручного импорта сначала проверьте конечную точку, с которой вы синхронизируете:
Откройте окно командной подсказки PowerShell на сервере WSUS.
Чтобы найти текущую конечную точку синхронизации, запустите следующий скрипт PowerShell:
Выпуск 1. Ручной импорт не удается, но синхронизация успешно
Многие пользователи импортируют обновления в WSUS вручную, а некоторые обновления необходимо импортировать вручную. Например, предварительные обновления, выпущенные в третью и четвертую недели месяца, должны импортироваться вручную. Начиная с конца июля 2020 г., возможно, вы не сможете импортировать обновления вручную.
Однако некоторые серверы WSUS могут успешно импортировать обновления. И обычная синхронизация с WU и MU продолжает работать.
Эта проблема возникает на серверах WSUS, которые работают Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 или Windows Server 2019.
Устранение неполадок 1
Проверьте файл %Program Files%\Update Services\LogFiles\SoftwareDistribution.log на ошибки при импорте обновлений вручную. И посмотрите на ошибки, похожие на следующий пример:
Существующее подключение было принудительно закрыто удаленным хостом.
На следующем скриншоте показан сетевой захват попытки подключения.
Разрешение проблемы 1
Эта проблема возникает из-за того, что функции импорта WSUS не могут использовать TLS 1.2.
Чтобы устранить эту проблему, используйте один из следующих методов:
Чтобы установить клавиши реестра, см. в перенастройке для сильной криптографии. Перезапустите сервер после набора ключей реестра.
Создайте или w3wp.exe.config файл, чтобы включить TLS 1.2.
Это изменение будет применяться w3wp.exe созданных экземпляров независимо от того, относятся ли они к WSUS. W3wp.exe TLS 1.2, если удаленная сторона поддерживает эту версию. Если включены TLS 1.1 и TLS 1.0, W3wp.exe согласовывать эти протоколы, если целевой сайт не поддерживает TLS 1.2.
Если файл %SystemRoot%\system32\inetsrv\w3wp.exe.config не существует, выполните следующие действия:
Создайте новый файл с именем W3wp.exe.config в %SystemRoot%\system32\inetsrv папке.
Откройте файл в текстовом редакторе, например Блокнот.
Добавьте в файл следующие строки и сохраните файл:
Если файл %SystemRoot%\system32\inetsrv\w3wp.exe.config уже существует, выполните следующие действия:
Откройте файл в Блокнот или другом текстовом редакторе.
Добавьте в элемент следующие строки <configuration> и сохраните файл:
После создания или обновления W3wp.exe.config откройте окно командной подсказки, а затем запустите для перезапуска iisreset всех рабочих процессов. Проверьте, работает ли ручной импорт.
Выпуск 2. Сбой ручного импорта после отключения TLS 1.1 или TLS 1.0
TLS 1.1 и TLS 1.0 постепенно отламывются, так как считаются небезопасными. После отключения этих протоколов вы больше не сможете импортировать обновления. Однако синхронизация продолжает работать.
Эта проблема возникает на серверах WSUS, которые работают Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 или Windows Server 2019.
Устранение неполадок 2
Журналы WSUS, в которых включены версии SSL/TLS при его старте. Чтобы определить версии SSL/TLS, выполните следующие действия:
Перезапустите службу WSUS.
Запустите iisreset по повышенной командной подсказке, чтобы заставить WSUS пройти последовательность запуска.
Откройте консоль WSUS и подключите ее к серверу.
Откройте, %Program Files%\Update Services\LogFiles\SoftwareDistribution.log и посмотрите записи, которые начинаются в протоколе SCHANNEL. Вы должны видеть записи, похожие на следующий пример:
Эти записи показывают, что отключены TLS 1.1 и TLS 1.0 и включен TLS 1.2.
Если процесс импорта не удается, softwareDistribution.log регистрирует следующую запись ошибки:
На следующем скриншоте показан сетевой захват попытки подключения.
WSUS закрывает подключение, так как все протоколы, которые он знает, как использовать для импорта (SSL3, TLS 1.0, TLS 1.1), отключены и не могут использовать TLS 1.2.
Разрешение проблемы 2
Эта проблема похожа на выпуск 1, в котором импорт WSUS не может использовать TLS 1.2. Чтобы устранить эту проблему, используйте решение проблемы 1.
Проблема 3. Сбой синхронизации на Windows Server 2012 и Windows Server 2012 R2 WSUS, которые применяют только обновления только для безопасности
Windows Server 2012 и Windows Server 2012 R2 содержат следующие треки обновления:
- Обновление только для безопасности, которое не является накопительным. Он содержит только исправления безопасности. Например, 9 июня 2020 г. — KB4561673 (обновление только для безопасности).
- Ежемесячный откат, который является накопительным. Он содержит все исправления безопасности из обновления только для безопасности, а также содержит исправления без обеспечения безопасности. Например, 9 июня 2020 г. — KB4561666 (ежемесячное докатка).
WSUS Windows Server 2012 и Windows Server 2012 R2 не может использовать TLS 1.2 для синхронизации, если не установлен один из следующих ежемесячных откатов или более позднего ежемесячного докатки:
-
версия ежемесячного докатки) для Windows Server 2012 версия ежемесячного докатки) для Windows Server 2012 R2
Изменение, которое позволяет WSUS использовать TLS 1.2, является исправлением без обеспечения безопасности, оно включено только в ежемесячные откаты.
Устранение неполадок 3
Если на сервере WSUS установлены правильные обновления, WSUS будет входить в журнал, какие версии SSL/TLS включены при его старте. Выполните следующие действия на сервере WSUS:
Перезапустите службу WSUS.
Запустите iisreset из командной подсказки повышенной высоты, чтобы заставить WSUS пройти последовательность запуска.
Откройте консоль WSUS и подключите ее к серверу.
Откройте %Program Files%\Update Services\LogFiles\SoftwareDistribution.log , поиск записей, которые начинаются с протокола SCHANNEL. Вы должны видеть записи, похожие на следующий пример:
Если вы не можете найти эти записи, это означает, что обновление, которое включает TLS 1.2, не установлено.
На следующем скриншоте показан сетевой захват попытки подключения.
Разрешение проблемы 3
Чтобы устранить эту проблему, установите последнюю ежемесячную откатку для Windows Server 2012 или Windows Server 2012 R2. Также применяем решение для выпуска 1, чтобы предотвратить сбой ручного импорта.
Выпуск 4. Сбой синхронизации после июля 2020 г., если WSUS интегрирован с Configuration Manager
Многие установки WSUS интегрированы с точками обновления Microsoft Endpoint Configuration Manager программного обеспечения (SUP). После июля 2020 г. могут возникнуть сбои в синхронизации, если диспетчер конфигурации настроен для синхронизации драйверов Surface.
Эта проблема возникает на серверах WSUS, которые работают Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 или Windows Server 2019.
Устранение неполадок 4
Когда возникает эта проблема, записи, похожие на следующий пример, регистрируются в Wsyncmgr.log:
Кроме того, %Program Files\Update Services\LogFiles\SoftwareDistribution.log в файле в журнале печатались следующие ошибки:
Эти ошибки указывают на то, что подключение было закрыто. Эта проблема возникает из-за того, что в диспетчере конфигурации используется функция импорта WSUS. Таким образом, он имеет те же ограничения.
Разрешение проблемы 4
Выпуск 5. Синхронизация не удается после июля 2020 г. из-за ограниченных шифров
Эта проблема возникает на серверах WSUS, которые работают Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 или Windows Server 2019.
Устранение неполадок 5
При синхронизации в файле регистрируются следующие %Program Files\Update Services\LogFiles\SoftwareDistribution.log ошибки:
Однако эти записи не являются полезными для определения того, есть ли у вас проблемы с шифром.
В этой ситуации используйте захват сети или проверьте объекты прикладной групповой политики (GPOs). Чтобы проверить применимые GPOs, запустите следующую команду по повышенной командной подсказке:
Откройте GPReport.html в браузере.
Поиск SSL Cipher Suite Order и параметр SSL Cipher Suites. Обычно этот параметр не настроен. Если она настроена, может возникнуть проблема, так как нет общего шифра с WU/MU.
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Со временем этот список изменится, так как по мере улучшения технологии шифры будут постепенно слабеть.
Если GPO применяется, и он не указывает один из этих шифров, связь с WU/MU не удается.
На следующем скриншоте показан захват сети.
Разрешение проблемы 5
Для устранения данной проблемы выполните следующие действия.
Для Windows Server 2016 и Windows Server 2019 включим один из следующих шифров:
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Для Windows Server 2012 2012 r2 включаем один из следующих шифров:
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
Если шифры не установлены GPO, найдите следующий подкай реестра:
Добавьте один из необходимых шифров в значение Functions ключа реестра.
Перезапустите сервер WSUS.
Чтобы предотвратить сбои ручного импорта, также применяем решение для проблемы 1.
Успешное подключение
На следующих скриншотах покажите успешное подключение, Windows Server 2016 WSUS-сервер синхронизирует обновления.
В сетевом захвате кадр 191 — это пакет Client Hello, использующий TLS 1.2. В кадре подробно показано, какие шифры были отправлены клиентом. Frame 195 — это пакет Server Hello с конечной точки. TLSCipherSuite, выбранный wu, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Сертификат сервера также отправляется в пакете Server Hello.
Примечание о прокси-серверах
При использовании прокси-сервера необходимо знать IP-адрес внутреннего интерфейса прокси-сервера, так как WSUS не взаимодействует напрямую с конечными точками WU. Если вы не можете получить IP-адрес прокси-сервера, поиск захвата сети для запросов CONNECT и поиск URL-адреса конечной точки Windows обновления.
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 и создаем задачу в планировщике. Чистку стоит делать раз в неделю.
Читайте также: