« Previous Next »

Thread: adding default document to IIS "breaks" individual site configs?

Last post 11-19-2008 7:39 AM by e1ny. 2 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (3 items)

Sort Posts:

  • 11-17-2008, 6:58 AM

    • e1ny
    • Top 50 Contributor
    • Joined on 12-10-2007, 4:50 PM
    • Posts 188

    adding default document to IIS "breaks" individual site configs?

    Hi All: I have a server running 64-bit standard sp1 with about 6 websites. On one of the websites I had added "index.php" to the default documents, where it showed up in ISM as a "local" entry.

    Then the developer decided they wanted index.php added to all the sites. Rather than add it on a site-by-site basis, I just added it to the server's root config by clicking on the server name in ISM and changing the default document there.

    This caused the first website to stop functioning (throwing 500 errors), which I didn't realize for some time. When I tried to check the default document on the first website in ISM, I received an error that there was a conflict in the web.config (preventing any changes from being made), which eventually led me to this technote:

    http://support.microsoft.com/default.aspx/kb/949349

    And I was able to fix it by first removing the "global" index.php default document setting, then removing the "local" setting, then re-enabling the global setting. Fortunately it was only two websites that had the "local" setting.

    It seems strange to me that ISM will "allow" me to make changes that will completely break a website. Just like you can't add the same virtual hostname for two websites without getting an error, I would expect some type of error checking, or at least an alert message, that would have prevented me from performing an action that will break a configuration elsewhere?

    Is there any type of utility that will check a server for configuration errors or conflicts like this?

  • 11-19-2008, 5:44 AM In reply to

    Re: adding default document to IIS "breaks" individual site configs?

    If you change/modify settings are Root level, it will be always inherited to all child object and if I remember correctly, while you do this, the pop-up shows that you are inheriting settings to child objects.

    Coming back to this issue, when you added index.php at root level as default document, it actually did not break the website, it actually just added index.php as default document. The reason it showed 500 error is PHP wasn't configured on your 1st site, if PHP would have been configured, it would have worked and haven't showed 500 error.

    HTH.

    ~ Ganesh

  • 11-19-2008, 7:39 AM In reply to

    • e1ny
    • Top 50 Contributor
    • Joined on 12-10-2007, 4:50 PM
    • Posts 188

    Re: adding default document to IIS "breaks" individual site configs?

    ganeshanekar:

    If you change/modify settings are Root level, it will be always inherited to all child object and if I remember correctly, while you do this, the pop-up shows that you are inheriting settings to child objects.

    It may have...I don't remember...but why should that "break" the child website that had been previously set? Why does IIS care that the setting is repeated in the child website? Why wouldn't IIS perform some housekeeping to remove the duplicate setting on the child websites?

    How would I know from that message that I should now have to manually go into the application.config and delete all the child override settings? <childish rant> Even if that is true, it presupposes that the administrator should know to do this...I take responsibility for my ignorance, but I maintain that this is a step backward from IIS6.</childish rant>

    ganeshanekar:

    Coming back to this issue, when you added index.php at root level as default document, it actually did not break the website, it actually just added index.php as default document. The reason it showed 500 error is PHP wasn't configured on your 1st site, if PHP would have been configured, it would have worked and haven't showed 500 error.

    On this particular webserver, the "first" website is disabled, and I'm not sure I understand what you mean by "PHP wasn't configured on your 1st site"...I had enabled PHP through the fastCGI method, so how does that "enable" or "disable" it for any individual website?

    I appreciate your help but I'm still not clear on this.

Page 1 of 1 (3 items)
Microsoft Communities