Встановлення IIS на Windows Server

Internet Information Services — штатний вебсервер Windows Server для розміщення статичних сайтів, застосунків ASP.NET, внутрішніх порталів, API та вебінтерфейсів корпоративних систем. IIS інтегрується з Windows, підтримує централізоване керування, TLS, журнали запитів, автентифікацію та ізоляцію застосунків через Application Pool.

Нижче розглянемо встановлення IIS на Windows Server 2022 або Windows Server 2025, вибір компонентів, створення окремого сайту, налаштування прав, HTTPS і базову діагностику. Інструкція підходить як для сервера з графічним інтерфейсом, так і для Server Core, де всі операції виконуються через PowerShell.

Перед початком варто визначити призначення вузла. Для одного статичного сайту достатньо мінімального набору компонентів. Застосунок ASP.NET Framework потребуватиме модулів ASP.NET 4.x та ISAPI, а віддалене адміністрування — Management Service. Не слід встановлювати всі доступні служби без потреби: кожен додатковий компонент збільшує поверхню атаки та ускладнює супровід. Якщо сервер є частиною ширшого робочого контуру, регулярне обслуговування серверів допомагає контролювати оновлення, резервні копії та доступність вебслужб.

Підготовка Windows Server до встановлення IIS

Увійдіть під обліковим записом із локальними адміністративними правами та перевірте версію операційної системи:

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

Встановіть актуальні оновлення Windows і перезавантажте сервер, якщо цього потребує система. Стан очікуваного перезавантаження важливий: інсталяція ролі може завершитися успішно, але частина компонентів працюватиме некоректно до рестарту.

Перевірте мережеві параметри:

Get-NetIPConfiguration
Resolve-DnsName localhost
Test-NetConnection localhost -Port 80

До встановлення IIS остання команда зазвичай показує, що TCP-порт 80 недоступний. Якщо порт уже прослуховується, з’ясуйте, який процес його використовує:

Get-NetTCPConnection -LocalPort 80 -State Listen -ErrorAction SilentlyContinue |
    Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id <PID>

Замість `<PID>` підставте ідентифікатор із першої команди. IIS не зможе запустити HTTP-прив’язку, якщо порт зайнятий іншим вебсервером або локальним агентом.

Для публічного вузла заздалегідь підготуйте DNS-ім’я. Запис типу A або CNAME має вказувати на адресу сервера чи балансувальника. Не використовуйте IP-адресу як постійний спосіб доступу до HTTPS-сайту: сертифікат зазвичай випускається на доменне ім’я.

Також визначте каталог для вебфайлів. Розміщувати власний проєкт безпосередньо в `C:\inetpub\wwwroot` необов’язково. Практичніше створити окрему структуру, наприклад `C:\Sites\Portal`, і надати доступ лише потрібному Application Pool.

Встановлення ролі Web Server (IIS)

На сервері з Desktop Experience відкрийте **Server Manager**, виберіть **Manage → Add Roles and Features**, а потім виконайте такі кроки:

1. Виберіть тип інсталяції **Role-based or feature-based installation**. 2. Вкажіть потрібний сервер у пулі. 3. Позначте роль **Web Server (IIS)**. 4. Погодьтеся на додавання **IIS Management Console**. 5. На сторінці Role Services залиште тільки необхідні служби. 6. Підтвердьте інсталяцію та дочекайтеся її завершення.

Для базового статичного сайту потрібні Common HTTP Features, Static Content, Default Document, HTTP Errors, HTTP Logging, Request Filtering та IIS Management Console. Компонент Directory Browsing краще не активувати, якщо відвідувачам не потрібно бачити список файлів у каталозі.

Швидше та відтворюваніше встановити IIS через PowerShell:

Install-WindowsFeature Web-Server -IncludeManagementTools

Перевірте результат:

Get-WindowsFeature Web-Server, Web-Mgmt-Console |
    Select-Object Name, InstallState

Для статичного сайту з журналюванням, стисненням і моніторингом запитів можна явно встановити набір компонентів:

Install-WindowsFeature `
    Web-Server, `
    Web-Common-Http, `
    Web-Default-Doc, `
    Web-Static-Content, `
    Web-Http-Errors, `
    Web-Http-Logging, `
    Web-Request-Monitor, `
    Web-Filtering, `
    Web-Stat-Compression, `
    Web-Mgmt-Console

Якщо планується застосунок на ASP.NET Framework 4.x, додайте відповідні модулі:

Install-WindowsFeature `
    Web-Net-Ext45, `
    Web-Asp-Net45, `
    Web-ISAPI-Ext, `
    Web-ISAPI-Filter

Не плутайте ASP.NET Framework з сучасним ASP.NET Core. Для ASP.NET Core після IIS окремо встановлюється актуальний .NET Hosting Bundle, який додає ASP.NET Core Module. Версія Hosting Bundle має відповідати підтримуваній версії .NET, на якій зібрано застосунок.

