Я использую стороннее приложение на 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-адреса?
Если вы делаете регулярные резервные копии, вы можете попробовать восстановить копию файла метабазы IIS, которая была до внесения изменений. Для этого есть справочник по товарам - techNet Вот. Сначала вам нужно восстановить файл с ленты, а затем поместить его в место, где вы можете получить к нему доступ, чтобы восстановить его в IIS. Сделайте резервную копию текущего файла первый
Настройки повторного использования не должны вызывать этого - хотя они, вероятно, активировали изменение конфигурации, сделанное ранее.
Похоже, вам не хватает сопоставления сценариев с подстановочными знаками для ASP.Net, и для сопоставления сценариев с подстановочными знаками следует включить параметр «Проверить, существует ли файл». Приложение, вероятно, поставлялось с инструкциями для этого как часть его первоначальной настройки, но можно переопределить эти настройки на уровне приложения, а также на сайте.
Предложение uSlackr восстановить метабазу из старой резервной копии - это хорошо (и не забывайте историю конфигурации), в противном случае вы можете сравнить метабазу.xml со старым, и особенно сосредоточиться на картах сценариев и связанных настройках, на каждом уровне вы увлекающийся.
(Я отвечаю на свой вопрос, потому что, следуя ответам, полученным от uSlackr и TristanK, я смог выяснить, как изменение настроек конфигурации могло вызвать столько хаоса.)
Статья, на которую указал uSlackr, была ключевой. Я не понимал, что автоматическое резервное копирование выполняется каждый раз, когда вы меняете конфигурацию. К сожалению, со всеми настройками, которые я сделал, чтобы попытаться вернуть все на место, автоматическое резервное копирование, когда что-то работало, было перезаписано. Однако я смог выполнить восстановление из резервной копии, используя инструкции для ручного восстановления (без необходимости восстанавливать множество ненужных файлов).
Я почти уверен, что сделал неправильно, так это изменил настройку в корне веб-сайта, а затем сказал «да», когда он спросил, нужно ли перезаписать все, что ниже. Я думал, что он просто изменит этот параметр (например, тайм-аут), но на самом деле он перезаписал карты сценариев на более низких уровнях пробелами. Эти карты сценариев включали обработчик подстановочных знаков, поэтому этот URL сломался. Извлеченные уроки: изменять что-либо на соответствующем уровне, восстанавливать из резервных копий, когда изменение конфигурации нарушает работу.