Iis задание стандартного домена для входа


Содержание

Установка и конфигурирование IIS

В большинстве случаев в реальных производственных проектах один или несколько серверов будут использоваться для обслуживания клиентских запросов веб-сайта. Эти серверы могут принадлежать и управляться непосредственно вами, специализированной командой или же сторонней компанией, предоставляющей услуги хостинга. В любом случае рано или поздно наступает момент, когда написание кода и его тестирование завершено, и работа должна быть представлена широкой публике — в этом и заключается развертывание веб-сайта.

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

Установка IIS

Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

В правой части окна нажмите на ссылке Add Roles. Это открывает мастер, позволяющий добавить новую роль сервера.

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

В некоторых ситуациях имя, под которым сервер известен вам, и имя, которое клиенты используют для получения содержимого, будут различаться. Мы оставим этот нюанс без внимания, но администратор сервера или компания, предоставляющая услуги хостинга, предоставят необходимые сведения, если это важно для конкретного сервера.

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Описание проблемы

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

С точки зрения пользователей, будет видно окно с запросом логина и пароля.

Проблема может заключаться в том, что методы операционной системы в силу различных причин возвращают описание текущего пользователя сеанса в таком представлении, которое не совпадает ни с одним пользователем в списке пользователей информационной базы 1С

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

Воспроизвести ситуацию с неудачной аутентификацией операционной системы. Авторизоваться под пользователем операционной системы, указанным в свойствах пользователя 1С.

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: «Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя»

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 — именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

04:45.940011-0,CONN,2,process=rphost,t:client >04:45.940012-0,CONN,2,process=rphost,t:client >04:45.971001-0,CONN,2,process=rphost,t:client >DstUserName2: DOMAIN701\testuser2(DOMAIN701\testuser2)
04:46.205021-0,EXCP,2,process=rphost,p:processName=trade,t:client >a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

Заменить значение свойства «Пользователь» пользователя информационной базы согласно следующему формату «\\» + [Имя пользователя из свойства DstUserName2 без скобок].

Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.


Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

В некоторых случаях, несмотря на корректно указанного пользователя операционной системы в пользователе информационной базы, при попытке входа в опубликованную базу через браузер аутентификация операционной системы не проходит. Такая ситуация может возникать, если веб-сервер IIS и сервер 1с находятся на разных машинах. В таком случае в технологическом журнале рабочего процесса можно наблюдать следующую картину:

56:39.487001-0,CONN,2,process=rphost,p:processName=accounting,t:client >56:39.487002-0,CONN,2,process=rphost,p:processName=accounting,t:client >56:39.596004-0,CONN,2,process=rphost,p:processName=accounting,t:client >DstUserName2: NT AUTHORITY\ANONYMOUS LOGON(NT AUTHORITY\ANONYMOUS LOGON )
56:39.659003-0,EXCP,2,process=rphost,p:processName=accounting,t:client >a01f465c-ed70-442e-ada5-847668d7a41c: Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя’

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

В настройках аутентификации отключить анонимную аутентификацию и включить Windows-аутентификацию. В Windows-аутентификации упорядочить доступных провайдеров так, чтобы на первом месте был Negotiate.

Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

3) Убедиться, что в контроллере домена в свойствах компьютера, на котором запущен веб-сервер, на вкладке делегирование установлено «Доверять компьютеру делегирование любых служб (только Kerberos)»

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение «Доверять компьютеру делегирование любых служб (только Kerberos)» и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

После выполнения всех действий необходимо перезагрузить клиентский компьютер (рабочие серверы перезагрузки не требуют) и убедиться, что аутентификация операционной системы успешно выполняется.

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Iis задание стандартного домена для входа

Добрый день уважаемые читатели и гости блога. Для меня было большим удивлением, что в Америке и в Европе, очень много хостинов используемых людьми, построены на Windows Internet Information Services, и ее доля там больше чем Linux Apache или nginx. В сегодняшнем посте я бы хотел рассказать, начинающим системным администраторам, как создавать сайты iis в Windows Server 2012 R2, точнее административную часть, так как там уже вы сами будите выбирать, будет ли это ресурс на движке Werdpress или же статический сайт, вариантов очень много.

