После развертывания сайтом можно управлять с применением средств IIS. Ниже рассматриваются наиболее полезные опции конфигурирования и способы их использования.
Создание нового сайта
IIS 8 может поддерживать множество сайтов на одном сервере. В рассмотренных примерах развертывания содержимое добавлялось к сайту по умолчанию, а в этом разделе будет показано, как создать совершенно новый сайт. Разверните древовидное представление в IIS Manager, щелкните правой кнопкой мыши на узле Sites (Сайты) и в контекстном меню выберите пункт Add Web Site. (Добавить веб-сайт. ). Откроется диалоговое окно Add Web Site, показанное на рисунке ниже:
Поле Site name (Имя сайта) должно содержать что-нибудь значащее. Оно используется для идентификации сайта в среде IIS Manager, но не влияет на содержимое сайта. В этом примере пул приложений был оставлен без изменений (пулы приложений рассматриваются далее). Поле Physical path (Физический путь) определяет местоположение, в котором IIS 8 будет искать содержимое для запросов на обслуживание, адресованных новому сайту. В этом примере на сервере был создан новый каталог D:\WebSites. Кнопки Connect as. (Подкл. как. ) и Test Settings. (Тест настроек. ) позволяют указать другие учетные данные пользователя для доступа к содержимому сайта.
Раздел Bindings (Привязка) позволяет указать, как IIS 8 будет прослушивать запросы, поступающие от клиентов. IIS 8 поддерживает множество протоколов, но мы сосредоточим внимание на HTTP, поскольку он используется наиболее широко. Для этого в списке Type (Тип) выберем опцию http.
Создание виртуальных каталогов
При установке места назначения для примеров веб-сайтов содержимое помещается в каталог, в котором IIS 8 ищет содержимое по умолчанию. Но содержимое можно было бы разместить где-то в другом месте, а затем использовать виртуальный каталог для ссылок на него. Чтобы продемонстрировать этот подход, создадим на сервере новый каталог и скопируем в него содержимое сайта. Путь к новому каталогу выглядит следующим образом:
Чтобы связать новый каталог с IIS, откройте IIS Manager, разверните древовидное представление, щелкните правой кнопкой мыши на элементе Default Web Site и в контекстном меню выберите пункт Add Virtual Directory (Добавить виртуальный каталог). В результате откроется диалоговое окно Add Virtual Directory (Добавление виртуального каталога), показанное на рисунке ниже:
Чтобы протестировать его, откройте браузер на сервере и направьте его на URL-адрес http://localhost/virtual. Как и ранее, откроется созданный нами простой веб-сайт, но на этот раз содержимое будет извлекаться из нового каталога, а доступ к нему будет осуществляться с помощью указанного специального URL-адреса.
Использование пулов приложений
Пулы приложений позволяют для упрощения конфигурирования и управления группировать вместе аналогичные или связанные приложения. При этом приложения, которые включены в пулы приложений, изолируются, в результате чего проблемы, возникающие в одном пуле, не оказывают влияния на приложения из других пулов.
Характеристики пулов приложений, отображаемые в главном окне IIS Manager
Столбец
Описание
Name (Имя)
Определяет имя пула приложений. После того как пул создан, его имя изменить нельзя
Учетная запись Windows, используемая для запуска приложений пула
Количество приложений, назначенных в пул; на рисунке выше видно, что пул DefaultAppPool содержит три приложения
Создание нового пула приложений
Нестандартный пул приложений можно создать, щелкнув на действии Add Application Pool (Добавить пул приложений) в правой части экрана IIS Manager. Откроется диалоговое окно Add Application Pool (Добавление пула приложений), показанное на рисунке ниже:
Щелкните на кнопке OK, и новый пул будет создан и добавлен в список IIS Manager. Щелчок на действии Advanced Settings. (Дополнительные параметры) позволит сконфигурировать детали, связанные с пулом.
Назначение приложения в пул приложений
Чтобы назначить приложение в пул приложений, выберите приложение в окне IIS Manager и щелкните на действии Basic Settings (Основные настройки) в правой части экрана. Откроется диалоговое окно Edit Application (Изменение приложения). Щелкните на кнопке Select (Выбрать) и выберите пул приложений из раскрывающегося списка, как показано на рисунке ниже. Мы выбрали специальный пул приложений, созданный в предыдущем разделе:
Запуск и останов пула приложений
После щелчка на пуле приложений в правой части окна IIS Manager в разделе Application Pool Tasks (Задачи пула приложений) отобразятся три действия. Действия Start (Начало) и Stop (Остановить) определяют то, обслуживаются ли запросы, адресованные назначенным в пул приложениям. Если пул остановлен, клиенты будут получать сообщение об ошибке. Действие Recycle (Перезапуск) переустанавливает пул приложений. Это полезно для устранения постепенно накапливающихся и трудных для диагностирования проблем.
Использование параллельного выполнения
Пулы приложений позволяют на одном сервере запускать приложения, которые требуют различных версий ASP.NET. При использовании унаследованных приложений или постепенной модернизации приложений до ASP.NET 4 можно формировать различные пулы приложений для обеспечения того, чтобы каждое приложение работало с требуемыми функциональными средствами.
Application Pool Identities в IIS
Каждый пул приложений в IIS использует свой собственный рабочий процесс (IIS Worker Process). Удостоверение пула приложений (Application Pool Identities) представляет из себя имя учетной записи, под которой выполняется рабочий процесс этого пула.
В IIS 6.0 и IIS 7.0 пул приложений по умолчанию работал под встроенной системной учетной записью NetworkService. Эта запись не требует пароля и имеет на локальном компьютере ограниченные права, что является хорошей практикой с точки зрения безопасности. Однако под этой учетной записью могут одновременно работать разные системные службы Windows, и при использовании одного и того же идентификатора одни службы могут воздействовать на работу других.
Начиная с Windows Server 2008 SP2 для того, чтобы изолировать рабочие процессы IIS от других системных служб, можно использовать виртуальные учетные записи (Virtual Accounts). Они позволяют запускать рабочий процесс для каждого пула приложений под собственной уникальной учетной записью ApplicationPoolIdentity. Эта учетная запись не требует управления и создается автоматически при создании каждого нового пула. Также она не имеет практически никаких привилегий в системе и не использует профиль пользователя, что повышает безопасность веб-сервера.
Для примера возьмем Application Pool с именем PubSite1. Открываем Task Manager и находим рабочий процесс IIS (w3wp.exe), выполняющийся от имени PubSite1. Как видите, имя учетной записи совпадает с именем пула приложений. Дело в том, что начиная с IIS 7.5 для каждого вновь созданного пула приложений по умолчанию создается виртуальная учетная запись с именем этого пула, и его рабочий процесс запускается из под этой записи.
Настройка типа удостоверения пула приложений
При необходимости тип идентификации пула приложений можно изменить. Для этого запускаем IIS Manager, переходим в раздел Application Pools, выбираем нужный пул и открываем его свойства (Advanced Settings).
В свойствах выбираем пункт Identity.
Здесь мы указываем учетную запись, от имени которой будет работать данный пул приложений:
• ApplicationPoolIdentity — учетная запись удостоверения пула приложений. Создается автоматически при запуске пула приложений и имеет самые минимальные права на локальном компьютере. Это наиболее безопасный вариант, начиная с IIS 7.5 используется по умолчанию; • LocalService – встроенная учетная запись, которая имеет ограниченные права на локальном компьютере. Примерно то же самое, что и NetworkService, но ограничена только локальным компьютером; • LocalSystem – системная учетная запись, имеющая неограниченные права на локальном компьютере. Наименее безопасный вариант, по возможности не рекомендуется ее использовать; • NetworkService — учетная запись, которая имеет ограниченные права на локальном компьютере, а также может использоваться для доступа к ресурсам в сети Active Directory на основании учетной записи компьютера.
Кроме того, в качестве удостоверения можно использовать и обычную учетную запись пользователя. Для этого надо выбрать Custom Account, нажать кнопку Set и ввести имя пользователя и пароль. Можно указать любого доменного или локального пользователя.
Примечание. При использовании учетной записи пользователя надо отслеживать срок действия пароля и своевременно менять его.
То же самое можно сделать с помощью утилиты командной строки appcmd. Чтобы указать учетную запись, которая будет использоваться для пула приложений, используется следующий синтаксис:
appcmd set config /section:applicationpools /[name=″имя пула приложений″].processModel.identityType:SpecificUser|NetworkService|LocalService|LocalSystem
Для примера изменим тип удостоверения для пула приложений PubSite1 на NetworkService:
appcmd set config /section:applicationpools /[name=″PubSite1″].processModel.identityType:NetworkService
Профиль пользователя
Если вы хотите настроить ApplicationPoolIdentity на использование пользовательского профиля, то надо зайти в расширенные свойства пула и перевести параметр Load User Profile в состояние True.
Настройка доступа к ресурсам
Иногда веб-приложению может потребоваться доступ к определенной папке или файлу на диске. Чтобы добавить ApplicationPoolIdentity в Access Control List (ACL):
• Запускаем Windows Explorer; • Выбираем нужный файл или директорию, кликаем по ней правой клавишей мыши и выбираем пункт Свойства (Properties); • Переходим на вкладку Безопасность (Security), • Кликаем по кнопке Изменить (Edit), затем Добавить (Add); • В поле Размещение (Locations) выбираем локальную машину; • Вводим имя пользователя в виде ″IIS AppPool\имя пула приложений″. Так для пула приложений PubSite1 имя пользователя будет выглядеть ″IIS AppPool\PubSite1″; • Проверяем имя клавишей Проверить имена (Check Names) и жмем ОК.
Также при желании можно воспользоваться утилитой командной строки ICACLS. Для примера дадим права на изменение для PubSite1:
D – удаление; F – полный доступ; M – изменение; RX – чтение и выполнение; R – чтение; W – запись.
Если ресурс находится в сети, то для доступа к нему лучше всего использовать учетную запись NetworkService. Рабочий процесс, запущенный под этим аккаунтом, для доступа к ресурсам использует учетные данные компьютера, сгенерированные при добавлении компьютера в домен. Для того, чтобы дать процессу доступ к сетевому ресурсу, в качестве пользователя указываем компьютер:
• Выбираем тип объекта (Object Type) Computers; • В поле Размещение (Locations) выбираем домен; • Вводим имя пользователя в виде domainname\machinename$, например contoso\SRV12$; • Проверяем имя и жмем ОК.
Очень удобный способ предоставлять доступ к сетевым ресурсам типа файловых шар или баз данных SQL Server. Однако работает он только при наличии домена AD.
Application Pool Identities
Whether you are running your site on your own server or in the cloud, security must be at the top of your priority list. If so, you will be happy to hear that IIS has a security feature called the application pool identity. This feature was introduced in Service Pack 2 (SP2) of Windows Server 2008 and Windows Vista. An application pool identity allows you to run an application pool under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The image below shows an IIS worker process (W3wp.exe) running as the DefaultAppPool identity.
Application Pool Identity Accounts
Worker processes in IIS 6.0 and in IIS 7 run as Network Service by default. Network Service is a built-in Windows identity. It doesn’t require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can’t be used by a malicious user to take over the whole system.
However, a problem arose over time as more and more Windows system services started to run as Network Service. This is because services running as Network Service can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called «virtual accounts» that allows IIS to create a unique identity for each of its application pools. For more information about virtual accounts, see Service Accounts Step-by-Step Guide.
Configuring IIS Application Pool Identities
If you are running IIS 7.5 on Windows Server 2008 R2, or a later version of IIS, you don’t have to do anything to use the new identity. For every application pool you create, the Identity property of the new application pool is set to ApplicationPoolIdentity by default. The IIS Admin Process (WAS) will create a virtual account with the name of the new application pool and run the application pool’s worker processes under this account by default.
To use this virtual account when running IIS 7.0 on Windows Server 2008, you have to change the Identity property of an application pool that you create to ApplicationPoolIdentity. Here is how:
Open the IIS Management Console (INETMGR.MSC).
Open the Application Pools node underneath the machine node. Select the application pool you want to change to run under an automatically generated application pool identity.
Right click the application pool and select Advanced Settings
Select the Identity list item and click the ellipsis (the button with the three dots).
The following dialog appears:
Select the Built-in account button, and then select the identity type ApplicationPoolIdentity from the combo box.
To do the same step by using the command-line, you can call the appcmd command-line tool the following way:
Securing Resources
Whenever a new application pool is created, the IIS management process creates a security identifier (SID) that represents the name of the application pool itself. For example, if you create an application pool with the name «MyNewAppPool,» a security identifier with the name «MyNewAppPool» is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console.
You can try this by selecting a file in Windows Explorer and adding the «DefaultAppPool» identity to the file’s Access Control List (ACL).
Open Windows Explorer
Select a file or directory.
Right click the file and select Properties
Select the Security tab
Click the Edit button and then Add button
Click the Locations button and make sure that you select your computer.
Enter IIS AppPool\DefaultAppPool in the Enter the object names to select: text box.
Click the Check Names button and click OK.
By doing this, the file or directory you selected will now also allow the DefaultAppPool identity access.
You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.
For more information, see ICACLS.
Accessing the Network
Using the Network Service account in a domain environment has a great benefit. Worker process running as Network Service access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:
The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.
What about Application Pool Identities?
The good news is that application pool identities also use the machine account to access network resources. No changes are required.
Compatibility Issues with Application Pool Identities
Guidance Documentation
The biggest compatibility issue with application pool identities is probably earlier guidance documents which explicitly recommend that you ACL resources for Network Service, that is, the default identity of the DefaultAppPool in IIS 6.0 and IIS 7.0. Customers will have to change their scripts to ACL for «IIS AppPool\DefaultAppPool» (or another application pool name) when running on IIS 7.5 or later (see the example above for how to do this).
User Profile
However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to «true».
Summary
Application pool identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, and later versions of Windows. It will make running IIS applications even more secure and reliable.
Расширенная настройка модуля ASP.NET Core и служб IIS
В этой статье рассматриваются параметры и сценарии расширенной настройки модуля ASP.NET Core и служб IIS.
Изменение размера стека
Применяется только при использовании модели внутрипроцессного размещения.
Конфигурация прокси-сервера использует протокол HTTP и токен связывания
Применяется только к размещению вне процесса.
Прокси-сервер, созданный между модулем ASP.NET Core и Kestrel, использует протокол HTTP. Отсутствует риск перехвата трафика между модулем и Kestrel из расположения за пределами сервера.
Токен связывания гарантирует, что полученные Kestrel запросы были переданы через прокси-сервер IIS, а не из какого-либо другого источника. Этот токен создается и задается модулем в переменную среды ( ASPNETCORE_TOKEN ). Он также задается в заголовке ( MS-ASPNETCORE-TOKEN ) каждого запроса, переданного через прокси-сервер. ПО промежуточного слоя IIS проверяет каждый получаемый запрос, чтобы убедиться, что заголовок с токеном связывания соответствует значению переменной среды. Если значения токена не совпадают, запрос заносится в журнал и отклоняется. Переменная среды с токеном связывания и трафик между модулем и Kestrel недоступны из расположения за пределами сервера. Не зная значение токена связывания, злоумышленник не может отправлять запросы, обходящие проверку в ПО промежуточного слоя IIS.
Модуль ASP.NET Core с общей конфигурацией IIS
При использовании общей конфигурации IIS на том же компьютере, где установлены службы IIS, запустите установщик пакета размещения ASP.NET Core с параметром OPT_NO_SHARED_CONFIG_CHECK со значением 1 :
Если путь к общей конфигурации не на том же компьютере, где установлены службы IIS, выполните следующие действия.
Защита данных
Стек защиты данных ASP.NET Core используют несколько ПО промежуточного слоя ASP.NET Core, включая ПО, которое применяется для аутентификации. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, защиту данных следует настроить для создания постоянного хранилища криптографических ключей. Это можно сделать с помощью скрипта развертывания или в пользовательском коде. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.
Если набор ключей для защиты данных хранится в памяти, при перезапуске приложения происходит следующее.
Чтобы настроить защиту данных в службах IIS для хранения набора ключей, воспользуйтесь одним из следующих методов:
Создание разделов реестра для защиты данных
Ключи защиты данных, используемые приложениями ASP.NET Core, хранятся во внешнем для приложений реестре. Чтобы хранить эти ключи для определенного приложения, нужно создать разделы реестра для пула приложений.
При автономной установке служб IIS, не поддерживающей веб-ферму, можно выполнить скрипт PowerShell Provision-AutoGenKeys.ps1 для защиты данных применительно к каждому пулу приложений, в который входит приложение ASP.NET Core. Этот скрипт создает раздел в реестре HKLM, который будет доступен только для учетной записи рабочего процесса пула приложений, к которому относится соответствующее приложение. Неактивные ключи шифруются с помощью API защиты данных с ключом компьютера.
В случаях, когда используется веб-ферма, в приложении можно настроить UNC-путь, по которому это приложение будет хранить набор ключей для защиты данных. По умолчанию ключи не шифруются. Разрешения на доступ к файлам в сетевой папке должны быть предоставлены только учетной записи Windows, с помощью которой выполняется приложение. Для защиты неактивных ключей можно использовать сертификат X509. Рассмотрите возможность реализации механизма, позволяющего пользователям отправлять сертификаты. поместите сертификаты в хранилище доверенных сертификатов пользователя и обеспечьте их доступность на всех компьютерах, где выполняется приложение. Дополнительные сведения см. в разделе Настройка защиты данных в ASP.NET Core.
Настройка пула приложений IIS для загрузки профиля пользователя.
Использование файловой системы в качестве хранилища набора ключей.
Измените код приложения так, чтобы в качестве хранилища набора ключей использовалась файловая система. Для защиты набора ключей используйте доверенный сертификат X509. Если сертификат — самозаверяющий, поместите его в доверенное корневое хранилище.
При использовании служб IIS в веб-ферме:
Настройка политики защиты данных на уровне компьютера
Система защиты данных обеспечивает ограниченную поддержку задания политики по умолчанию на уровне компьютера для всех приложений, использующих интерфейсы API защиты данных. Дополнительные сведения см. в разделе ASP.NET Core Защита данных.
Конфигурация IIS
Операционные системы семейства Windows Server
Включите роль сервера Веб-сервер (IIS) и настройте службы роли.
После этапа выбора компонентов запускается этап выбора служб роли для веб-сервера (IIS). Выберите нужные службы роли IIS или оставьте службы по умолчанию.
Проверка подлинности Windows (необязательный компонент) Чтобы включить проверку подлинности Windows, разверните такие узлы: Веб-сервер > Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Проверка подлинности Windows и Настройка проверки подлинности Windows.
Протокол WebSocket (необязательный компонент) Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Веб-сервер > Разработка приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.
Пройдите этап Подтверждение, чтобы установить роль и службы веб-сервера. После установки роли Веб-сервер (IIS) перезагружать сервер или службы IIS не требуется.
Операционные системы Windows для настольных компьютеров
Включите компоненты Консоль управления IIS и Службы Интернета.
Последовательно выберите Панель управления > Программы > Программы и компоненты > Включение или отключение компонентов Windows (в левой части экрана).
Разверните узел Службы IIS. Разверните узел Средства управления веб-сайтом.
Установите флажок Консоль управления IIS.
Установите флажок Службы Интернета.
В группе Службы Интернета оставьте компоненты по умолчанию или настройте компоненты IIS.
Проверка подлинности Windows (необязательный компонент) Чтобы включить проверку подлинности Windows, разверните такие узлы: Службы Интернета > Безопасность. Выберите компонент Проверка подлинности Windows. Дополнительные сведения см. в статьях Проверка подлинности Windows и Настройка проверки подлинности Windows.
Протокол WebSocket (необязательный компонент) Протокол WebSocket поддерживается в ASP.NET Core начиная с версии 1.1. Чтобы включить протокол WebSocket, разверните такие узлы: Службы Интернета > Компоненты разработки приложений. Выберите компонент Протокол WebSocket. Дополнительные сведения см. в разделе Протокол WebSocket.
Если во время установки IIS потребуется перезагрузка, перезагрузите систему.
Виртуальные каталоги
Виртуальные каталоги IIS не поддерживаются в приложениях ASP.NET Core. Приложение может размещаться как вложенное.
Вложенные приложения
Приложение ASP.NET Core можно разместить как вложенное приложение IIS. Путь к вложенному приложению становится частью URL-адреса главного приложения.
В ссылках на статический ресурс во вложенном приложении следует использовать нотацию
Если атрибуту src статического ресурса присваивается абсолютный путь (например, src=»https://docs.microsoft.com/image.png» ), ссылка отображается без свойства pathbase вложенного приложения. ПО промежуточного слоя для обработки статических файлов в главном приложении пытается найти ресурс в корневом веб-каталоге главного приложения, что приводит к ошибке 404 — Not Found (не найдено), кроме случаев, когда статический ресурс доступен из главного приложения.
Для размещения приложения ASP.NET Core в качестве приложения, вложенного в другое приложение ASP.NET Core, сделайте следующее:
Добавьте корневой веб-сайт в диспетчере служб IIS с вложенным приложением в папке внутри корневого веб-сайта.
Щелкните правой кнопкой мыши папку вложенного приложения в диспетчере служб IIS и выберите Преобразовать в приложение.
В диалоговом окне Добавление приложения нажмите кнопку Выбрать, чтобы назначить созданный пул приложений вложенному приложению. Нажмите кнопку ОК.
Назначение отдельного пула приложений вложенному приложению является обязательным при использовании модели внутрипроцессного размещения.
Дополнительные сведения о внутрипроцессной модели размещения и настройке модуля ASP.NET Core см. в статье Модуль ASP.NET Core.
Пулы приложений
Модель размещения определяет изоляцию пула приложений:
В диалоговом окне Добавление веб-сайта IIS на каждое приложение по умолчанию задан один пул приложений. Если указано Имя сайта, оно автоматически переносится в текстовое поле Пул приложений. При добавлении веб-сайта создается пул приложений с именем сайта.
Identity пула приложений
Процесс управления IIS создает в системе безопасности Windows безопасный идентификатор с именем пула приложений. С помощью этого идентификатора можно защищать ресурсы, но он не является реальной учетной записью и не отображается в консоли управления пользователями Windows.
Если рабочему процессу IIS требуется предоставить доступ к приложению с повышенными правами, измените список управления доступом (ACL) для каталога, содержащего приложение.
Откройте проводник и перейдите к каталогу.
Щелкните каталог правой кнопкой мыши и выберите пункт Свойства.
На вкладке Безопасность нажмите кнопку Изменить, а затем — кнопку Добавить.
Нажмите кнопку Размещение и выберите систему.
Нажмите кнопку ОК.
Разрешения на чтение и выполнение предоставляются по умолчанию. При необходимости предоставьте дополнительные разрешения.
Кроме того, доступ можно предоставить через командную строку, используя средство ICACLS. В случае с DefaultAppPool выполняется такая команда:
Дополнительные сведения об ICACLS см. здесь.
Поддержка HTTP/2
HTTP/2 поддерживается в ASP.NET Core для следующих сценариев развертывания IIS:
Дополнительные сведения о внутрипроцессной и внепроцессной моделях размещения см. в статье Модуль ASP.NET Core.
Протокол HTTP/2 включен по умолчанию. Если не удается установить подключение HTTP/2, применяется резервный вариант HTTP/1.1. Дополнительные сведения о настройке HTTP/2 для развертываний IIS см. в статье об HTTP/2 в IIS.
Предварительные запросы CORS
Модуль инициализации приложений и время ожидания в режиме простоя
Размещение в IIS с помощью модуля ASP.NET Core версии 2:
Модуль инициализации приложений
Применяется к приложениям, размещенным в процессе и вне процесса.
Функция инициализации приложений в IIS отправляет в приложение HTTP-запрос при запуске или перезапуске пула приложений. Этот запрос инициирует запуск приложения. По умолчанию IIS отправляет запрос к корневому URL-адресу приложения ( / ) для его инициализации (подробные сведения о конфигурации см. в дополнительных ресурсах).
Убедитесь, что включена роль инициализации приложения IIS.
На настольных компьютерах с Windows 7 или более поздней версии при локальном использовании IIS:
В Windows Server 2008 R2 и более поздней версии:
Чтобы включить модуль инициализации приложений для сайта, используйте один из следующих подходов.
При использовании диспетчера IIS:
Время ожидания в режиме простоя
Применяется только к приложениям, размещенным в процессе.
Чтобы предотвратить переход приложения из состояния простоя, задайте для пула приложений время ожидания в режиме простоя с помощью диспетчера IIS:
Чтобы не истекло время ожидания в приложениях, размещенных вне процесса, воспользуйтесь одним из таких методов:
