Встановлення Windows Server 2025 як професіонал: ролі, оновлення та посилення безпеки за 60 хвилин

Було корисно?

Перша година життя Windows Server вирішує, чи стане він спокійним, нудним працівником… чи буде «будинком з привидами» вашого наступного розслідування інциденту.
Більшість «поганих Windows-серверів» не прокляті. Їх просто встановили з типовими налаштуваннями, випадковими ролями та планом «оновлю пізніше».

Це виробнича конфігурація: мінімальна площа атаки, передбачувані оновлення, адекватне сховище та жорстке підкріплення без ламання ваших додатків.
Якщо ви — людина, яку викликають о 2:00 ночі, вам потрібен нудний сервер. Нудний — це добре.

Основні правила для професійної установки за 60 хвилин

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

Правило 1: Визначте, для чого цей сервер потрібен, і для чого він не потрібен

Один сервер — одне завдання — принаймні спочатку. Контролер домену плюс файловий сервер плюс SQL плюс «о, і ще принт-сервер» — це те,
як ви перетворюєте обслуговування на переговори про заручників. Виберіть основне навантаження і будуйте навколо нього.

Правило 2: Ставтеся до значень за замовчуванням як до «тимчасових», а не «гарних»

Значення за замовчуванням оптимізовані, щоб «усім завантажилося», а не «витримало ваше середовище». Ваш рівень безпеки, графік оновлень
та профіль сховища — це ваша відповідальність. Microsoft дає вам стартову лінію, а не фініш.

Правило 3: Якщо ви не можете його перебудувати, ви ним не володієте

Робіть нотатки під час роботи. Краще: автоматизуйте скриптом. Але навіть чіткий чекліст кращий за «я пам’ятаю, що натискав щось». День, коли потрібно швидко відновити,
— це день, коли пам’ять перетворюється на фольклор.

Парафраз ідеї Вернера Фогельса: «Усе ламається; проектуйте так, щоби система могла продовжувати працювати та швидко відновлюватися.»
Такий підхід однаково стосується Windows-серверів і флотів мікросервісів.

Цікаві факти та контекст (що пояснює поточні значення за замовчуванням)

  • Server Core не новинка. Microsoft представив його ще за епохи Windows Server 2008, щоб зменшити площу атаки та кількість патчів; він досі варіант «нудний перемагає».
  • Журналювання NTFS — старе, і це комплімент. NTFS був стандартом з 1990-х; він перевірений у бою, але сучасний Windows також просуває ReFS для певних сценаріїв.
  • SMB-шифрування і підписування стали масовими не випадково. Латеральний рух і крадіжка облікових даних зробили «швидкі та довірливі» файлові шари ризиком.
  • PowerShell став справжнім інтерфейсом адміністратора вже давно. З Windows Server 2012 адміністрація «через GUI» тихо перетворилася на «за спиною PowerShell».
  • Windows Defender більше не іграшка. Вбудований антивірус виріс у серйозну базу безпеки кінцевих точок; ігнорувати його зазвичай гірше, ніж увімкнути.
  • Еволюція Hyper-V змінила розміщення ролей. Після того як віртуалізація стала стандартом, стара модель «один додаток на фізичний сервер» померла — але «одне завдання на VM» залишається розумною практикою.
  • Дизайн Active Directory усе ще визначає порядок налаштувань. Синхронізація часу, DNS та припущення щодо ідентичності роблять ранній порядок конфігурації важливішим на Windows, ніж багато хто очікує.
  • Patch Tuesday — це політика, а не пропозиція. Ритм — інституційний. Якщо ваша стратегія оновлень його не поважає, ви будете дрейфувати, поки під час інциденту не повернетеся назад різко.

План на 60 хвилин (що робити й у якій послідовності)

Сенс не в тому, щоб зробити усе за 60 хвилин. Сенс — зробити незворотні та високоефективні дії спочатку,
а потім залишити систему в безпечному, патчабельному та підтримуваному стані. Це шлях, який збереже майбутнього вас від проблем.

Хвилини 0–10: Інсталяція з розумними виборами дисків та редакції

  • Виберіть правильну редакцію та режим розгортання (Server Core, якщо немає вагомої причини інакше).
  • Підтвердьте UEFI vs BIOS, Secure Boot та TPM, якщо плануєте BitLocker.
  • Розподіліть розділи розумно: ОС відокремлена від даних та логів, де це доцільно.

Хвилини 10–25: Основи ідентичності та доступу

  • Встановіть ім’я хоста, IP-адресацію, DNS та шлюз.
  • Налаштуйте синхронізацію часу та часовий пояс (Kerberos покарає вас пізніше, якщо не зробите цього).
  • Забезпечте віддалене адміністрування (WinRM/PowerShell remoting), потім обмежте RDP.