Подготовка IIS для развертывания сайта в IIS

И так для нашей задачи, вы уже должны иметь развернутую службу IIS, как это сделать, я рассказывал в отдельной статье. Теперь перейдем к практике и подготовим его для последующих вещей. Открываем диспетчер IIS. Найти этот пункт можно в диспетчера сервера.

Я хочу создать отдельный сайт, пускай это будет iis.pyatilistnik.org, для этого переходим в пункт сайты и через правый клик ,выбираем пункт «Добавить веб-сайт»

Само создание сайта iis состоит из вот таких не хитрых пунктов. Во первых, вы задаете:

  • Имя сайта — у меня это iis.pyatilistnik.org
  • Указываете физический путь — это та папка в которой будет лежать контент для сайта, например, картинки, документы, html странички, если сайт с базой данных, то многое будет лежать в ней.

Далее вы производите привязку сайта к нужному ip адресу, делается это после того, как вы на своем DNS сервере создали A или Cname запись для ресурса. Так же задаем тип привязки, имеет ввиду протокол, тут их всего два обычный незащищенный http и защищенный сертификатом шифрования https, о нем я подробно говорил.

Ну и последним шагом в данном окне, будет указание имени узла, имеется ввиду по какому dns имени, будут фильтроваться заголовки, чтобы попасть на нужный сайт, так как на 80 порту их может висеть очень много.

Пробуем запустить ваш сайт. И так, сайт в диспетчере IIS на Windows Server 2012 r2 мы создали, пробуем его запустить, для этого у вас есть в пункте управление веб-сайтом, отдельный пункт «Обзор»

Если все хорошо, то вы получите доступ к ресурсу, если же нет, то увидите запрещающее сообщение:

Тут два варианта:

  • У вас пустая папка с сайтом, попробуйте поместить в нее, хотя бы картинку, для тестирования
  • У вас просто нет прав на чтение данного каталога на уровне Windows

С первым вариантом, все понятно, кладем в папку нужный контент, во втором случае, вам нужно назначить права, я дам их для группы «Все» на чтение. Делается это просто, выберите папку и щелкните по ней правым кликом, выберите свойства.

Перейдите на вкладку «Безопасность > Изменить > Добавить > Проверить имя» и через поиск найти нужную группу.

Назначаем нужный уровень прав для созданного сайта IIS, у меня это чтение и выполнение.

Открываем в браузере ваш сайт и проверяем.

Если у вас появляется окно, что не удается отобразить эту статью, то у вас с большой вероятностью, либо не правильная привязка к порту, либо не открыт порт на брандмауэре.

Следующим шагом, у вас встанет вопрос какого типа будет ваш сайт и нужно ли для его настройки добавлять новые компоненты или же устанавливать сторонние, по типу PHP или MySQP для WordPress. Далее я вам советую, разобраться в вопросе проверки подлинности IIS и как она настраивается.

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

Илон Маск рекомендует:  Как сделать, чтобы фон не повторялся

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

6. Выбираем верхний узел, узел веб сервера, в котором представлены иконки, отвечающие за параметры работы модулей всего веб сервера, эти параметры наследуются по умолчанию для всех веб сайтов. Убеждаемся, что все необходимые модули установлены и отображены. Снимок экрана при установке конфигурации по умолчанию приведен ниже.

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).


10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.

В принципе, для базовой проверки работоспособности и целостности установки данных шагов вполне достаточно. Но если вы хотите поближе познакомиться с «полным» набором настроек и конфигурацией «по умолчанию» – то можете проделать следующие шаги.

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

Такие настройки безопасности по умолчанию – только анонимные пользователи – позволяют гарантировать защиту данных на сервере, для которых требуются соответствующие разрешения, а также – что механизм аутентификации веб сервера (которого в данном случае просто нет) не будет использован для перебора паролей и прочих попыток «взлома» через учетные записи.

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Основы архитектуры IIS, или запросопровод для ASP.NET

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures» Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план
2. Крупный план
2.1. HTTP.SYS
2.2. World Wide Web Publishing Service (W3SVC)
2.3. Windows Process Activation Service (WAS)
2.4. Пул приложений
2.5. Домен приложения, приложение
3. Что дальше?
Источники

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» — что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS.
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища — из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS.
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS.
8. HTTP.SYS отправляет ответ браузеру.

