Если на сервере с ОС 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, например так:
net helpmsg 0x8007007e
- с помощью PowerShell, например так:
[ComponentModel.Win32Exception]0x8007007e
В нашем случае первый вариант не дал результата, зато метод с использованием 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.
Удаляем строку, описывающую проблемную схему "xpress", оставив только схему "gzip" с вызовом имеющейся в системе библиотеки gzip.dll и сохраняем изменения в файле.
Сразу после этого сайты в IIS заработали, как ни в чём не бывало.
Вот такой вот нежный IIS и такой вот злой WSUS :)
RSS - Записи
Спасибо огромное, рецепт сработал чудодейственно.
Все сработало. Топ решение !
Спасибо, помогло, даже не знал куда копать.
Спасибо тебе! Спас!
Спасибо огромное. Я даже не знал куда копать)
Большое спасибо что поделился своим решением!
Раньше помогало удаление остаточных узлов от WSUS.
А с косячным модулем компресии в конфиге iis это что-то новенькое)
Спасибо, добрый человек!
Парни, вы лучшие.
В англоязычном сегменте обсасывают ошибку, пересоздают сайты, приложения, а надо строчку из конфига удалить.
У меня после удаления WSUSа консоль управления почты перестала работать. Хорошо хоть сама почта ходила. Восстановил.
У меня консоль управления Exchange отвалилась после удаления WSUS. Она тоже коннектится через IIS. Восстановил.
Спасибо!!!
Большое спасибо за статью , пригодилась !!
Спасибо добрый человек!
Столкнулся с точно такой же историей не при удалении WSUS, а при его развёртывании.
Думал, что одинэсники, чьи обмены настроены на IIS, меня сожрут.
Восстановил им работоспособность именно таким образом. Как потом WSUS будет работать - поэкспериментирую после.