Хвилини 25–40: Патчі та перезавантаження як у дорослого

  • Застосуйте останні кумулятивні оновлення перед додаванням ролей.
  • Переконайтеся, що джерело оновлень (WSUS, Windows Update for Business або прямий Microsoft Update) відповідає політиці.
  • Перезавантажуйтеся доти, доки не буде «жодних залишкових оновлень». Один перезавантаження — це надія, а не процес.

Хвилини 40–55: Встановлення ролей та функцій (мінімально)

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

Хвилини 55–60: Застосуйте базове посилення та зробіть знімок (або бекап)

  • Увімкніть Defender, посильте брандмауер, відключіть непотрібне.
  • Увімкніть BitLocker, якщо підтримується та передбачено операційно.
  • Створіть контрольну точку/знімок «золотої конфігурації», якщо віртуалізовано, або принаймні резервну копію й експорт конфігурації.

Жарт №1: Якщо ви пропускаєте патчі, бо «він щойно новий», вітаємо — ваш сервер тепер музейний експонат з інтерактивним шкідливим ПЗ.

Вибір під час інсталяції: що важливо (і що ні)

Server Core vs Desktop Experience

Якщо ви будуєте інфраструктурні ролі (AD DS, DNS, DHCP, Hyper-V host, файловий сервер) і не маєте жорсткої залежності від локального GUI,
оберіть Server Core. Менше бінарників означає менше патчів, менше шляхів атаки і менше «таємничого коду», встановленого для підтримки UI-функцій, якими ви не користуєтесь.

Використовуйте Desktop Experience, коли у вас є постачальник, який наполягає на локальних UI-інструментах або старих MMC-надбудовах, що погано працюють віддалено.
Але розглядайте це як витрату: більше патчів, більше сервісів, більше речей для посилення.

UEFI, Secure Boot та TPM: вирішіть наперед

UEFI + Secure Boot + TPM дають історію довіри платформи, яка витримає аудит та розслідування інцидентів. Якщо хочете BitLocker на диску ОС без дивної ручної роботи з ключами, вам потрібен TPM.

Не «плануйте додати TPM пізніше». Рішення щодо апаратного та віртуального TPM впливають на шифрування, процеси відновлення та відповідність.

Макет дисків: розділяйте домени відмов

Том ОС має бути нудним. Тримайте його меншим, легшим для іміджування, бекапу та менш схильним до заповнення логами додатків, які хтось забув обертати.

Прагматичний макет у багатьох організаціях:

  • C: Тільки ОС (плюс мінімальні інструменти).
  • D: Бінарники додатків / служби (за бажанням).
  • E: Дані.
  • F: Логи та тимчасові файли (особливо для IIS, проміжного бекапу, ETL-задань).

Конкретні літери дисків не важливі. Важлива саме роздільність.

Вибір файлової системи: NTFS vs ReFS

NTFS залишається безпечною опцією за замовчуванням для широкої сумісності. ReFS має переваги в цілісності та для деяких великих сценаріїв зберігання, але це
не універсальна заміна для всіх навантажень (декотрі додатки та інструменти бекапу мають власні вимоги).

Якщо ви не знаєте, навіщо вам ReFS, то, ймовірно, він вам не потрібен. Якщо знаєте — у вас вже є план тестування.

Після інсталяції: ідентичність, мережа, час і віддалений доступ

Називайте так, щоб змогли знайти о 3 ранку

Імена хостів мають кодувати середовище та роль так, щоб люди могли швидко їх розпізнати. Тримайте ім’я достатньо коротким для інструментів і сертифікатів.
Уникайте хитрувань. Хитрі імена псуються швидко.

Мережа: статична там, де потрібно; документуйте там, де ні

Контролери домену, DNS-сервери, Hyper-V host, вузли зберігання та будь-що, від чого залежать інші системи, мають статичну адресацію. Сервери додатків
часто можуть бути в DHCP з резервацією, залежно від вашого середовища. У будь-якому разі переконайтеся, що DNS правильний і послідовний.

Синхронізація часу: невидима залежність, що ламає автентифікацію

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

Віддалене адміністрування: WinRM першим, RDP другим

Якщо ви можете керувати сервером через PowerShell Remoting і MMC/RSAT з адмінської робочої станції, вам потрібно значно менше RDP. Тримайте RDP для аварійного доступу,
але зменшуйте експозицію. Не використовуйте RDP як основну панель управління.

Ролі та функції: встановлюйте лише те, що вмієте захищати

Ролі — це не «функції», це контракти

Встановлення ролі означає, що ви погоджуєтеся патчити її, моніторити її та розуміти її режими відмови. Найшвидший спосіб зіпсувати новий сервер — встановити «трохи всього» і вирішувати пізніше.

Звичні шаблони ролей, про які ви не пошкодуєте

  • Domain Controller (AD DS + DNS): тримайте його чистим. Ніяких додаткових додатків. Ніяких файлових шарів. Ніякого SQL.
  • Файловий сервер: ізолюйте від DC, застосовуйте SMB signing/encryption за потреби й плануйте квоти/FSRM заздалегідь.
  • Hyper-V host: ставтеся до хоста як до прошивки. Мінімум ролей, мінімум логінів, передбачуване патчування.
  • IIS: обмежуйте модулі, зменшуйте привілеї пулів додатків і тримайте TLS/шифри відповідно до політики.