В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.

2. Крупный план

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно — Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда — Use of special characters like ‘%’ ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно — Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

  • Администрирование драйвера HTTP.sys.
  • Управление рабочими процессами.
  • Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с .NET Framework и интегрированные с IIS:

  • NetTcpActivator для протокола TCP;
  • NetPipeActivator для Named Pipes;
  • NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:

  • Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
  • Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
  • Исполняемый файл w3wp.exe – шаблон рабочего процесса.
  • Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
  • Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler — PPH) и у домена приложения (AppDomain protocol handlers — ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Илон Маск рекомендует:  Функции bios int 10h видео сервис

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее — маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.


Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе .NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в этой статье).

Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.

На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс My >
Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Создание динамических поддоменов через Windows / IIS: обзор

Довольно часто приходится сталкиваться с проблемой, когда информации на сайте, размещенном на Windows Server, становится настолько много, что приходится пересмотреть свои взгляды на архитектуру сайта. В этих случаях сайт можно разбить на поддомены. В статье представлены два способа, как этого добиться с небольшим их анализом со стороны автора.

Приступая к реализации этих методов, необходимо получить следующие доступы и возможности пользоваться технологиями:

  • должна быть возможность изменения DNS;
  • доступ к серверу ISS;
  • ISAPI_Rewrite (для реализации 2 способа).

Реализация первого метода: настройка сервера IIS

Вероятно, у вас будет ограниченное количество поддоменов, которыми необходимо будет управлять. Управлять им можно будет как всеми вместе, так и каждым по отдельности.

Управление группой поддоменов: добавьте следующую запись в ваш DNS и измените домен вместе с IP следующим образом:

*.example.com IN A 1.2.3.4

Объявление вручную: добавьте запись для каждого из поддоменов.

В sub1.example.com 1.2.3.4
В sub2.example.com 1.2.3.4
В sub3.example.com 1.2.3.4

Во-первых, убедитесь, что вы создали корень директории для каждого из поддоменов, как при работе с новым сайтом. Ваша директория может выглядеть следующим образом:

d:\inetpub\wwwroot\example.com\sub1\
d:\inetpub\wwwroot\example.com\sub2\
d:\inetpub\wwwroot\example.com\sub3\
d:\inetpub\wwwroot\example.com\js\
d:\inetpub\wwwroot\example.com\css\
d:\inetpub\wwwroot\example.com\img\

Далее необходимо создать сайт для каждого из поддоменов. Следующие действия можно повторять для вех поддоменов:

  • Откройте консоль IIS (IIS Management Console);
  • Щелкните на Web Sites и выберите New: Web-site;
  • Нажмите Next, чтобы продолжить;
  • Введите описание сайта и нажмите кнопку Next. Пример того, как это выглядит: sub1.example.com;
  • IP-адрес и Settings: введите sub1.example.com в Host header.
  • На следующей странице введите путь d:\inetpub\wwwroot\example.com\sub1\
  • На следующей странице, выберите подходящие настройки и нажмите кнопку Next.

Теперь начинается самое интересное: созданы отдельные сайты для каждого поддомена, но у них есть общие файлы (скрипты, CSS, картинки). Проблема состоит в том, как сделать так, чтобы каждому сайту были доступны эти файлы.

  • Кликните правой кнопкой мыши на поддомен, который вы только что создали в консоль управления IIS и выберите New : Virtual Directory;
  • В качестве примера будем использовать папку CSS. Кликните на Next и введите в css псевдонимом;
  • Укажите путь d : \ inetpub \ wwwroot \ example.com \ css \ и нажмите кнопку Next.

Реализация первого метода: подведение итогов

Итак, мы создали несколько поддоменов и разделили между ними общие файлы.

Реализация первого метода: использование ISAPI_Rewrite

