Wsus windows server 2012 r2 ошибка http

Обновлено: 04.07.2024

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

Наш предыдущий материал рассматривал установку WSUS на платформе Windows Server 2008, тогда это была довольно непростая задача для неподготовленного администратора. Требовалось установить дополнительные пакеты, специальным образом настроить веб-сервер, да и сами службы WSUS устанавливались как отдельное приложение.

Начиная с Windows Server 2008 R2, WSUS был включен в состав ОС в качестве одной из ролей, поэтому, несмотря на то, что мы будем рассматривать платформу Windows Server 2012 R2, все сказанное, за незначительными поправками, будет справедливо и для Server 2008 R2.

Из сторонних пакетов потребуется установить только Microsoft Report Viewer 2008 SP1 Redistributable, однако он не является обязательным и на работу службы не влияет, а требуется только для формирования отчетов. Поэтому даже если вы забудете его установить - ничего страшного не произойдет, при первом обращении к отчетам система сообщит вам об этом и даст ссылку на скачивание.

Важно! Существует ряд ограничений на установку служб ролей WSUS. Сервер БД WSUS не может быть контроллером домена, Сервер WSUS не может быть одновременно сервером терминалов Remote Desktop Services.

Для установки WSUS откроем Диспетчер серверов и перейдем в Управление - Добавить роли и компоненты. В открывшемся мастере добавляем роль Службы Windows Server Update Services.

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

В качестве хранилища по умолчанию WSUS предлагает использовать внутреннюю базу данных Windows (Windows Internal Database, WID). Для небольших внедрений мы не видим смысла в установке отдельного SQL-сервера, никаких существенных преимуществ это не даст.

Следующим шагом переходим к базовым настройкам служб роли. В нашем случае потребуется выбрать опции WID Database и WSUS Services, если вы собираетесь использовать SQL-сервер, то вместо WID Database следует выбрать опцию База данных. Сам сервер баз данных к этому моменту уже должен быть развернут в вашей сети.

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

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

Для приблизительной оценки требуемого места приведем данные с одной реальной инсталляции, произведенной летом 2012 года. На текущий момент выбраны следующие продукты: все клиентские ОС от Windows XP до Windows 8.1, кроме Vista, все серверные ОС от Server 2003 до Server 2012 R2, Office 2010, Exchange 2010, SQL Server 2008 - 2012, а также ряд дополнительных продуктов из разряда Распространяемых пакетов Visual C++ и т.п.

Размер обновлений в хранилище на текущий момент (два года после установки) - 173 ГБ, размер SQL базы данных - около 10 ГБ.

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

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

Если коротко, то сначала нужно выбрать источник синхронизации: сервера Microsoft или вышестоящий WSUS сервер.

Затем выбрать языки и продукты.

Указать классы обновлений.

И задать параметры автоматической синхронизации.

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

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

После чего потребуется сообщить клиентам расположение вашего WSUS сервера, это можно сделать через групповые политики: Конфигурация компьютера - Политики - Административные шаблоны - Центр обновления Windows - Указать размещение службы обновлений Microsoft в интрасети.

Или в локальных политиках: Пуск - Выполнить - gpedit.msc, затем Конфигурация компьютера - Административные шаблоны - Центр обновления Windows (Windows Update)- Указать размещение службы обновлений Microsoft в интрасети.

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

Если на сервере с ОС Windows Server 2012 R2 и установленной ролью Windows Server Update Services (WSUS) в конфигурации веб-сервера IIS помимо сайта WSUS Administration имеются какие-либо другие сайты, то после удаления роли WSUS эти сайты могут перестать работать. Рассмотрим эту проблему и способ её решения.

После выполнения стандартной процедуры удаления роли WSUS через консоль Server Manager замечено, что все сайты, работающие на базе веб-сервера IIS перестали штатно работать, возвращая всем клиентам, подключающимся из локальной сети, ошибку " 500 - Intenal server error "

Чтобы получить больше информации об ошибке, выполняем открытие сайта локально на самом веб-сервере и видим, что ошибка 500.19 связана с модулем сжатия DynamicCompressionModule и имеет код 0x8007007e

Иногда при решении подобного рода проблем дополнительную ясность может дать получение описания кода ошибки. Полученный в нашем случае код ошибки 0x8007007e можно попробовать расшифровать штатными инструментами Windows:

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

с помощью PowerShell, например так:

В нашем случае первый вариант не дал результата, зато метод с использованием PowerShell вернул описание кода ошибки.

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

После дальнейшего изучения ситуации стало очевидно, что роль WSUS после удаления оставила в системе немало "мусора". В частности в IIS не был удалён сайт WSUS Administration и связанный с ним пул приложений WsusPool, а виртуальные каталоги этого сайта ссылались на уже несуществующие в системе файловые пути. Ручное удаление этих "ошмётков" из консоли IIS Manager не купировало проблемы с 500 ошибкой веб-сервера.

Далее по совету страницы с подробным описанием ошибки мы заглянули в конфигурационный файл applicationHost.config , расположенный в каталоге C:\Windows\System32\inetsrv\config .

Обнаружилось, что в разделе глобальной конфигурации хоста configuration > system.webServer > httpCompression присутствует объект типа scheme с именем " xpress ", ссылающийся на уже несуществующую в системе библиотеку C:\Program Files\Update Services\WebServices\suscomp.dll

Судя по всему, это тот самый проблемный модуль сжатия, на отсутствие которого ругается веб-сервер IIS.

System.Data.SqlClient.SqlException (0x80131904): Не удалось выполнить вход. Имя входа принадлежит недоверенному домену и не может использоваться в проверке подлинности Windows.

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

Вопрос задан более трёх лет назад
11362 просмотра

Оценить 1 комментарий

по адресу %windir%\wid\data\ отсутствует база данных SUSDB.mdf

сказано же MS не используйте на DC 2012r2 роль wsus

В случае, установки роли WSUS и сервера БД на разных серверах, существует ряд ограничений:

Сервер БД WSUS не может быть контроллером домена
Сервер WSUS не может быть одновременно сервером терминалов Remote Desktop Services

дело в том, что база данных SUSDB.mdf отсутствует в папке C:\Windows\WID\Data

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

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

в топике же написано :)
System.Data.SqlClient.SqlException (0x80131904): Не удалось выполнить вход. Имя входа принадлежит недоверенному домену и не может использоваться в проверке подлинности Windows.

На чем хранить БД WSUS?
Проверьте права на базу wsus.

Попробуйте перезапустить службу Windows Internal Database , и убедиться чтобы стартанула служба wsus.

System – Полный доступ;
Network Service – Полный доступ;
Администраторы – Полный доступ;
Пользователи – Чтение и выполнение.

System – Полный доступ;
Network Service – Полный доступ;
Администраторы WSUS – Полный доступ;
Администраторы – Полный доступ;
Пользователи – Чтение и выполнение.

Разрешения SMB:
Network Service – Полный доступ;Администраторы - Полный доступ; Администраторы WSUS - Полный доступ; Все - Чтение.

Разрешения SMB:
Network Service – Полный доступ; Администраторы - Полный доступ; Администраторы WSUS - Полный доступ; Все - Чтение.

Во время регулярного утверждения обновлений на WSUS я столкнулся с ошибкой WSUS. Мы используем сервер Windows Server 2012 R2 со средой WSUS 3.0.

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

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

Я также заметил, что служба WSUS не была запущена. Программа просмотра событий показала мне код события: ошибка 7053.

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

C: \ Users \% имя пользователя% \ AppData \ Roaming \ Microsoft \ MMC \ WSUS

Не удается подключиться к «% Servername%». Сервер SQL может не работать на сервере. Убедитесь, что SQL Server работает и правильно настроен на сервере. Обратитесь к администратору сети, если проблема не устранена.

После дальнейшего расследования я обнаружил, что Microsoft патч KB3148812 был виновником здесь, так как он обеспечивает предоставление расшифровки ESD в WSUS. Таким образом, удаление KB3148812 и перезагрузка сервера должны помочь. Кроме того, тем временем Microsoft выпустила KB3159706, который заменит патч KB3148812.

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

Итак, вот что помогло в моем случае:

Открыть надземный командная строка (CMD)

Перейдите к: C: \ Program Files \ Update Services \ Инструменты \

Запустите следующую команду:

wsusutil.exe /постустановочных / обслуживание

Как только вы получитеуспешно завершено»Откройте Диспетчер серверов и установите следующую функцию:

Это дополнительно установит Модель процесса службы активации Windows.

После успешной установки перезапустите службу WSUS, и вы сможете нормально открыть консоль WSUS.

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