Встановлюйте ролі через PowerShell, щоб бути явними

GUI-інсталяції ховають деталі. PowerShell показує, що змінив. Це краще для нотаток у тікетах, огляду змін і майбутніх перебудов.

Оновлення: патчуйте як слід

Виберіть модель оновлень і дотримуйтеся її

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

  • WSUS (централізований контроль і схвалення): корисно, коли потрібне жорстке управління.
  • Windows Update for Business (політично керований хмарний контроль): добре для масштабу та консистентності.
  • Direct Microsoft Update: прийнятно для ізольованих серверів, лабораторій чи невеликих розгортань зі стрункою дисципліною процесів.

Чого не слід робити: змішувати моделі без потреби. Так ви отримаєте «деякі сервери запатчені, деякі — ні, ніхто не знає чому».

Патчити перед ролями (зазвичай)

Щойно встановлений сервер зазвичай відстає по кумулятивних оновленнях. Раннє патчування зменшує шанси на дивні баги під час інсталяції ролей і скорочує вікно вразливості.
Є винятки (деякі ролі все одно вимагають перезавантаження під час інсталяції), але загальне правило діє.

Цикли перезавантаження — частина патчування, а не незручність

Ваша задача — не «встановити оновлення». Ваша задача — «прибути в чистий стан без очікуваних перезавантажень і без невдалих оновлень».
Стан очікування перезавантаження викликає дивні явища: сервіси не завантажуються, драйвери наполовину застосовані, політики не діють.

Посилення безпеки: зменшіть площу ураження без самосаботажу

Принципи бази

  • Найменші права: запускайте сервіси з мінімальними правами. Уникайте LocalSystem, якщо не любите жити на межі.
  • Зменшуйте прослуховуючі сервіси: кожен відкритий порт — це обіцянка, яку треба захищати.
  • Шифруйте там, де це важливо: дані в стані спокою (BitLocker) і дані в русі (TLS, SMB encryption/signing за потреби).
  • Забезпечте повне та передбачуване логування: журнали безпеки, логування PowerShell та пересилання подій, якщо є інфраструктура.

Позиція брандмауера: «забороняємо за замовчуванням» — це стиль життя

Windows Firewall — не опціональний декор. Увімкніть його для всіх профілів. Створіть явні вхідні правила для того, що потрібно. Потім перевірте, що насправді прослуховується.
Якщо ви покладаєтеся на «внутрішню VLAN», ви проектуєте для 2009 року, а не для сьогодення.

Посилення RDP: залиште, але ускладніть його зловживання

Вимагайте Network Level Authentication. Обмежте, хто може входити через RDP. Розгляньте доступ «just-in-time» через інструменти привілейованого доступу, якщо вони є.
Як мінімум — не виставляйте RDP широко і не дозволяйте випадковим адміністративним групам доступ за помилкою.

Налаштування Defender: за замовчуванням достатньо, але налаштований краще

У багатьох середовищах увімкнення реального часу Defender і cloud-delivered захисту — негайне покращення у порівнянні з «нічого» або «простроченим стороннім агентом». Якщо вендор вимагає виключень, домовляйтесь:
вузькі шляхи, вузькі процеси та документуйте причини.

Вимикайте те, чим не користуєтесь

Кожна непотрібна функція додає площу для патчів і сюрпризів. Приклади: SMBv1 (не використовуйте), застарілі протоколи TLS (ні), випадкові веб-компоненти на не-веб-серверах (навіщо?), локальні облікові записи з довготривалими паролями (припиніть це).

Сховище та файлові системи: реалії (частина SRE)

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

Windows охоче дозволяє вам побудувати сервер на тонкопроторонованому сховищі з вимкненим write caching, покласти логи на диск ОС і потім
«таємничо» сповільнитись під навантаженням. ОС не таємнича — вона буквальна.

Визначте, яке у вас сховище

  • Локальні NVMe/SAS SSD: найшвидші, найпростіші. Чудово під Hyper-V host і автономні навантаження.
  • SAN (FC/iSCSI): спільне та кероване, але латентність і налаштування мультипатчингу мають значення.
  • SMB storage / NAS: добре для файлових шарів і деяких сценаріїв Hyper-V, але вимагає уважного налаштування SMB і мережевого дизайну.

Вирівнювання розділів та розмір блоку: так, це ще має значення

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

Плануйте розташування логів та їхнє зростання

«Ми покладемо логи на C: тимчасово» — класична передінцидентна фраза. Помістіть логи туди, де є місце і моніторинг. Якщо додаток заповнить том логів,
він має відмовити так, щоб ви це помітили, а не зіпсувати ОС.