Сразу перейдем к сравнению первого метода со вторым.

Добавьте следующую запись в ваш DNS и измените домен вместе с IP следующим образом:

*.example.com IN A 1.2.3.4

  • Откройте консоль управления IIS выберите Web-site;
  • Щелкните правой кнопкой мыши по нему и выберите Properties;
  • Нажмите кнопку Advanced;
  • Убедитесь, что имеется одна запись для множества сущностей для данного веб-сайта с заполненным Host Header Name. Данная запись будет перехватывать все запросы, которые адресуются IP-адрес;
  • Убедитесь, что IP-адрес используется только этим сайтом

Настройка httpd.ini по ISAPI_Rewrite

Добавьте следующий код в httpd.ini в корне директории. Убедитесь, что они в правильном порядке.

# Конвертировать http://example.com к http://www.example.com/
RewriteCond Host: ^example.com
RewriteRule (.*) http\://www\.example.com$1 [I,RP]

# ограничимся рядом общих папок.
# будем выполнять их соответственно вне зависимости от поддомена.
# Example: http://sub1.example.com/img/logo.jpg -> /img/logo.jpg
# Example: http://www.example.com/img/logo.jpg -> /img/logo.jpg
RewriteRule (/css/.*) $1 [I,O,L]
RewriteRule (/js/.*) $1 [I,O,L]
RewriteRule (/img/.*) $1 [I,O,L]

# Перенаправлять все остальные подкаталоги, не соответствующие
# вышеупомянутому списку, как поддомены.
#example: www.example.com\sub1 -> sub1.example.com
RewriteCond Host: www\.highspeed\.com
RewriteRule /(\w*)/(.*) http\://$1\.example\.com$2 [I,RP]

# Если веб-сайт начинается с www, то обязательно укажите файл в корневой папке.
# Если вы специально создали папки / www /, то вы можете закомментировать этот раздел.
RewriteCond Host: (?:www\.)example.com
RewriteRule (.*) $1 [I,O,L]

# url сайта, начинающийся без www, будет переправлен на поддомен
# Example: http://sub1.example.com/default.asp -> /sub1/default.asp
# Note: if the folder does not exists, then the user will get a 404 error automatically.
RewriteCond Host: (.*)\.example.com
RewriteRule (.*) /$1$2 [I,O,L]

# исправление недостающего символа
# выдача 404 ошибки
RewriteCond Host: (.*)
RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [I,RP]

Предположим, что корпоративный сайт состоит из двух поддоменов sub1, sub2.

URI ¦ Расположение на сервере

http://www.example.com ¦ /
http://sub1.example.com/img/logo.jpg ¦ /img/logo.jpg
http://sub2.example.com ¦ /sub2/
http://abc.example.com ¦ /abc/ -> 404 Not Found

Реализация второго метода: подведение итогов

Второе решение легкое в реализации, однако нужно быть осторожным в создании директорий. Так, например, пользователь не может создавать папки d:\inetpub\wwwroot\example.com\sub1\img\ потому, что она противоречит ISAPI_Rewrite (/ img / *.). Поэтому файлы в этой папке не будут доступны.


Multiple IIS- плюсы

  • Вся информация из всех папок доступна, противоречий нет.
  • Отделены log-файлы для отслеживания их по отдельности.
  • Может быть осуществлена настройка для группы серверов и произведена балансировка нагрузки на них.

Multiple IIS сеть — минусы

  • Необходимость создания нового сайта на поддомене.
  • Требует доступа к серверу IIS.
  • Простота установки.
  • Легкость просмотра log-файлов.
  • Для добавления поддомена просто необходимо добавить новую папку
  • Необходимость отслеживания каталогов во избежание конфликтов.
  • Нужна выделять IP-адрес.
  • Требуется дополнительный ресурс для обработки каждого файла.
  • Необходимость подбора сервера, который поддерживает ISAPI_Rewrite.

Хотя ISAPI_Rewrite гораздо проще в реализации, все-таки, использовать его рекомендуется на не очень больших сайтах, с которыми работает группа разработчиков. Это объясняется тем, что группа разработчиков должна постоянно отслеживать добавление и удаление ресурсов. Для большого сайта администратор должен будет произвести все настройки на нескольких серверах только один раз. Поддомены, созданные различными командами разработчиков, в этом случае будут функционировать практически одинаково с одинаковыми настройками.

В конце концов, выбор способа разделения сайта на поддомены зависит от администратора, который обслуживает сайт.

IIS 7.0: краткая инструкция для системного администратора. Часть 1 – пpoверка результатов установки.

Продолжаем говорить об процедуре установки веб сервера под управлением IIS 7.0 на Windows Server 2008, которая была рассмотрена в предыдущем посте.

Теперь перейдем к проверке результатов установки IIS 7.0. Самый простой вариант проверить, работает ли веб сервер, особенно – находясь за локальной консолью, это обратиться из любого веб-браузера по адресу http://localhost/. Далее, проверить с локальной и удаленной машины по IP-адресу.

При установке IIS 7.0 создается веб сайт по умолчанию, сконфигурированный на ответ при любом URL-запросе, поступившем на порт 80 любого сетевого интерфейса сервера, на котором установлен IIS 7.0. Т.е. запрос браузера типа http://localhost/ должен быть обработан как запрос к веб сайту по умолчанию. Содержимое сайта по умолчанию представляет собой 2 файла – iisstart.htm и welcome.png (который отображается в iisstart.htm), которые и будут открыты клиентом. Поэтому результат обращения к localhost будет иметь следующий вид:

Теперь, если все хорошо (если «плохо» – поиск неисправностей и ошибок мы рассмотрим позже, в отдельном разделе), убедимся, что все модули, которые должны быть установлены по умолчанию – подключены и работают, а базовая конфигурация – отвечает нашим требованиям.

1. Основным инструментом управления IIS 7.0 является консоль Internet Information Services (IIS) Manager, которая устанавливается по умолчанию, вместе с ролью Web Server в Windows Server 2008 (IIS Management Console, раздел Management Tools при установки модулей). После соответствующей установки консоль управления IIS 7.0 можно найти, как дочернюю запись внутри раздела Web Server (IIS) в разделе ролей Server Manager, либо как пункт в разделе Administrative Tools меню Start, либо выполнив команду inetmgr (в командной строке или через пункт Run того же меню Start).

2. При старте консоль Internet Information Services (IIS) Manager открывается с «домашней страницей», на которой в виде панелей находится информация о том, к каким веб серверам и веб сайтам подключался пользователь консоли до этого (если консоль только установлена вместе с ролью Web Server (IIS), то в консоле присутствует запись только о локальном веб сервере), также присутствуют ссылки для выбора подключения к другим серверам, веб сайтам, веб приложениям и папкам, а также ссылки на внешние ресурсы, посвященные IIS.

3. Кроме того, на домашней странице присутствует панель новостей, которые подгружаются как новостная RSS-лента с сайта www.iis.net, если администратор нажимает на ссылку Enable IIS News. Новости, кстати, очень полезные, рекомендуется включать и использовать эту информацию в повседневной работе.

4. При подключении к какому либо веб серверу IIS 7.0 консоль Internet Information Services (IIS) Manager представляет его конфигурацию, как логическую структуру – уровень самого веб сервера, чьи настройки являются глобальными и распространяются по умолчанию на все веб сайты, пулы приложений и, сообственно, веб сайты со своими настройками. Эта конфигурационная иерархия, в виде разворачивающегося дерева, начинающегося с узла с именем (или IP) веб сервера, отображается в левой панели консоли Internet Information Services (IIS) Manager.

5. Если выбрать какой-то узел в дереве конфигурации, то в центральной панель консоли Internet Information Services (IIS) Manager будут отображены в виде отдельных иконок все параметры (а также – модули или списки), соответствующие конфигурации выбранного узла, а в правой панели – набор контекстных задач и операций, которые администратор (или пользователь) может выполнить над данным узлом.