Переглянути всі доступні компоненти IIS можна так:

Get-WindowsFeature Web-* | Format-Table DisplayName, Name, InstallState

Після інсталяції перевірте служби Windows Process Activation Service і World Wide Web Publishing Service:

Get-Service WAS, W3SVC

Обидві служби мають бути в стані `Running`. За потреби запустіть їх і встановіть автоматичний тип запуску:

Set-Service WAS -StartupType Automatic
Set-Service W3SVC -StartupType Automatic
Start-Service WAS
Start-Service W3SVC

Створення сайту та окремого Application Pool

Одразу після встановлення IIS створює `Default Web Site`, який слухає порт 80 і використовує каталог `C:\inetpub\wwwroot`. Для тесту відкрийте в браузері `http://localhost` або виконайте:

Invoke-WebRequest http://localhost -UseBasicParsing |
    Select-Object StatusCode, StatusDescription

Очікуваний код — `200`. Це підтверджує, що служба запущена та HTTP-прив’язка працює локально.

Для реального проєкту створіть окремий каталог, сайт і Application Pool. Відкрийте PowerShell від імені адміністратора:

Import-Module WebAdministration

New-Item -Path C:\Sites\Portal -ItemType Directory -Force
Set-Content -Path C:\Sites\Portal\index.html -Value @'
<!doctype html>
<html lang="uk">
<head><meta charset="utf-8"><title>Portal</title></head>
<body><h1>IIS працює</h1></body>
</html>
'@

New-WebAppPool -Name PortalPool
Set-ItemProperty IIS:\AppPools\PortalPool -Name managedRuntimeVersion -Value ""
Set-ItemProperty IIS:\AppPools\PortalPool -Name processModel.identityType -Value ApplicationPoolIdentity

Порожнє значення `managedRuntimeVersion` означає режим **No Managed Code**. Він підходить для статичного сайту, reverse proxy та ASP.NET Core, оскільки сучасний .NET виконується не всередині класичного CLR Application Pool. Для старого застосунку ASP.NET Framework може знадобитися `v4.0`.

Надайте ідентичності пулу право читання каталогу:

icacls C:\Sites\Portal /grant "IIS AppPool\PortalPool:(OI)(CI)RX" /T

Не видавайте вебпроцесу `Full Control` на весь диск або каталог застосунку. Якщо програмі потрібен запис, створіть окремий підкаталог, наприклад `C:\Sites\Portal\App_Data`, і надайте право `Modify` лише на нього.

Зупиніть стандартний сайт, щоб звільнити порт 80, і створіть власний:

Stop-Website -Name "Default Web Site"

New-Website `
    -Name "Portal" `
    -PhysicalPath "C:\Sites\Portal" `
    -ApplicationPool "PortalPool" `
    -Port 80 `
    -HostHeader "portal.example.local"

Додайте тестовий запис до локального файла hosts на комп’ютері адміністратора або створіть DNS-запис. Після цього перевірте сайт із сервера, передавши потрібний заголовок Host:

Invoke-WebRequest `
    -Uri http://127.0.0.1 `
    -Headers @{ Host = "portal.example.local" } `
    -UseBasicParsing |
    Select-Object StatusCode

Якщо на одному сервері розміщено кілька сайтів, кожен із них може використовувати той самий порт 80, але повинен мати унікальний Host Header. Для ізоляції застосунків створюйте окремий Application Pool для кожного проєкту. Такий підхід не дозволить аварії одного робочого процесу автоматично зупинити інші сайти. Для комплексного супроводу подібних вузлів корисне окреме адміністрування Windows і Linux, що охоплює права доступу, служби, патчі та контроль ресурсів.

Налаштування HTTPS, firewall і журналів

Для тестового середовища можна створити самопідписаний сертифікат. Браузери не довірятимуть йому без додавання власного кореня довіри, тому для відкритого сайту використовуйте сертифікат від довіреного центру сертифікації.

$cert = New-SelfSignedCertificate `
    -DnsName "portal.example.local" `
    -CertStoreLocation "Cert:\LocalMachine\My" `
    -NotAfter (Get-Date).AddYears(1)

New-WebBinding `
    -Name "Portal" `
    -Protocol https `
    -Port 443 `
    -HostHeader "portal.example.local" `
    -SslFlags 1

Get-Item "Cert:\LocalMachine\My\$($cert.Thumbprint)" |
    New-Item "IIS:\SslBindings\0.0.0.0!443!portal.example.local" -Force

Параметр `SslFlags 1` активує SNI, завдяки чому кілька HTTPS-сайтів можуть використовувати одну IP-адресу та порт 443. Старі клієнти без підтримки SNI потребують окремої IP-адреси.

Якщо правила Windows Defender Firewall не створилися автоматично або використовуються нестандартні політики, відкрийте лише потрібні порти:

New-NetFirewallRule `
    -DisplayName "IIS HTTP 80" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 80 `
    -Action Allow

New-NetFirewallRule `
    -DisplayName "IIS HTTPS 443" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 443 `
    -Action Allow

У сегментованій мережі додайте `-RemoteAddress` із дозволеними підмережами замість відкриття доступу для всіх джерел. Не забудьте перевірити зовнішній firewall, NAT або правила хмарної мережі: локальне правило Windows не відкриває порт на маршрутизаторі чи балансувальнику.

Переконайтеся, що порти прослуховуються:

Get-NetTCPConnection -State Listen |
    Where-Object LocalPort -in 80,443 |
    Select-Object LocalAddress, LocalPort, OwningProcess

Стандартні журнали IIS зберігаються в `C:\inetpub\logs\LogFiles`. Ідентифікатор каталогу на кшталт `W3SVC2` відповідає ID сайту. Дізнатися його можна командою:

Get-Website | Select-Object Name, Id, State, PhysicalPath

Перегляд останніх записів журналу:

Get-Content C:\inetpub\logs\LogFiles\W3SVC2\u_ex*.log -Tail 30

Для діагностики також перевіряйте **Event Viewer → Windows Logs → Application** і журнали IIS у **Applications and Services Logs**. Налаштуйте ротацію та централізований збір логів, щоб системний диск не заповнився. Якщо IIS встановлюється на контролері домену, краще переглянути окрему інструкцію про встановлення Active Directory на Windows Server 2022: за можливості вебсервер і контролер домену слід розміщувати на різних вузлах.

Типові помилки під час встановлення IIS

**Сторінка не відкривається з іншого комп’ютера.** Спочатку перевірте локальний запит через `Invoke-WebRequest`. Якщо він успішний, перевіряйте Windows Defender Firewall, мережеві ACL, маршрутизацію, NAT і DNS. Команда `Test-NetConnection server-name -Port 443` із клієнтського вузла допоможе відокремити мережеву проблему від помилки застосунку.

**Помилка 403.14 Forbidden.** IIS не знайшов документ за замовчуванням, а перегляд каталогу вимкнений. Додайте `index.html` або інший стартовий файл до списку Default Document. Увімкнення Directory Browsing лише приховає причину та може відкрити структуру файлів відвідувачам.

**Помилка 401 Unauthorized.** Перевірте активні методи автентифікації. Для відкритого статичного сайту зазвичай потрібна Anonymous Authentication. Для внутрішнього порталу може використовуватися Windows Authentication, але її треба встановити як окремий компонент і правильно налаштувати доступ користувачів.

**Помилка 500.19.** Найчастіше IIS не може прочитати `web.config`, конфігурація містить невідомий модуль або секцію заблоковано на рівні сервера. Перегляньте код помилки в детальному повідомленні та Event Viewer. Не замінюйте `web.config` навмання — спочатку визначте відсутній компонент.

**Помилка 503 Service Unavailable.** Перевірте стан Application Pool:

Get-WebAppPoolState -Name PortalPool
Start-WebAppPool -Name PortalPool

Якщо пул одразу зупиняється, перегляньте системний журнал. Поширені причини — неправильний обліковий запис процесу, прострочений пароль користувача служби, помилки завантаження модуля або часті аварійні завершення процесу.

**Помилка 404 для файлу, який існує.** Перевірте фізичний шлях сайту, права читання, Request Filtering і MIME Types. IIS може блокувати невідоме розширення навіть за наявності файла в каталозі.

**HTTPS відкриває неправильний сайт або сертифікат.** Перевірте Host Name, SNI та прив’язки:

Get-WebBinding | Select-Object protocol, bindingInformation, sslFlags
netsh http show sslcert

Однакові комбінації IP, порту й Host Header створюють конфлікти. Після заміни сертифіката переконайтеся, що HTTPS-прив’язка використовує новий thumbprint.

**Сайт працює локально, але DNS-ім’я веде на інший вузол.** Перевірте результат `Resolve-DnsName`, кеш DNS на клієнті та фактичну адресу балансувальника. Файл hosts придатний для короткого тесту, але не замінює нормальний DNS-запис.

Висновок

Для базового встановлення IIS достатньо додати роль Web Server, Management Console та мінімальні HTTP-компоненти. Надійна конфігурація на цьому не закінчується: кожен сайт повинен мати окремий каталог і Application Pool, обмежені NTFS-права, унікальні прив’язки, коректний TLS-сертифікат і контрольований доступ через firewall.

Після запуску перевірте сайт локально та з клієнтського вузла, перегляньте HTTP-коди, журнали IIS і події Windows. Зафіксуйте встановлені компоненти PowerShell-сценарієм, налаштуйте резервне копіювання конфігурації та стежте за терміном дії сертифіката. Такий підхід робить розгортання відтворюваним і значно спрощує пошук несправностей під час подальшої експлуатації Windows Server.