Приложения и сайты, разработанные на ASP.NET, должны размещаться на веб-сервере (далее IIS). Это оснастка Windows, отвечающая за размещение веб-приложений, распараллеливание http-запросов, хранение сессий пользователей и многое-многое другое.

В Windows 2008 IIS по умолчанию отсутствует, и прежде чем настроить сайт, необходимо установить IIS . Поэтому статья разбита на две части:

Как установить IIS 7 на windows 2008

Сервер приложений IIS 7 устанавливается с дистрибутива операционной системы. Желательно устанавливать IIS с того же дистрибутива ОС, который установлен на данном компьютере. По опыту скажу, бывают прецеденты некорректной работы, в случае установки IIS с «неродного» дистрибутива. Вставьте диск с Windows 2008 в дисковод и начинайте установку IIS:

1. Нажмите «Пуск» и нажмите правой кнопкой мыши по «Компьютер», зайдите в «Управление»:

2. В диспетчере сервера выберите «Компоненты» и нажмите «Добавить компоненты»:

3. В дереве выбираем «Средства веб-сервера (IIS)» и жмем «Далее»:

После этого начнется установка IIS 7 с диска операционной системы Windows 2008. Дождитесь завершения и перезагрузите компьютер. Все! Установка IIS завершена!

Как настроить IIS 7 на windows 2008

Итак, у нас есть сайт, условно назовем его Security. Он представляет собой каталог Security и набор файлов в этом каталоге. Сайт имеет главную страницу, которая должна загружаться по умолчанию. Назовем ее index.aspx. Первым делом необходимо установить и зарегистрировать.Net Framework. Нужно ставить тот же.Net Framework, под который написан ваш сайт. Версию можно посмотреть в файле web.config вашего сайта. Мы будем считать, что наш сайт написан на Net.Framework v.4.0.

Установке и настройке Net.Framework посвящена отдельная статья Как установить Asp.Net и зарегистрировать его в IIS . Здесь опишу кратко: чтобы зарегистрировать.Net Framework в IIS, нужно в командной строке из каталога C:\WINDOWS\Microsoft.NET\Framework\ версия вашего Framework \ выполнить команду aspnet_regiis.exe -i;

Каталог Security разместите в C:\Inetpub\wwwroot\. Это рабочий каталог диспетчера служб IIS.

Теперь займемся непосредственно настройкой IIS:

1. Запустим Диспетчер служб IIS. Нажмем «Пуск», «Выполнить». В появившемся окне введем inetmgr.exe и нажмем «ОК»:

2. Первым делом создадим группу приложений для нашего сайта. Вообще, группа приложений создается для того, чтобы разнести приложения, работающие на разных версиях.Net Framework. В принципе, если у вас на машине будет располагаться только один сайт, то данный шаг можно пропустить. В диспетчере служб IIS выберите правой кнопкой мыши пункт «Группы приложений», меню «Создать», пункт «Группа приложений…». В появившемся окне введите название группы приложений и нажмите «ОК». Т.к. мы решили, что наш сайт написан на.Net Framework v.4.0, то и назовем нашу группу приложений «Net 4.0»:

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

4. В появившемся окне выбираем наш пул приложения и нажимаем «ОК»:

5. На вкладке «Документы» нужно добавить нашу главную страницу. Тогда при доступе к сайту не нужно будет обращаться по адресу http://имя_сервера /Security/ndex.aspx, достаточно будет написать http://имя_сервера /Security и мы попадем на главную страницу сайта. На вкладке «Документы» удалите все страницы, которые там заведены по умолчанию и добавьте свою стартовую страницу index.aspx:

6. На этом настройка IIS завершена, осталось настроить права доступа на каталог Security. Откройте общий доступ на вкладке «Доступ» и дайте полный доступ группе IIS_IUSRS и пользователю IUSR (они создаются при установке IIS). На вкладке «Безопасность» также дать полный доступ указанной группе и пользователю:

Теперь можно пробовать открыть наш сайт. Откройте браузер и введите в адресную строку http://имя_сервера /Security, появится ваша главная страница. Все! Если есть вопросы, с радостью отвечу в комментариях к статье.

Данное описание подходит для следующих редакций Windows 7: Профессиональная и Максимальная.

Установка веб-сервера IIS

Панель управления → Программы → Включение или отключение компонентов Windows. Находим в списке раздел - Службы IIS. Раскрываем его и выбираем нужные компоненты:

Базовый набор:

• Безопасность. Выбираем все компоненты кроме «Проверка подлинности с сопоставлением сертификата …».
• Компоненты разработки приложений. Выбираем только компонент CGI, это нужно для последующей установки PHP.
• Общие функции HTTP. Отмечаем все пункты.
• Проверка работоспособности и диагностика. Выбираем «Ведение журнала HTTP» и «Монитор запросов».
• Функции повышения быстродействия. Отмечаем все пункты.
• Средства управления веб-сайтом. Отмечаем только «Консоль управления IIS».

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

Теперь переходим к созданию веб-сайта. Открываем Панель управления → Система и безопасность → Администрирование → Управление компьютером (можно это сделать и быстрее: правый клик на Компьютер → в меню выбрать пункт Управление). В открывшемся окне слева нажав на маленький треугольник раскрываем группу «Службы и приложения» и открываем «Диспетчер служб IIS». В соседнем окне «Подключения» выбираем папку «Сайты» (если там есть Default Web Site, его можно удалить), затем в правом окне «Действия» нажимаем на ссылку «Добавить веб-сайт…» (можно сделать и так: правый клик → в меню выбрать «Добавить веб-сайт…»).

Далее в открывшемся окне необходимо указать имя веб-сайта и месторасположение его файлов (по умолчанию это c:\inetpub\wwwroot, если этот путь не указан по умолчанию, пропишите его вручную). Остальные опции оставляем без изменения.

Нажимаем OK. На этом базовая настройка завершена. Теперь нужно проверить работоспособность только что созданного сайта. Открываем браузер и в адресной строке вводим: http://localhost. Если все работает правильно, вы увидите похожую страницу:

Установка PHP (FastCGI)

Перед началом установки необходимо скачать релиз PHP с сайта http://windows.php.net/download/ . На выбор там предлагается несколько вариантов. Нам необходим релиз VC9 x86 Non Thread Safe . Для работы с IIS в режиме FastCGI это наиболее быстрый и стабильный вариант. Скачивайте релиз с установщиком (installer), а не zip-архив (это для любителей ручной установки). Примите во внимание, что с установщиком (installer) это не обязательно должна быть последняя выложенная версия PHP, ничего страшного не случится, если вы скачаете более раннюю версию.

Выбираем IIS FastCGI - сейчас это единственный стабильный вариант установки PHP на IIS.

После завершения работы установщика, переходим к настройкам IIS. В принципе здесь надо сделать только одно действие - поднять приоритет php-файлов, чтобы они обрабатывались в первую очередь. Открываем опять диспетчер служб IIS - правый клик на Компьютер → в меню выбираем пункт «Управление», в левом окошке раскрываем «Службы и приложения» → «Диспетчер служб IIS». В окне правее «Подключения» нажимаем по названию нашего сайта и в среднем окне открываем (кликаем 2 раза) раздел «Документ по умолчанию».

В появившемся списке необходимо переместить index.php в начало (т.е. в самый верх - для этого выделяем index.php и справа нажимаем «Вверх»):

Если используется Windows 7 64-бит, необходимо произвести одно дополнительное действие. Откройте раздел «Пулы приложений» (в окне «Подключения»). Выделите DefaultAppPool и откройте «Дополнительные параметры» (через правый клик или в крайней правой колонке «Действия»). В разделе (Общие) необходимо найти опцию «Разрешить выполнение 32-битных приложений» (Enable 32-bit Applications) и установить в положение True. Если уже созданы дополнительные пулы для уже существующих сайтов, то для каждого из них нужно проделать ту же операцию.

Теперь необходимо провести тестирование PHP. В корневую папку веб-сайта (c:\inetpub\wwwroot) необходимо поместить файл index.php со следующим содержанием:

Открываем сайт в браузере (http://localhost). Если все работает правильно, вы увидите страницу с информацией об установке PHP:

Открываем страницу загрузки дистрибутива: http://www.mysql.com/downloads/mysql/

Для Win 32 качаем: Windows (x86, 32-bit), MSI Installer
Для Win 64 качаем: Windows (x86, 64-bit), MSI Installer

После нажатия на кнопку Download вы увидите форму для регистрации, ее можно пропустить нажав на ссылку внизу (» No thanks, just start my download!).

Запускаем установщик, после нескольких не особо информативных окон нам предлагают выбрать тип установки, выбираем Custom:

Окно выбора компонентов (если вы новичок, оставляем все по умолчанию, жмем Next и устанавливаем):

В конце установки появится новое окно с вопросом о подписке, нажимаем крестик в верхнем правом углу.

Завершающий этап установки. Отмечаем опцию «Launch the MySQL Instance Configuration Wizard» (Запуск мастера конфигурации MySQL) и нажимаем Finish:

После завершения установки запускается MySQL Server Instance Configuration Wizard (его можно запустить вручную из Компьютер → Program Files → MySQL → MySQL Server 5.5 → bin → MySQLInstanceConfig.exe). Нажимаем Next:

Выбираем сценарий установки: Developer Machine - для установки на домашний компьютер (наш выбор), Server Machine - для установки на сервер, Dedicated MySQL Server Machine - для установки на сервер полностью выделенный под MySQL. Эти опции влияют в первую очередь на объем потребляемой MySQL памяти:

MySQL поддерживает два основных типа БД (InnoDB - с поддержкой транзакций и MyISAM - без транзакций). Multifunctional Database - будет установлена поддержка БД обоих типов (наш выбор). Transactional Database Only - будет установлена поддержка только InnoDB. Non-Transactional Database Only - будет установлена поддержка только MyISAM.

Если на предыдущем этапе была выбрана поддержка InnoDB, здесь можно настроить расположение файлов данных InnoDB:

Поддержка одновременных соединений. Decision Support - до 20 одновременных соединений (наш выбор). Online Transaction Processing - до 500 соединений. Manual Setting - ручная установка количества соединений.

Отмечаем опции «Enable TCP/IP Networking» и «Enable Strict Mode». Port Number оставляем без изменений - 3306. Если к серверу планируются прямые подключения с других компьютеров, отмечаем опцию «Add firewall exception for this port» (открыть порт в брандмауэре windows).

Выбираем кодировку по умолчанию. Сейчас самый разумный выбор - это UTF-8. Выбираем опцию Best Support For Multilingualism:

Обязательно отмечаем опцию «Install As Windows Service» (запускать как службу Windows). Отмечаем «Launch the MySQL Server automatically», если нужен автозапуск службы.

Завершающий этап. Установка пароля администратора (root). Этот пароль лучше не терять! Опции «Enable root access from remote machines» и «Create An Anonymous Account» отмечать не рекомендуется, т.к. они снижают безопасность.

Примечание: если вы до этого устанавливали MySQL, а потом удалили или переустановили, то на последнем этапе будет возникать ошибка 1045 (Connection Error). Чтобы этого не было, придется удалить MySQL, затем удалить скрытую папку MySQL находящуюся в C:\ProgramData (в этой папке находятся файлы информации о данных пользователя). После этого повторите процедуру установки и настройки.

Теперь осталось проверить успешно ли прошла установка. Открываем Пуск → Все программы → MySQL → MySql Server 5.5 → MySQL 5.5 Command Line Client (утилита для работы с MySQL в командной строке).

Далее вводим пароль администратора (root). Если пароль правильный, вы попадете в командную строку (mysql>). Введите команду: show databases; (точка с запятой на конце обязательны). В результате вы должны увидеть список баз данных (как минимум две - information_schema и mysql). Это означает, что сервер работает правильно. Закрываем командную строку выполнив команду exit.

Установка и базовая настройка phpMyAdmin

Открываем страницу загрузки http://www.phpmyadmin.net/home_page/downloads.php и выбираем для скачивания архив оканчивающийся на *all-languages.7z или *all-languages.zip. Создаем папку phpmyadmin в C:\inetpub\wwwroot\ и извлекаем туда файлы скаченного архива.

Проверим как оно работает. Открываем браузер и переходим по адресу http://localhost/phpmyadmin/ . Должно открыться такое окно:

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

Есть два варианта. Можно вручную отредактировать файл config.sample.inc.php и сохранить его как config.inc.php (оба файла в корне установки phpMyAdmin).

Или использовать графический конфигуратор. Для этого в браузере открываем следующий адрес: http://localhost/phpmyadmin/setup/

Если вы видите предупреждение «Невозможно загрузить или сохранить настройки». Создайте папку config в корне установки phpMyAdmin (это значит внутри папки phpmyadmin). Убедитесь, что в настройках безопасности папки config группе пользователей IIS_IUSRS и пользователю IUSR присвоены права полного доступа. Для тех кто не знает как это делается: правый клик на папку config → свойства → вкладка безопасность → нажимаем кнопку «Изменить…» → выделяем в списке IIS_IUSRS (...) и ниже отмечаем галочкой «Полный доступ», нажимаем «Применить». Тоже самое делаем и для IUSR. Если такого пользователя в списке нет, нажимаем «Добавить» → Дополнительно… → Поиск → выбираем IUSR и нажимаем ОК, затем ставим ему полный доступ.

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

Важнейший момент! Если вы подключаетесь к серверу MySQL установленному на той же машине (localhost), в графе «Хост сервера» localhost необходимо заменить на 127.0.0.1 (то же самое относится и к созданию config.inc.php вручную). Добавьте в файл C:\Windows\System32\drivers\etc\hosts строчку: 127.0.0.1 localhost. В этом же файле удалите или закомментируйте (поставить знак # в начале строки) строку::1 localhost (если она изначально закомментирована, то не надо ничего с ней делать).

Сохраняем настройки и автоматически возвращаемся на предыдущую страницу. Здесь выбираем язык по умолчанию - Русский, сервер по умолчанию - 127.0.0.1, конец строки - Windows.

На этом все. Возвращаемся на страницу http://localhost/phpmyadmin/. Теперь можно авторизоваться в системе под пользователем root (пароль вводите тот, который указывали при настройке MySQL для пользователя root). Тестируем подключение к MySQL. Если все прошло успешно (вы смогли войти в phpMyAdmin), папку config удаляем.

1. Предварительно создаем каталог TestSite для содержания сайта на в директории c:\inetpub на сервере. Это можно сделать и из базовой ОС: с помощью проводника открываем каталог \\win_web_srv\с$ и создаем папку или в командной строке на сервере с помощью команды mkdir .

2. В каталоге testsite создайте файл index.html следующего содержания

Тестовый сайт для экспериментов

3. В файле host в базовой ОС пропишем соответствие IP адреса нашего web-сервера и имени нового сайта TestSite.

4. Запускаем Диспетчер служб IIS в базовой ОС.

5. Подключаемся к нашему удаленному web-серверу.

6. На правой панели «Подключения» выбираем узел «сайты» , на левой панели «Действия» выбираем «Добавить веб-сайт»

7. В открывшемся окне определяем основные параметры сайта:

имя сайта – TestSite (можете задать произвольное, оно будет использоваться только для идентификации сайтав рамках web-сервера)

каталог содержимого, физический путь – c:\inetpub\testsite

Привязку выполним по host header.

имя узла – TestSite (вот по этому имени к сайту будет осуществляться доступ посетителей)

8. Таким образом, создали новый сайт и осуществили привязку по host header (имени узла).

9. Проверяем работает ли сайт. В браузере в строке URL напишите http://testsite/ Должны увидеть страничку index.html созданного сайта.

10. Сконфигурируем «Документ по умолчанию»

11. На панели подключений в узле сайты выбираем наш сайт TestSite и в центральной части основного окна выбираем пункт «Документ по умолчанию»

12. Документов по умолчанию может быть несколько, администратор может упорядочить список этих документов, тем самым определить последовательность поиска их в каталоге. Если документ по умолчанию не найден, то учитывается настройкой параметра Directory Browsing

13. Обратите внимание, что настройки для нашего сайта были унаследованы с более высокого уровня. Т.к. у нас имеется только страничка index.html и ничего другого пока не предвидится, то отредактируем эти настройки. Используйте пункты доступные на панели Действий справа:

· удалим все имена файлов из списка кроме index.html

· добавим новое имя default.html

· переместим файл index.html на самый верх

14. В итоге должна получиться такая примерно картинка

15. После изменений посмотрите в основном каталоге нашего сайта c:\inetpub\TestSite появился файл web.config , который содержит изменения в конфигурации только для конкретного сайта, относящиеся к настройкам Документа по умолчанию

16. Создадим виртуальную директорию.

17. В каталоге c:\inetpub\testsite на сервере создайте подкаталог vd .

18. В Диспетчере служб IIS щелкните правой кнопкой мыши на названии нашего сайта и выберите Обновить

19. Обратите внимание, в структуре сайта появилась папка, но это скорее реальная папка, а не виртуальная J. Т.к. она располагается в физической структуре каталогов нашего сайта.

20. В браузере в строке URL напишите http://testsite/vd, вы получите следующее сообщение об ошибке

21. Такая реакция web-сервера объясняется тем, что в каталоге vd нет ни одного файла указанного в настройках Документа по умолчанию , а настройка Directory Browsing унаследованная от сайта имеет значение параметра Enabled=False , т.е. просмотр каталогов запрещен.

22. Разрешим просмотр каталогов для папки vd

23. В структуре сайта выбираем папку VD , и на странице Возможностей в группе IIS выбираем пункт Просмотр каталога .Таким образом, мы сможем не только настроить параметры отображения содержания каталога, но прежде всего включить такую возможность для папки VD.

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

25. Обновляем страничку в браузере

26. Обратите внимание, что автоматически в каталоге VD был создан файл web.config , в котором определено как раз разрешения просмотра каталога

27. Пробуем создать «настоящую» Виртуальную директорию за пределами структуры каталогов нашего сайта. Например в корне диска С создадим каталог VD_TestSite. Соответственно в отличие от папки VD, эта папка не попала автоматически в структуру нашего сайта.

28. В Диспетчере служб IIS щелкаем правой кнопкой мыши на узле нашего сайта (TestSite) и выбираем пункт «Добавить виртуальный каталог»

29. Остается только определить параметры виртуальной директории и указать ее физическое месторасположение

30. В окне «Добавление виртуального каталога» определяем параметры виртуальной директории: псевдоним и физическое расположение. Обратите внимание алиас (псевдоним) не соответствует названию папки. В строке браузера в URL необходимо будет использовать как раз указанный псевдоним.

31. Обратите внимание на отличие иконок двух папок в структуре сайта

32. В каталогt c:\VD_TestSite создайте примитивную html страничку с именем index.html

33. В браузере в строке URL наберите http://testsite/vd1. Убедитесь, что созданная страничка отображается. В общем случае виртуальная директория может ссылаться на каталог, расположенный даже на другой физической машине, в этом случае путь указывается UNC путь.

34. Попробуем намного поэкспериментировать с различными способами привязки сайта.

35. Пробуем выполнить привязку сайта к порту.

36. В Диспетчере служб IIS , на панели «Действия» выбираем «Привязки» , затем «Добавить» и указываем нестандартный порт 4545

37. В браузере в строке URL напишите http://web_win_srv. Должны увидеть страничку Default Web Site , т.е. сайта по умолчанию.

38. Попробуем теперь в строке URL написать http://web_win_srv:4545. Должна открыться страничка нашего сайта – TestSite.

39. Таким образом, получили, что наш сайт привязан двумя способами:

· порт 80 и host header TestSite

· порт 4545

40. Ознакомимся с настройками ограничений для нашего сайта.

41. На панели «Действия» выбираем пункт «Дополнительные параметры»

42. Странные большие числа значений параметров «Максимальная пропускная способность» и «Максимальное число подключений» обозначают, что ограничения не заданы.

43. Ограничения можно изменить с помощью пункта «Ограничения…» на панели «Действия»

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

45. В браузере попробуйте открыть заведомо несуществующую страничку на нашем сайте, например http://testsite/test.html. Т.к. такой страницы нет, то сервер возвратит сообщение о ошибке с кодом 404 . Это сообщение можно изменить и сделать более «дружественным» по отношению к посетителю.

46. Посмотрим все страницы соответствующие ошибкам для сайта TestSite, которые он унаследовал с уровня Web-сервера

47. Попробуем изменить сообщение при возникновении ошибки 404 .

48. Создадим собственную html-страничку с именем 404.htm и разместим ее в каталоге c:\inetpub\TestSite\err .Содержание файла 404.htm

Файл не найден

К сожалению, здесь нет того содержания, которое Вы искали.

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

49. На панели Действия выбираем пункт «Изменить…»

50. В браузере попробуйте открыть заведомо несуществующую страничку на нашем сайте, например http://testsite/test.html

51. Смотрим на созданную нами специально для ошибки 404 странницу.

52. Теперь поэкспериментируем с подключением к нашему сайту и работу с ним посредством защищенного протокола HTTPS на основе SSL сертификатов.

53. Посмотрим сертификаты, которые присутствуют на нашем локальном компьютере (базовая ОС) и web-сервере. Для этого воспользуемся соответствующей оснасткой консоли управления MMC.

54. Запускаем консоль управления из командной строки cmd .

55. Выполним добавление нужной нам оснастки.

Файл –> Добавить или удалить оснастку

56. Из списка доступных оснасток выбираем «Сертификаты» и жмем кнопку «Добавить» .

57. В открывшемся окне выбираем опцию «учетная запись компьютера» , жмем «Далее» и «Готово»

58. После этого оснастка появится в списке «Выбранные оснастки…» , для завершения жмем «ОК»

59. Аналогичным образом в эту же консоль добавим оснастку «Сертификаты» для удаленного web-сервера. Только в процессе настройки укажите имя удаленного web-сервера.

60. Таким образом, получаем доступ к управлению сертификатами, расположенными в хранилищах на локальном компьютере (базовая ОС) и удаленного web-сервера.

62. Для работы по протоколу HTTPS необходимо иметь сертификат сервера, причем этот сертификат должен быть заверен центром сертификации. В рамках лабораторной работы мы не будем «заморачиваться» созданием «полноценного» сертификата, который было бы правильно использовать. Сертификат для нашего web-сервера мы заверим самоподписанным корневым сертификатом, который сами создадим и перенесем в хранилище доверенных корневых сертификатов на локальной машине (базовая ОС). Понятно, что это «не спортивно», а в реальной жизни нельзя использовать, но для наших экспериментов вполне сойдет. Это является следствием того, что в нашей лабораторной сети слишком много условностей и нет самого главного Центра сертификации или хотя бы работающего контроллера домена.

63. Еще одно препятствие обусловлено режимом инсталляции web-сервера – Server Core, в котором нет «Диспетчера служб IIS», поэтому все действия по конфигурации выполняем преимущественно удаленно или в режиме командной строки. При удаленном управлении IIS с помощью «Диспетчера служб IIS» нет доступа к функции управления сертификатами для IIS (для сравнения см. картинки ниже, скриншоты с web-сервера в режиме установки Full). Но мы не ищем легких путей.

64. Итак, создаем все сертификаты с помощью командной строки. Для этого будем использовать утилиту makecert.exe из Windows SDK for Windows Server 2008 and .Net Framework 3.5

65. Создаем самоподписанный корневой сертификат. На web-сервере в командной строке (cmd) вводим команду

makecert.exe –ss root –sr localMachine –n “CN=TestCompany” -eku 1.3.6.1.5.5.7.3.1 –r

–ss root указывает, что сертификат будет создан в хранилище доверенных корневых сертификатов

–r – создаем самоподписанный сертификат

–eku 1.3.6.1.5.5.7.3.1 – идентификатор сертификата для Server Authentication; для клиента нужно использовать Client Authentication (1.3.6.1.5.5.7.3.2)

66. Создаем сертификат для web-сайта, подписанный нашим корневым сертификатом. Важно, что бы значение параметра CN совпадало в точности с именем сайта URL. Например, создаваемый сертификат будет корректным только для сайта testsite, но не будет корректным для www.testsite.

makecert –pe –ss my –n “CN=testsite” –b 01/01/2013 –e 01/01/2036 –sky exchange –in “TestCompany” –is root –eku 1.3.6.1.5.5.7.3.1 –sr localMachine

67. В результате проделанных манипуляций имеем созданный корневой сертификат в хранилище «Доверенные центры сертификации» и собственный сертификат для web-сайта в хранилище «Личное»

68. Самостоятельно найдите эти сертификаты в консоли управления базовой ОС.

69. Открываем «Диспетчер служб IIS» и выполним привязку тестового web-сайта для обеспечения возможности обращения к нему по протоколу HTTPS. Следует обратить внимание, что при привязке выбираем протокол HTTPS и в качестве Сертификата SSL указываем созданный нами сертификат с именем «testsite»

70. В браузере пробуем обратиться к тестовому сайту по протоколу HTTPS.

https:\\testsite

71. Обратите внимание, т.к. организация «TestCompany» не известна нашей локальной машине, то браузер выдал предупреждение

72. Несмотря на предупреждение, продолжаем работу с сайтом.

73. Что бы все было красиво, необходимо поместить корневой сертификат нашей тестовой организации (TestCompany) в хранилище доверенных корневых сертификатов на локальном компьютере (базовая ОС). Выполним экспорт корневого сертификата в файл (например, TestCompany.cert) с помощью консоли управления.

74. Выполним импорт сертификат из файла TestCompany.cert в хранилище доверенных корневых сертификатов локальной машине (базовая ОС).

75. В браузере откроем опять наш тестовый сайт, использую для доступа к нему протокол HTTPS. Видим, что идентификация сертификата прошла успешно.

76. Попробуйте использовать протокол HTTP для работы с тестовым сайтом.

http:\\testsite

77. Видим, что сайт может обрабатывать как запросы HTTP, так и HTTPS. Для запрещения использовать протокол HTTP, а обрабатывать все запросы только по протоколу HTTPS необходимо в настройках web-сайта «Параметры SSL» выбрать опцию «Требовать SSL» . Кроме того, в здесь же можно настроить поведения web-сайта относительно SSL сертификата клиента.

78. Теперь пробуем обратиться к тестовому сайту по протоколу HTTP. Видим, что доступ запрещен.

79. Если мы попытаемся использовать для другого сайта (например, для сайта по умолчанию) SSL сертификат, выпущенный для сайта TestSite, то в окне браузера получим сообщение об ошибке.

80. Выполните самостоятельно привязку сайта по умолчанию на использование протокола HTTPS и SSL сертификата, созданного для сайта TestSite и убедитесь в возникновении ошибки.

81. Создайте самостоятельно SSL сертификат для сайта по умолчанию и выполните изменение привязки для корректной работы сайта по умолчанию попротоколу HTTPS.

82. Ну и на последок самое интересное…

83. Обеспечим возможность размещать на нашем web-сервере сайты, созданные с помощью PHP.

84. Прежде всего, проверяем, поддерживается наш web-сервер CGI. Убеждаемся, что при инсталляции компонента IIS-CGI не была установлена

oclist | more

85. Устанавливаем модуль IIS-CGI

Обычно, когда говорят о web-сервере, подразумевают решения на базе платформы Linux. Но если ваша инфраструктура развернута на основе Windows Server то логично будет использовать веб-сервер IIS. Вопреки распространенному мнению, это весьма популярная платформа, которая позволяет работать как с большинством популярных CMS, так и имеет широкий спектр систем, предназначенных для работы именно на Windows и IIS.

Несомненным достоинством IIS является его тесная интеграция с другими технологиями и средствами разработки Microsoft. В частности веб-решения для IIS могут использовать богатые возможности.NET и легко взаимодействовать с настольными приложениями на этой платформе. Если же вас это пока не интересует, то к вашим услугам богатый выбор готовых CMS, в том числе написанных специально для IIS. Сегодня мы рассмотрим как установить и настроить IIS для работы с веб-решениями на базе ASP.NET и установим одну из популярных CMS для этой платформы.

Для установки веб-сервера на платформе Windows перейдем в оснастку Роли в Диспетчере сервера и выберем установку ролей Веб-сервер (IIS) и Сервер приложений .

Но не спешите нажимать Далее, слева, под названием каждой роли, доступна опция Службы ролей , перейдем на нее и установим для Сервера приложений следующие опции: Поддержка веб-сервера (IIS), Общий доступ к TCP-портам и Активация через HTTP.

А для веб-сервера установите службу FTP-сервер.

После чего установите выбранные роли. Для проверки работоспособности IIS наберите в браузере IP-адрес вашего сервера, вы должны будете увидеть стандартную страницу-заглушку веб-сервера.

Теперь перейдем в к настройке сервера, для этого откроем Диспетчер служб IIS (находится в Пуск - Администрирование).

Первым делом создадим новый сайт, для этого щелкните правой кнопке на пункте Сайты в боковом меню Диспетчера IIS и выберите Создать новый сайт .

В открывшемся окне укажите имя сайта, путь к корневой папке (по умолчанию сайты пользователей располагаются в C:\inetpub\wwwroot ), которую следует предварительно создать и укажите имя узла (доменное имя сайта), в нашем случае iissite.local

Не забудьте добавить A-запись с именем вашего сайта на DNS-сервер или пропишите необходимые строки в файлы hosts тех рабочих станций, откуда будете обращаться к сайту

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

Далее укажите привязку FTP-cлужбы к сетевым интерфейсам и портам, а также настройте параметры безопасности. Если вы собираетесь использовать SSL, то учтите что вам потребуется сертификат, хотя если вы будете использовать FTP-доступ только для собственных нужд, то можно обойтись самоподписанным сертификатом. Не забудьте поставить галочку для автоматического запуска FTP-сайта.

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

Веб-сервер настроен и вы можете использовать его для размещения HTML-страниц, однако современные сайты используют для хранения своих данных СУБД, поэтому следующим шагом установим MS SQL Express 2012 , возможностей которого с лихвой хватит для наших задач. Установка производится со значениями по умолчанию, кроме Режима проверки подлинности , который следует переключить в Смешанный режим и задать пароль суперпользователю SQL-сервера sa .

Теперь попробуем установить какую либо популярную CMS созданную на базе технологии ASP.NET, обширный выбор таких решений представлен в галерее web-приложений Microsoft. Обратите внимание, что по кнопке скачать вы получите пакет для установки через Web PI, для установки на IIS вам потребуется перейти на сайт разработчика и скачать полный пакет с CMS

Мы будем устанавливать Orchard CMS , для получения пакета пройдите по ссылке и выберите Загрузить как zip , распакуйте полученный архив и закачайте в корень сайта содержимое папки Orchard.

Данная CMS создана на базе ASP.NET 4, поэтому настроим наш сайт на использование необходимых технологий. Для этого щелкните правой кнопкой на имени сайта в боковом меню и выберите Управление веб-сайтом - Дополнительные параметры

В открывшемся окне измените параметр Пул приложений , указав там ASP.NET v.4

Затем установите необходимые права на папку с сайтом, вам нужно добавить пользователю IIS_IUSRS возможность записи и изменения содержимого данной папки.

Также не забудьте создать базу данных для сайта, для этого зайдите в SQL Server Management Studio и, щелкнув правой кнопкой на пункте Базы данных в боковом меню, создайте новую базу.

В прошлом году мне пришлось отсобеседовать около 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. Общий план

Рис. 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

Встроенный в ядро 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)

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

В 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)

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

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

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

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