6. Выбираем верхний узел, узел веб сервера, в котором представлены иконки, отвечающие за параметры работы модулей всего веб сервера, эти параметры наследуются по умолчанию для всех веб сайтов. Убеждаемся, что все необходимые модули установлены и отображены. Снимок экрана при установке конфигурации по умолчанию приведен ниже.

7. В правой панели при выборе узла веб сайта отображаются все операции, возможные для выполнения непосредственно с веб сервером (службами IIS в целом) в данном конексте – перезапуск, останов, запуск, переход к пулам приложений и сайтам.

8. Убеждаемся, что пулы приложений (Application Pools) сконфигурированы. Пулы приложений будут рассмотрены позже. Пулы являются дочерним узлом в дереве конфигурации для узла веб сайта. При установке по умолчанию создается только один пул – DefaultAppPool, в котором регистрируется одно приложение – сконфигурированный по умолчанию веб сайт, работу которого мы уже проверили. См. снимок экрана.

9. Ниже узла пулов приложений в дереве конфигурации находится узел веб сайтов (Sites), при выборе которого отображается список работающих на данном веб сервере веб сайтов. По умолчанию создается один веб сайт под названием Default Web Site с внутренним номером (ID) равным 1, «привязанный» на 80 порт всех IP-адресах всех сетевых интерфейсов к любому URL в запросе, и использующий в качестве домашнего каталога своего контента каталог с путем %SystemDrive%\inetpub\wwwroot (что при установленном Windows Server 2008 на диск C: соответствует C: \inetpub\wwwroot).

Илон Маск рекомендует:  Введение в opengl

10. При выборе в левой панели консоли узла веб сайта (Default Web Site), также, как и в случае с выбором узла веб сервера, в центральной панели отображаются иконки для доступа к параметрам конфигурации различных модулей, на этот раз – конкретного веб сайта. Убеждаемся, что также, как и в случае со всем веб сервером, все необходимые модули представлены в центральной панели.

11. В правой панели консоли, аналогично панели для всего веб сервера, отображаются контекстные команды, правда, на этот раз их список серьезно расширен – старт/стоп/перезапуск процесса веб сайта, просмотр его базовых и расширенных настроек (а не параметров модулей), настройки привязки (адрес, порт, доменное имя – по сочетанию которых будет отвечать на запросы данный веб сайт) и т.п.

В принципе, для базовой проверки работоспособности и целостности установки данных шагов вполне достаточно. Но если вы хотите поближе познакомиться с «полным» набором настроек и конфигурацией «по умолчанию» – то можете проделать следующие шаги.

12. Выберите узел веб сервера в дереве конфигурации в левой панели консоли Internet Information Services (IIS) Manager. В центральной панели кликните на иконку Modules. В центральной панели откроется следующий полный список установленных по умолчанию модулей, представляющий из себя перечень .dll файлов.

13. Чтобы убедиться, что веб сервер будет работать только со статическими файлами (по умолчанию) или только с нужными вам расширениями – выберите снова узел веб сервера и в центральной панели кликните на иконку Handler Mappings. Откроется список «привязки» расширений вызываемых на веб сайте пользователем файлов и привязанных к данным расширениям модулям, выполняющим обработку данного вызова. Обратите внимание, что по умолчанию все файлы привязаны к модулю обработки статических файлов (т.е. запрос какого либо скриптового или исполнимого файла из домашнего каталога веб сайта не будет приводить к его исполнению на сервере, а лишь к передаче данного файла пользователю), а также к модулям документа по умолчанию и просмотра каталога. С этими модулями мы познакомимся позже.

14. И, наконец, для того, чтобы убедиться в безопасности веб сайта – проверьте параметры его аутентификации. Для этого выбираем иконку Authentication в той же центральной панели. По умолчанию никаких модулей аутентификации веб сервер (и веб сайты) не поддерживает. Т.е. все подключения для него анонимны. В чем безопасность? Это значит, что пользователям будет доступен только то содержимое домашних каталогов сайтов – файлы и подкаталоги – которые имеют NTFS разрешения для чтения «всем» (Everyone). В случае, если таких разрешений файл не имеет, пользователю будет отказано в доступе с соответствующей ошибкой 401. Если же пользователь попробует каким-то образом аутентифицироваться в процессе HTTP запроса на сервере – то поскольку никаких модулей аутентификации, кроме анонимного, на веб сервере не установлено – он снова получит соответствующую ошибку 401.