Практичні завдання з командами, виходом та рішеннями (12+)

Це базові перевірки, які я роблю на новому сервері. Кожне завдання містить команду, що означає вихід і яке рішення за нею слід прийняти.
Виконуйте їх у підвищеній сесії PowerShell.

Завдання 1: Підтвердити редакцію ОС та тип інсталяції

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsEditionId,OsHardwareAbstractionLayer"
WindowsProductName                WindowsEditionId OsHardwareAbstractionLayer
-----------------                ----------------- --------------------------
Windows Server 2025 Datacenter    ServerDatacenter 10.0.26100.1

Значення: Підтверджує, що ви не випадково встановили Standard, коли потрібен Datacenter, або Desktop Experience, коли хотіли Core.

Рішення: Якщо редакція/режим інсталяції неправильні — зупиніться і перевстановіть. «Виправити пізніше» зазвичай означає повну перебудову.

Завдання 2: Перевірити стан очікування перезавантаження (тихий винуватець)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"
True

Значення: True вказує, що Windows вважає, що очікується перезавантаження через обслуговування.

Рішення: Перезавантажте та перевірте ще раз перед встановленням ролей або усуненням «випадкових» проблем.

Завдання 3: Підтвердити ім’я хоста та членство в домені

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ComputerSystem | Select-Object Name,Domain,PartOfDomain"
Name     Domain        PartOfDomain
----     ------        ------------
FS01     corp.example  True

Значення: Підтверджує, що ви приєдналися до потрібного домену і не опинилися в WORKGROUP на «продакшен»-сервері.

Рішення: Якщо членство в домені неправильне — виправте це перед встановленням ролей, що залежать від AD (і перед видачею сертифікатів).

Завдання 4: Перевірити налаштування NIC (IP, DNS і чи не підсипає DHCP)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias IPv4Address    IPv4DefaultGateway DnsServer
-------------- -----------    ------------------ ---------
Ethernet0      10.20.5.21     10.20.5.1         {10.20.1.10, 10.20.1.11}

Значення: Підтверджує, що сервер має правильну адресу і вказує DNS на ваші резолвери (не на роутер, не на 8.8.8.8, не на себе, якщо він не є DNS).

Рішення: Якщо DNS неправильний — виправте негайно. Помилки резолюції імен витрачають дні і змушують підозрювати AD без причини.

Завдання 5: Підтвердити синхронізацію часу та зсув

cr0x@server:~$ powershell -NoProfile -Command "w32tm /query /status"
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 2/5/2026 8:41:22 AM
Source: time.corp.example
Poll Interval: 6 (64s)

Значення: Показує джерело часу та чи остання синхронізація була успішною.

Рішення: Якщо джерело — «Local CMOS Clock» на сервері, приєднаному до домену, який не є PDC emulator, виправте NTP. Зсув часу та помилки аутентифікації люблять годинникові дрейфи.

Завдання 6: Підтвердити, що Windows Firewall увімкнено для всіх профілів

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Значення: За замовчуванням ви блокуєте вхідні з’єднання, що змушує створювати явні правила.

Рішення: Якщо будь-який профіль вимкнутий — увімкніть його і створіть необхідні дозволи. Не покладайтеся на міфи про периметр.

Завдання 7: Подивіться, що насправді прослуховується в мережі

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Sort-Object LocalPort | Select-Object -First 10"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      135       968
0.0.0.0      445       4
0.0.0.0      3389      1440
::          445       4
::          3389      1440

Значення: Відкриті порти — реальна площа атаки. Це показує, що у вас експонується.

Рішення: Якщо бачите несподівані прослуховувачі (старі агенти, сервіси вендора, веб-сервери), ідентифікуйте їх і видаліть/відключіть або закривайте брандмауером.

Завдання 8: Зіставте прослуховувані порти з сервісами/процесами

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 1440 | Select-Object Id,ProcessName,Path"
Id   ProcessName Path
--   ----------- ----
1440 TermService C:\Windows\System32\svchost.exe

Значення: Підтверджує, хто володіє портом (тут RDP через Terminal Services).

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

Завдання 9: Перевірити стан Defender та реальний час захисту

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMServiceEnabled,AntispywareEnabled,AntivirusEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled AntivirusEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ------------------ --------------- ------------------------- --------------------
True             True               True            True                      True

Значення: Підтверджує, що Defender не вимкнений випадково або через стару GPO.

Рішення: Якщо він вимкнений — з’ясуйте причину. Якщо потрібен сторонній AV, переконайтеся, що він встановлений і здоровий замість того, щоб залишати прогалину.

Завдання 10: Підтвердити статус оновлень та дати останніх встановлень

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5"
Source Description      HotFixID  InstalledBy          InstalledOn
------ -----------      --------  -----------          -----------
FS01   Update           KB503xxxx NT AUTHORITY\SYSTEM  2/5/2026
FS01   Security Update  KB503yyyy NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB503zzzz NT AUTHORITY\SYSTEM  2/5/2026
FS01   Update           KB502aaaa NT AUTHORITY\SYSTEM  1/14/2026
FS01   Update           KB502bbbb NT AUTHORITY\SYSTEM  1/14/2026

Значення: Швидко видно, чи сервер актуальний або застарів на місяці.

Рішення: Якщо останні патчі старі — виправте pipeline оновлень перед встановленням додаткових ролей. Технічний борг починається миттєво.

Завдання 11: Перевірити, чи увімкнено BitLocker (і чи придатний TPM)

cr0x@server:~$ powershell -NoProfile -Command "Get-BitLockerVolume -MountPoint 'C:' | Select-Object MountPoint,VolumeStatus,ProtectionStatus,EncryptionPercentage"
MountPoint VolumeStatus    ProtectionStatus EncryptionPercentage
---------- ------------    ---------------- --------------------
C:         FullyEncrypted  On               100

Значення: Підтверджує, що шифрування даних у стані спокою активне.

Рішення: Якщо потрібне шифрування, але воно вимкнене — увімкніть і ескроуйте ключі відновлення відповідно до політики. Якщо немає процесу управління ключами — не експериментуйте.

Завдання 12: Перевірити макет дисків і томів (щоб уникнути «C: заповнено» у майбутньому)

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter,FileSystemLabel,FileSystem,SizeRemaining,Size | Sort-Object DriveLetter"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- ---------- ------------- ----
C           OS             NTFS       58.4 GB       120 GB
E           DATA           NTFS       1.6 TB        2.0 TB
F           LOGS           NTFS       350 GB        400 GB

Значення: Показує, де є місце та чи відповідає план томів реальності.

Рішення: Якщо логи і дані на C:, перемістіть їх перед запуском додатків. Переміщення пізніше складніше і ризикованіше.

Завдання 13: Перевірити стан сховища (свого роду SMART через Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName,MediaType,HealthStatus,OperationalStatus,Size"
FriendlyName      MediaType HealthStatus OperationalStatus Size
------------      --------- ------------ ----------------- ----
NVMe Disk 0       SSD       Healthy      OK                1.8 TB
NVMe Disk 1       SSD       Healthy      OK                1.8 TB

Значення: Базовий сигнал: Windows вважає диски здоровими і працездатними.

Рішення: Якщо бачите «Warning» або «Unhealthy» — зупиніться і розслідуйте, перш ніж довіряти цьому хосту з даними.

Завдання 14: Підтвердити встановлені ролі (і виявити випадкові)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsFeature | Where-Object { $_.Installed -eq $true } | Select-Object -First 15"
Display Name                                            Name                       Install State
------------                                            ----                       -------------
File and Storage Services                               FileAndStorage-Services    Installed
File Server                                             FS-FileServer              Installed
Windows Server Backup                                   Windows-Server-Backup      Installed
Windows Defender Features                               Windows-Defender-Features  Installed
Remote Server Administration Tools                      RSAT                       Installed

Значення: Підтверджує, що ви насправді встановили.

Рішення: Якщо бачите ролі, які не потрібні (наприклад, Web-Server на файловому сервері) — видаліть їх. Менше коду — менше проблем.

Завдання 15: Встановити роль явно (приклад: File Server) і перевірити

cr0x@server:~$ powershell -NoProfile -Command "Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools"
Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {File Server}

Значення: Роль успішно встановлена і цього разу не потребує перезавантаження.

Рішення: Якщо Restart NeededYes, перезавантажте зараз — не нагромаджуйте змін поверх стану, що очікує перезавантаження.

Завдання 16: Перевірити основні налаштування SMB (підписування, діалекти)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RequireSecuritySignature,EncryptData"
EnableSMB1Protocol EnableSMB2Protocol RequireSecuritySignature EncryptData
------------------ ------------------ ------------------------ -----------
False              True               True                     False

Значення: SMBv1 вимкнено (добре), SMBv2+ увімкнено, підписування вимагається, шифрування наразі опціональне.

Рішення: Для чутливих шарів або недовірених мереж увімкніть шифрування per-share або глобально. Не вмикайте шифрування масово без вимірювання впливу на CPU.

Жарт №2: Вимкнути брандмауер, бо «він блокує мій додаток» — це як знімати детектор диму, бо він голосно пищить.

Швидкий план діагностики (швидко знайти вузьке місце)

Коли новий сервер відчувається повільним, не здогадуйтеся. Не перевстановлюйте драйвери з нудьги. Зробіть коротке триажне тестування, що скаже, куди пішов час.
Мета — ізолювати CPU, тиск пам’яті, затримки сховища, мережу або ідентичність/DNS.

Перше: чи це сховище, і чи очевидно це?

  • Перевірте чергу диска та латентність: якщо сховище повільне — усе повільне.
  • Перевірте, чи том ОС майже не заповнений: мало місця викликає патологічну поведінку і невдалі оновлення.
  • Перевірте журнали подій: скиди диска, попередження storport, проблеми NTFS.
cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:02:11 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.007
2/5/2026 9:02:13 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.005
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.009
2/5/2026 9:02:15 AM       \\FS01\physicaldisk(_total)\avg. disk sec/read : 0.004
                          \\FS01\physicaldisk(_total)\avg. disk sec/write: 0.008

Значення: Латентності в одиницях мілісекунд зазвичай прийнятні для багатьох навантажень. Десятки/сотні мс — це проблема.

Рішення: Якщо латентність висока, перестаньте звинувачувати «Windows» і почніть перевіряти бекенд сховища, політику write cache, SAN multipath і «шумних сусідів».

Друге: тиск CPU і пам’яті (спочатку прості перевірки)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes' -SampleInterval 2 -MaxSamples 3"
Timestamp                 CounterSamples
---------                 --------------
2/5/2026 9:03:01 AM       \\FS01\processor(_total)\% processor time : 12.4
                          \\FS01\memory\available mbytes : 18234
2/5/2026 9:03:03 AM       \\FS01\processor(_total)\% processor time : 10.1
                          \\FS01\memory\available mbytes : 18190
2/5/2026 9:03:05 AM       \\FS01\processor(_total)\% processor time : 11.7
                          \\FS01\memory\available mbytes : 18210

Значення: CPU не завантажений, пам’ять не виснажена.

Рішення: Якщо CPU високий — ідентифікуйте топ-процеси і перевірте сканування AV, інтенсивне логування або неправильне індексування. Якщо пам’ять низька — перевірте поведінку підкачки та розмір додатків.

Третє: DNS та ідентичність (бо все від цього залежить)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName corp.example -Type SOA"
Name         Type TTL  Section    NameHost
----         ---- ---  -------    --------
corp.example SOA  3600 Answer     dns01.corp.example

Значення: Резолюція DNS працює і повертає авторитетну інформацію.

Рішення: Якщо DNS повільний або невірний — виправте DNS перед діагностикою таймаутів додатків. Додатки не вміють коректно обробляти поганий DNS; вони просто креативно страждають.

Четверте: основи мережі (не бенчмаркуйте на оптимізмах)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName dns01.corp.example -Port 53"
ComputerName           : dns01.corp.example
RemoteAddress          : 10.20.1.10
RemotePort             : 53
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.5.21
TcpTestSucceeded       : True

Значення: Базова доступність до залежності працює на очікуваному порту.

Рішення: Якщо це не проходить — у вас проблеми з маршрутом/брандмауером/VLAN. Припиніть чіпати збірку сервера і йдіть говорити з мережею.

Типові помилки: симптом → корінь → виправлення

1) «Інсталяція ролі пройшла, але сервіси не працюють або поводяться дивно»

