Изменения конфигурации IIS нарушают стороннее приложение
Я использую стороннее приложение, созданное на asp.net. Он работает на сервере 2003/IIS6. Я изменил способ утилизации пулов приложений. После этого стороннее приложение перестало работать. В частности, URL, которые не соответствуют файлам в каталоге сторонних программ, вернули 404 ошибки.
(Я не очень разбираюсь в том, как работает asp.net.) Я имею в виду, что если я перейду к URL example.com/thirdparty/page.aspxЕсли в каталоге сторонней программы есть файл page.aspx, страница работает. Если я пойду к example.com/thirdparty/stylesheet6.css, когда в каталоге программы нет файла stylesheet6.css, я получаю ошибку 404.
Он перестал работать после того, как я сделал это изменение в пулах приложений, хотя я мог по ошибке изменить какой-то другой аспект конфигурации IIS. Я вернул эти настройки пула приложений обратно, как я думаю, но это не исправило.
Компания, выпускающая это стороннее программное обеспечение, предлагает удалять, переустанавливать и восстанавливать из резервной копии (в основном, они понятия не имеют, почему она сломана), но я бы хотел отменить то, что я нанес, потому что это может быть проще.
Какие изменения в конфигурации IIS я мог бы сделать, чтобы сломать URL-адреса такого типа?
3 ответа
(Я отвечаю на свой собственный вопрос, потому что, следуя ответам, данным uSlackr и TristanK, я смог выяснить, как изменение настроек конфигурации может вызвать такой хаос.)
Статья, на которую указал uSlackr, была ключевой. Я не осознавал, что автоматическое резервное копирование выполнялось каждый раз, когда вы меняли конфигурацию. К сожалению, со всеми изменениями, которые я сделал, чтобы попытаться вернуть вещи обратно, автоматическое резервное копирование, когда все работало, было переписано. Однако я смог восстановить из резервной копии, используя инструкции для ручного восстановления (без необходимости восстанавливать множество ненужных файлов).
То, что я почти уверен, что сделал неправильно, это изменил настройку в корне сайта, а затем сказал "да", когда он спросил, следует ли перезаписать все, что ниже. То, что я думал, что это будет делать, это просто изменить эту настройку (например, время ожидания), но на самом деле он перезаписал карты сценариев на более низких уровнях пробелами. Эти сценарии включали в себя обработчик подстановочных знаков, поэтому эти URL не работали. Извлеченные уроки: изменить вещи на соответствующем уровне, восстановить из резервных копий, когда изменение конфигурации сломает вещи.
Если вы делаете регулярное резервное копирование, вы можете попытаться восстановить копию файла метабазы IIS до внесения изменений. Здесь есть руководство по товарам, это techNet здесь. Сначала вам нужно будет восстановить файл с ленты, а затем поместить его куда-нибудь, чтобы получить к нему доступ, чтобы восстановить его в IIS. Сначала сделайте резервную копию текущего файла
Переработка настроек не должна вызывать это - они, вероятно, активировали изменение конфигурации, сделанное ранее, хотя.
Похоже, вам не хватает сопоставления сценариев с подстановочными символами для ASP.Net, и для карты сопоставления сценариев должен быть включен параметр "Проверьте файл существует". Приложение, вероятно, поставляется с инструкциями для этого как часть его первоначальной настройки, но возможно переопределить эти настройки как на уровне приложения, так и на сайте.
Предложение uSlackr о восстановлении метабазы из более старой резервной копии - это хорошо (и не забывайте историю конфигурации), иначе вы можете сравнить файл metabase.xml со старой, особенно сосредоточившись на картах сценариев и связанных с ними настройках на каждом уровне, на котором вы работаете. увлекающийся.