Такие настройки безопасности по умолчанию – только анонимные пользователи – позволяют гарантировать защиту данных на сервере, для которых требуются соответствующие разрешения, а также – что механизм аутентификации веб сервера (которого в данном случае просто нет) не будет использован для перебора паролей и прочих попыток «взлома» через учетные записи.

Итак, сервер установлен и его работоспособность проверена. Теперь достаточно поместить какой либо статический контент (файлы HTML, изображения, документы и файлы для выгрузки пользователями) в домашний каталог его сайта по умолчанию (напоминаю, что это в большинстве случаев C:\inetpub\wwwroot) – и веб сайт под управлением IIS 7.0 начнет работать. Ну, и конечно, для внешних сайтов – не забыть прописать их A-record в вашей доменной зоне на публичном DNS сервере.

В следующей части – установка IIS 7.0 в режиме командной строки, особенности работы IIS 7.0 на Server Core.

Домен входа в систему IIS 7 по умолчанию

Мне нужно изменить домен входа по умолчанию на наш веб-сайт, но по какой-то причине он по-прежнему помещает домен компьютера в качестве значения по умолчанию при входе в систему. Я пробовал следующее: http://technet.microsoft.com/en-us/library/cc772009 (v = ws.10).aspx но получить те же результаты. что еще может быть?

Я не могу найти какие-либо другие решения в Интернете, любые идеи? Я сравнил конфигурацию IIS с другим сервером (это работает), и он выглядит идентичным. не может для жизни меня выяснить, что происходит.

Когда вы выполняете аутентификацию на веб-сайте, есть много точек, на которых можно представить диалог входа в систему. Я собираюсь предположить, что у вас есть простой веб-сайт, состоящий только из базовых файлов .HTM.CSS и .JS. (Значит, вы не используете ASP.NET и хотите иметь аутентификацию на основе форм.)

Сам веб-сайт работает под доменом/пользователем, настроенным в пуле приложений, на котором работает сайт. Я подозреваю, что вы НЕ пытаетесь настроить это. Это уровень безопасности, на котором работает весь процесс веб-сайта. Смысл, без регистрации конечного пользователя вообще, это то, что уровень безопасности веб-сайта относится к доступу к файловой системе, сети, реестру и т.д.

Если вы хотите, чтобы ТОЛЬКО пользователи в одном из доменов вашей сети Windows имели доступ, вы должны перейти на веб-сайт IIS, нажать «Аутентификация» и отключить анонимность, олицетворение ASP.NET и аутентификацию форм. Затем установите только домен в базовой аутентификации для того, что вам нужно.

Если это то, что вы сделали, и он все еще не работает. Тогда я подозреваю это, потому что машина IIS, вероятно, должна удовлетворять некоторым требованиям, чтобы это произошло. Например: он должен быть добавлен как член домена, который вы пытаетесь настроить. Другая возможность заключается в том, что некоторые настройки на контроллере домена или невозможность достичь этого не позволяют веб-серверу представить посетителям вашего веб-сайта возможность входа в этот домен.

Iis задание стандартного домена для входа

Добрый день уважаемые читатели и гости блога. Для меня было большим удивлением, что в Америке и в Европе, очень много хостинов используемых людьми, построены на Windows Internet Information Services, и ее доля там больше чем Linux Apache или nginx. В сегодняшнем посте я бы хотел рассказать, начинающим системным администраторам, как создавать сайты iis в Windows Server 2012 R2, точнее административную часть, так как там уже вы сами будите выбирать, будет ли это ресурс на движке Werdpress или же статический сайт, вариантов очень много.

Подготовка IIS для развертывания сайта в IIS

И так для нашей задачи, вы уже должны иметь развернутую службу IIS, как это сделать, я рассказывал в отдельной статье. Теперь перейдем к практике и подготовим его для последующих вещей. Открываем диспетчер IIS. Найти этот пункт можно в диспетчера сервера.