Симптоми: сервіси не запускаються; функції працюють частково; Event Viewer показує помилки обслуговування/CSI; перезавантаження інколи «вирішують» проблему.

Корінь: стан очікування перезавантаження через оновлення або інсталяцію функцій.

Виправлення: Перезавантажуйте доти, доки стан очікування не зникне; підтвердіть це перевіркою реєстру. Потім повторіть інсталяцію/відновлення ролі.

2) «Приєднання до домену працює, але автентифікація нестабільна»

Симптоми: помилки Kerberos, GPO не застосовується, періодичні відмови у доступі.

Корінь: зсув часу або неправильна ієрархія NTP.

Виправлення: Перевірте w32tm /query /status; виправте джерело часу; підтвердьте часовий пояс; пересинхронізуйте і перевірте.

3) «Файлові шари повільні, особливо в години піку»

Симптоми: операції копіювання зупиняються; Провідник зависає; CPU сервера виглядає нормальним.

Корінь: пікові затримки сховища (конгестія SAN, thin provisioning, політика write cache, фонова знімка).

Виправлення: Виміряйте лічильники латентності диска; перевірте продуктивність бекенду; відділіть логи/тимчасові; розгляньте QoS або виділені томи.

4) «RDP відкритий і з’являються спроби підбору паролів»

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

Корінь: RDP дозволено широко; правила брандмауера надто відкриті; слабкий контроль доступу.

Виправлення: Обмежте вхідний RDP до підмереж адміністраторів/VPN; вимагайте NLA; обмежте дозволені групи; розгляньте відключення RDP на публічному профілі взагалі.

5) «Windows Update продовжує падати з загадковими помилками»

Симптоми: оновлення завантажуються, але не встановлюються; повторні збої; помилки стеку обслуговування.

Корінь: мало місця на C:, зламана конфігурація джерела оновлень або застарілі компоненти обслуговування.

Виправлення: Звільніть місце; підтвердіть політику джерела оновлень; перезавантажте; потім повторіть. Якщо проблема стійка — розгляньте ремонтну інсталяцію або перебудову залежно від відтворюваності вашої збірки.

6) «Після посилення безпеки додаток ламається в продакшені»

