Мне интересно, какие преимущества даст мне перемещение всех файлов содержимого веб-сайта из каталога inetpub по умолчанию (C :) во что-то вроде D: \ wwwroot. По умолчанию IIS создает отдельный пул приложений для каждого веб-сайта, и я использую встроенного пользователя и группу (IURS) в качестве метода проверки подлинности. Я убедился, что у каждого каталога сайта есть соответствующие настройки разрешений, поэтому я не уверен, какие преимущества я получу. Некоторые из настроек среды приведены ниже:
Также как это статья (перемещение каталога iis7 inetpub на другой диск) указывает, не уверен, стоит ли переносить файлы на другой диск:
ПОЖАЛУЙСТА, ВНИМАТЕЛЬНО СЛЕДУЕТ: СОБЫТИЯ ОБСЛУЖИВАНИЯ WINDOWS (ИМ. ГОРЯЧИЕ ИСПРАВЛЕНИЯ И СЕРВИСНЫЕ ПАКЕТЫ) БУДУТ ЗАМЕНЯТЬ ФАЙЛЫ В ИСХОДНЫХ КАТАЛОГАХ. ВЕРОЯТНОСТЬ, ЧТО ФАЙЛЫ В КАТАЛОГАХ INETPUB НЕОБХОДИМО ЗАМЕНИТЬ СЕРВИСНОЕ ОБСЛУЖИВАНИЕ, НИЗКАЯ, НО ПО ЭТОЙ ПРИЧИНЕ УДАЛЕНИЕ ИСХОДНЫХ КАТАЛОГОВ НЕВОЗМОЖНО.
Одна из причин заключается в том, что если у вас есть динамически созданный контент, который помещается в этот каталог, и он работает безумно, вы можете вызвать сбой ОС, если она будет работать на полном диске. Этого не произойдет, если несистемный раздел работает на весь диск, это, вероятно, просто приведет к сбою вашего приложения.
Хотя в прошлом предлагались отдельные разделы, в действительности они не требуются. Если есть угроза безопасности, это ваша машина, а не просто раздел.
Проблема, поднятая MarkM, может быть решена путем мониторинга дискового пространства, которое, я считаю, в любом случае должно использоваться на всех серверах, и предупреждений, выдаваемых, когда пространство становится ниже заданных пороговых значений. Нетрудно добавить мониторинг скорости изменений и перезапустить приложения или даже сам сервер в случае сбоя процесса.
единственная причина безопасности, о которой я могу думать, - это родительские пути ... если у вас есть веб-сайт, размещенный из c: \ wwwroot, и плохая конфигурация IIS, кто-то может получить доступ к содержимому, размещенному в том же разделе. Я полагаю, это была проблема с IIS 5
Помимо этого, основной причиной могут быть журналы и другой контент, заполняющий ваш системный раздел (как упоминалось MarkM)