Alterações na configuração do IIS interrompem o aplicativo de terceiros

Question

Estou usando um aplicativo de terceiros criado no asp.net. Ele é executado no Server 2003 / IIS6. Alterei a maneira como os pools de aplicativos são reciclados. Depois disso, o aplicativo de terceiros parou de funcionar. Especificamente, as URLs que não correspondem aos arquivos no diretório do programa de terceiros retornaram erros 404.

(Eu não estou tão atualizado sobre como o asp.net funciona.) O que quero dizer é que, se eu for para uma URL como example.com/thirdparty/page.aspx , quando houver um arquivo page.aspx no diretório do programa de terceiros , a página funciona. Se eu for para example.com/thirdparty/stylesheet6.css , quando não houver arquivo stylesheet6.css no diretório do programa, recebo um erro 404.

Ele parou de funcionar depois que fiz essa alteração nos pools de aplicativos, embora eu pudesse ter alterado outro aspecto da configuração do IIS por engano. Eu coloquei as configurações do pool de aplicativos de volta como eu acho que elas estavam, mas isso não resolveu isso.

A empresa para este software de terceiros sugere desinstalações, reinstalações e restaurações a partir do backup (basicamente, elas não têm a menor idéia do motivo da quebra), mas gostaria de desfazer o dano que causei porque isso pode ser mais fácil.

Que tipo de alterações na configuração do IIS eu poderia ter feito para quebrar esse tipo de URL?

    

Answer 1

(Eu estou respondendo a minha própria pergunta, porque seguindo as respostas dadas pelo uSlackr e TristanK eu fui capaz de descobrir como uma mudança na configuração poderia causar muito estrago.)

O artigo que a uSlackr apontou foi fundamental. Eu não sabia que backups automáticos eram feitos toda vez que você alterava uma configuração. Infelizmente, com todos os ajustes que fiz para tentar colocar as coisas de volta, o backup automático de quando as coisas estavam funcionando tinha sido substituído. No entanto, eu era capaz de restaurar a partir de um backup usando as instruções para uma restauração manual (sem precisar restaurar cargas de arquivos irrelevantes).

O que eu tenho certeza que fiz de errado foi mudar uma configuração na raiz do site e depois dizer sim quando perguntado se tudo abaixo deve ser substituído. O que eu pensei que iria fazer era apenas mudar essa configuração (por exemplo, um tempo limite), mas o que realmente fez foi substituir os mapas de script em níveis mais baixos com espaços em branco. Esses scriptmaps incluíam o manipulador de curinga, e é por isso que esse URL quebrou. Lições aprendidas: altere as coisas no nível apropriado, restaure a partir de backups quando uma alteração de configuração quebra as coisas.

    

Answer 2

Se você fizer backups regulares, poderá tentar restaurar uma cópia do arquivo da metabase do IIS antes das alterações. Há um guia de mercadorias para isso é techNet aqui . Você precisará recuperar o arquivo da fita primeiro e colocá-lo em algum lugar onde possa acessá-lo para restaurá-lo para o IIS. Backup do arquivo atual primeiro

    

Answer 3

As configurações de reciclagem não devem causar isso - elas provavelmente ativaram uma alteração de configuração feita anteriormente.

Parece que está faltando um mapeamento de script curinga para o ASP.Net, e uma configuração de "verificar arquivo existente" deve ser alternada para o mapa de script curinga. O aplicativo provavelmente foi enviado com instruções para isso como parte de sua configuração inicial, mas é possível redefinir essas configurações no nível do aplicativo e no site.

A sugestão do uSlackr para restaurar a metabase de um backup mais antigo é boa (e não se esqueça do histórico de configuração), ou você poderia comparar o metabase.xml com o antigo e focalizar particularmente os mapas de script e configurações relacionadas em cada nível você está interessado.