Симптоми: додаток не може прив’язатися до порту, не може писати логи, не може автентифікуватися до віддалених сервісів.

Корінь: зміни посилення застосовані без моделі винятків для додатків (права сервісних облікових записів, ACL для папок, правила брандмауера).

Виправлення: Відкочуйтеся з цілеспрямованими винятками: вузькі правила брандмауера, мінімальні ACL, документовані дозволи сервісних облікових записів. Уникайте глобальних відключень.

Три корпоративні міні-історії (як це провалюється в реальному житті)

Міні-історія 1: Інцидент через хибне припущення

Команда підняла нову VM Windows Server для бізнес-додатку. Інженер припустив, що «DHCP підходить; IP лишатиметься тим самим», бо VM знаходилась у стабільному кластері.
Ніхто не створив резервацію. Ніхто не задокументував адресу. Все пройшло тестування, бо IP не змінювався тижнями.

Потім планове обслуговування гіпервізора перемістило VM у сегмент із іншим DHCP-диапазоном. Сервер перезавантажився, запросив адресу і отримав новий IP. DNS scavenging зрештою видалив старий запис і замінив його.
Додаток не використовував DNS — він був жорстко прописаний на стару IP в трьох місцях, включно з конектором вендора, якого ніхто не знав.

Режим відмови був кінематографічним: користувачі бачили періодичні помилки, бо половина клієнтів кешувала стару IP, а половина — нову.
Автентифікація була нормальна. CPU і RAM — нормальні. Моніторинг — теж, бо він дивився на стару адресу.

Виправлення було нудним: статичний IP (або резервація), правильний DNS і правило, що залежності мають адресуватись за DNS-именем, а не IP, якщо нема задокументованої причини.
Головний урок: «Працювало в тесті» — не доказ коректності. Це доказ того, що час ще не покарав вас.

Міні-історія 2: Оптимізація, що повернулась бумерангом

Інша організація працювала з зайнятим файловим сервером на спільному сховищі. Хтось вирішив, що включення SMB-шифрування «покращить безпеку», і увімкнув його глобально.
Зміна пройшла поверхневі тести: кілька копій файлів пройшли, тривог не було. Інженер записав зміну і пішов додому задоволений.

Через два дні під час години пік продуктивність погіршилася. Не катастрофа — але настільки, щоб викликати черги, довші входи до системи і гнівні тікети, що важко корелювалися.
CPU на файловому сервері піднявся. Пропускна здатність мережі трохи впала. Латентність сховища зросла, бо клієнти повторно надсилали операції під час конгестії.
Всі звинувачували SAN, бо SAN — це найпопулярний винуватець.

Розслідування показало реальну причину: наклад шифрування на старіших клієнтах і підмножині високопродуктивних робочих потоків. Сервер мав достатньо CPU, але патерн зашифрованих сесій підвищив вартість на підключення.
Зміна також взаємодіяла з антивірусом при відкритті файлів, множачи накладні витрати так, як бенчмарки не показували.

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Компанія стандартизувала строгий серверний чекліст: запатчити до актуального, перевірити стан очікування перезавантаження, застосувати базові правила брандмауера, експортувати конфігурацію ролей і зробити чистий знімок.
Це не було драйвово, тож ніхто про це не хвалився. Вони просто робили це щоразу.

Через місяці новий кумулятивний апдейт спричинив дивний boot-loop на підмножині VM через взаємодію з певною конфігурацією віртуального контролера сховища.
Симптом виглядав як «Windows зламався». Спроби відновлення були хаотичними у командах, що не мали відомого доброго стану або послідовної збірки.

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

Тимчасове рішення було простим: відкоригувати налаштування віртуального контролера, застосувати оновлення знову і підтвердити стабільність.
Чекліст не запобіг багу. Він не дозволив перетворити відмову на багатоденну археологію.

Контрольні списки / покроковий план

Чекліст перед інсталяцією (5 хвилин, заощаджує години)

  • Підтвердьте роль сервера: DC, файловий сервер, Hyper-V host, IIS, сервер додатків тощо.
  • Визначте режим інсталяції: Server Core, якщо не потрібен локальний GUI.
  • Визначте план дисків: ОС vs дані vs логи; розмір з урахуванням росту.
  • Визначте джерело оновлень: WSUS vs WUfB vs прямий Microsoft Update.
  • Визначте базову політику безпеки: позиція брандмауера, політика RDP, політика Defender, вимога BitLocker.
  • Підтвердьте процедури аварійного доступу (локальний адміністратор, аварійна консоль).

Чекліст інсталяції (15 хвилин)

  • Встановіть потрібну редакцію Windows Server 2025.
  • Використовуйте UEFI + Secure Boot, якщо підтримується.
  • Розбивайте томи згідно плану; чітко маркуйте томи (OS, DATA, LOGS).
  • Встановіть сильний локальний пароль адміністратора і збережіть його у сховищі секретів згідно політики.