Для управления некоторыми параметрами отдельно взятого рабочего процесса 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. Домен приложения, приложение

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в.NET Framework).

Рис. 7. Рисунок для задачки.

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

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

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

Как мы уже знаем, модули в IIS бывают 2 типов: нативные и управляемые. Точный список модулей вы можете почерпнуть в MSDN-е или в статье Риган Темплин. Вы всегда можете написать свой модуль, например, для редиректов. Чаще всего, конечно, делают управляемые модули, т.к. их проще всего реализовать. К слову, ASP.NET WebForms и MVC работают в виде таких вот управляемых модулей. Т.ч. лично у меня холивары WebForms vs. MVC вызывают улыбку и трудно сдерживаемое желание потроллить. Зная принципы работы IIS и ASP.NET, вы сами сможете реализовать любой понравившийся вам паттерн.

На следующем уровне рассмотрения мы столкнёмся уже с составляющими ASP.NET, такими как HttpHandler-ы и события обработки страницы. Про это написана масса статей, т.ч. не вижу смысла сколько-нибудь задерживаться на этом. Единственное, позволю себе посоветовать идущим на собеседования забить в поисковике «ASP.NET page lifecycle» перед встречей – этого уж точно по моему глубокому убеждению стыдно не знать специалистам, считающих себя разработчиками на ASP.NET.

Пример дефолтных настроек нативных модулей в applicationHost.config