Я хочу создать отдельный сайт, пускай это будет iis.pyatilistnik.org, для этого переходим в пункт сайты и через правый клик ,выбираем пункт «Добавить веб-сайт»

Само создание сайта iis состоит из вот таких не хитрых пунктов. Во первых, вы задаете:

  • Имя сайта — у меня это iis.pyatilistnik.org
  • Указываете физический путь — это та папка в которой будет лежать контент для сайта, например, картинки, документы, html странички, если сайт с базой данных, то многое будет лежать в ней.


Далее вы производите привязку сайта к нужному ip адресу, делается это после того, как вы на своем DNS сервере создали A или Cname запись для ресурса. Так же задаем тип привязки, имеет ввиду протокол, тут их всего два обычный незащищенный http и защищенный сертификатом шифрования https, о нем я подробно говорил.

Ну и последним шагом в данном окне, будет указание имени узла, имеется ввиду по какому dns имени, будут фильтроваться заголовки, чтобы попасть на нужный сайт, так как на 80 порту их может висеть очень много.

Пробуем запустить ваш сайт. И так, сайт в диспетчере IIS на Windows Server 2012 r2 мы создали, пробуем его запустить, для этого у вас есть в пункте управление веб-сайтом, отдельный пункт «Обзор»

Если все хорошо, то вы получите доступ к ресурсу, если же нет, то увидите запрещающее сообщение:

Тут два варианта:

  • У вас пустая папка с сайтом, попробуйте поместить в нее, хотя бы картинку, для тестирования
  • У вас просто нет прав на чтение данного каталога на уровне Windows

С первым вариантом, все понятно, кладем в папку нужный контент, во втором случае, вам нужно назначить права, я дам их для группы «Все» на чтение. Делается это просто, выберите папку и щелкните по ней правым кликом, выберите свойства.

Перейдите на вкладку «Безопасность > Изменить > Добавить > Проверить имя» и через поиск найти нужную группу.

Назначаем нужный уровень прав для созданного сайта IIS, у меня это чтение и выполнение.

Открываем в браузере ваш сайт и проверяем.

Если у вас появляется окно, что не удается отобразить эту статью, то у вас с большой вероятностью, либо не правильная привязка к порту, либо не открыт порт на брандмауэре.

Следующим шагом, у вас встанет вопрос какого типа будет ваш сайт и нужно ли для его настройки добавлять новые компоненты или же устанавливать сторонние, по типу PHP или MySQP для WordPress. Далее я вам советую, разобраться в вопросе проверки подлинности IIS и как она настраивается.

Установка и конфигурирование IIS

В большинстве случаев в реальных производственных проектах один или несколько серверов будут использоваться для обслуживания клиентских запросов веб-сайта. Эти серверы могут принадлежать и управляться непосредственно вами, специализированной командой или же сторонней компанией, предоставляющей услуги хостинга. В любом случае рано или поздно наступает момент, когда написание кода и его тестирование завершено, и работа должна быть представлена широкой публике — в этом и заключается развертывание веб-сайта.

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.

Установка IIS

Компонент IIS включен как часть установки Windows (как для сервера, так и для рабочих станций) и требует активизации и конфигурирования. Далее представлены три способа активации IIS для различных операционных систем.

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

В правой части окна нажмите на ссылке Add Roles. Это открывает мастер, позволяющий добавить новую роль сервера.

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

В некоторых ситуациях имя, под которым сервер известен вам, и имя, которое клиенты используют для получения содержимого, будут различаться. Мы оставим этот нюанс без внимания, но администратор сервера или компания, предоставляющая услуги хостинга, предоставят необходимые сведения, если это важно для конкретного сервера.

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

Итак, каждый сервер может поддерживать множество сайтов, каждый из которых работает на другом порту или с другим IP-адресом. Каждый сайт может иметь множество файлов и каталогов, и сочетание этих элементов предоставляет информацию о URL-адресе. Мы вернемся к URL-адресам и использованию IIS Manager при рассмотрении каждого из подходов к развертыванию.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL