I'm using a third party app build on asp.net. It runs on Server 2003/IIS6. I changed the way that app pools are recycled. After this happened the third party application stopped working. Specifically URLs that didn't correspond to files in the third party program directory returned 404 errors.
(I'm not that up to speed on how asp.net works.) What I mean is that if I go to a URL like example.com/thirdparty/page.aspx, when there is a page.aspx file in the third party program directory, the page works. If I go to example.com/thirdparty/stylesheet6.css, when there is no stylesheet6.css file in the program directory, I get a 404 error.
It stopped working after I did this change to the app pools, though I could have changed some other aspect of the IIS configuration by mistake. I've put those app pool settings back how I think they were, but that hasn't fixed it.
The company for this third party software suggests uninstalls and reinstalls and restoring from backup (basically they haven't a clue why it's broken) but I'd like to undo what damage I did because that might be easier.
What sort of changes to IIS configuration could I have done that would break these sort of URLs?
If you do regular backups, you could try restoring a copy of the IIS metabase file from before the changes. There is a goods guide to this is techNet here. You'll need to recover the file from tape first then put it somewhere you can access it to restore it to IIS. Backup the current file first
Recycling settings shouldn't cause that - they'll probably have activated a configuration change made previously, though.
It sounds like you're missing a wildcard script mapping for ASP.Net, and a "verify file exists" setting should be toggled for the wildcard script map. The app probably shipped with instructions for that as part of its first-time setup, but it's possible to redefine these settings at the app level as well as the site.
uSlackr's suggestion to restore the metabase from an older backup is good (and don't forget configuration history), or otherwise you could compare metabase.xml with the old one, and particularly focus on scriptmaps and related settings, at each level you're interested in.
(I'm answering my own question because following the answers given by the uSlackr and TristanK I was able to find out how a configuration setting change could cause so much havoc.)
The article that uSlackr pointed to was key. I didn't realise automatic backups were done every time you changed a configuration. Unfortunately with all the tweaking I'd done to try and put things back, the automatic backup from when things were working had got overwritten. However I was able to restore from a backup using the instructions for a manual restore (without having to restore loads of irrelevant files).
What I'm pretty sure I did wrong was to change a setting at the root of the website and then say yes when it asked if everything below should be overwritten. What I thought it would do was just change that setting (e.g. a timeout) but what it actually did was overwrite scriptmaps at lower levels with blanks. Those scriptmaps included the wildcard handler, which is why those URL broke. Lessons learned: change things at the appropriate level, restore from backups when a configuration change breaks things.