Чекліст першого завантаження (20 хвилин)

  • Встановіть ім’я хоста і перезавантажте (зробіть зараз, щоб потім не здивуватись).
  • Налаштуйте NIC: статичний IP для інфраструктурних залежностей; правильні DNS-сервера.
  • Встановіть часовий пояс і перевірте джерело NTP/часу.
  • Увімкніть WinRM/PowerShell remoting як основний спосіб адміністрування (якщо політика дозволяє).
  • Увімкніть брандмауер для всіх профілів; створіть явні правила для мереж управління.

Чекліст патчування (10–20 хвилин, залежить від пропускної здатності)

  • Встановіть останні оновлення.
  • Перезавантажте.
  • Перевірте наявність додаткових оновлень.
  • Повторюйте, доки немає очікуваних оновлень і стану перезавантаження.

Чекліст ролей та посилення (10–20 хвилин)

  • Встановлюйте лише потрібні ролі через PowerShell.
  • Переконайтеся, що прослуховувані порти та правила брандмауера відповідають намірам.
  • Підтвердіть стан Defender; реалізуйте необхідні винятки вузько.
  • Увімкніть BitLocker, якщо потрібно і є процес ескроу ключів/відновлення.
  • Експортуйте «квитанцію» конфігурації (ролі, мережеві налаштування) у запис змін.
  • Зробіть знімок/контрольну точку або базовий бекап.

Поширені питання

1) Чи слід використовувати Server Core для Windows Server 2025?

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

2) Коли встановлювати ролі: до чи після патчування?

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

3) Чи достатньо Windows Defender на серверах?

У багатьох середовищах Defender — надійна база, особливо в порівнянні з «нічого» або погано підтримуваним стороннім агентом.
Якщо політика вимагає іншого рішення — гаразд; просто переконайтеся, що у вас реально працює захист і телеметрія, а не галочка в списку.

4) Чи слід увімкнути BitLocker на серверах?

Якщо є вимоги відповідності, чутливі дані або ризик витоку дисків (хмара, колокація, «ноутбуки як сервери» — таке буває), то так.
Але робіть це з процесом ескроу ключів і відновлення. Шифрування без можливості відновлення — не безпека, а самонавантажене знищення даних.

5) Чи потрібно тримати брандмауер увімкненим всередині дата-центру?

Так. Внутрішні мережі не є автоматично довіреними, а латеральний рух — стандартна техніка атак.
Тримайте брандмауер увімкненим, блокуйте вхідні за замовчуванням і явним чином дозволяйте порти для управління та додатків.

6) Як обрати між NTFS і ReFS?

Якщо потрібна максимальна сумісність і немає спеціальної причини, обирайте NTFS.
Розглядайте ReFS, коли маєте валідований кейс і план тестування, що включає бекапи, відновлення та сумісність додатків.

7) Який найшвидший спосіб зрозуміти, чи «повільність» — це сховище?

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

8) Чи варто дозволяти RDP взагалі?

Дозволяйте його як контрольований аварійний шлях, а не як щоденний інструмент адміністрування.
Обмежуйте доступ до адмін-мереж, вимагайте NLA і обмежуйте, хто може входити. Віддавайте перевагу PowerShell remoting для рутини.

9) Як уникнути «сніжинок» серверів?

Використовуйте PowerShell для інсталяції ролей і конфігурації, тримайте збірковий чекліст і зберігайте експорти конфігурацій у записах змін.
Якщо сервер неможливо перебудувати за задокументованими кроками — він сніжинка, не зважаючи на впевненість інсталятора.

10) Який мінімум перевірок після першої години?

Підтвердіть: немає очікуваних перезавантажень, оновлення актуальні, брандмауер увімкнений, Defender здоровий, правильний DNS/час, лише очікувані прослуховувані порти,
томи мають простір, логи не на C:. Це рівень «безпечно продовжувати».

Наступні кроки (тримайтеся нудно)

Після першої години ваша робота переходить від «збірки» до «експлуатації». Зробіть наступне:

  • Встановіть пороги моніторингу для дискового простору, латентності диска, CPU, пам’яті та невдалих оновлень. Якщо ви не вимірюєте — дізнаєтесь про проблеми через тікети.
  • Централізуйте журнали, якщо середовище підтримує (пересилання подій/SIEM). Локальні журнали хороші до моменту, коли сервер впаде.
  • Документуйте контракт ролі: які порти відкриті, які сервісні облікові записи є, які бекапи запускаються і яка процедура відновлення.
  • Протестуйте відновлення. Бекапи без відновлення — просто дорогі відчуття.
  • Заплануйте вікна патчування і доведіть, що можете перезавантажувати без драм. Страх перед перезавантаженням робить сервери непатчабельними.

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

← Попередня
DNS: ваш домен працює… поки раптом ні — пояснення пастки делегування
Наступна →
Створення завантажувального USB за допомогою PowerShell (без GUI)

Залишити коментар