Windows Server 2022: чеклист чистої інсталяції — чесне налаштування, що запобігає проблемам

Принципи: ставтеся до чистої інсталяції як до продукційної інфраструктури

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

Принцип 1: Зробіть кожну залежність явною

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

Принцип 2: Оптимізуйте наприкінці

Тюнінг продуктивності без базових даних — це лише забобон з додатковими кроками. Спочатку отримайте стабільну збірку: правильні драйвери, передбачуване розміщення сховища, чисті журнали подій і перевірене ПЗМ (firmware). Потім вимірюйте. Потім налаштовуйте.

Принцип 3: Якщо не можна діагностувати за 10 хвилин, ви побудували неправильно

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

Цитата, яку варто тримати в кишені: «Надія — не стратегія.» — генерал Гордон Р. Салліван. В операціях надія — це те, що ви робите, коли пропустили чеклист.

Цікаві факти та історичний контекст (чому Windows такий, яким є)

• Журнали NTFS із журналюванням походять ще з ери Windows NT; це причина, чому Windows часто краще переживає втрату живлення порівняно зі старішими ФС, але журналювання — не те ж саме, що консистентність застосунків.
• Windows Server Core існує тому, що компоненти GUI додають поверхню для патчів і частіші перезавантаження. Core став серйозно використовуватися, коли адміністратори зрозуміли, що «менше встановленого» часто означає «менше ломкається».
• Чутливість Active Directory до часу — це спадщина, яка не зникає: Kerberos-квитки мають обмежений термін, тому недбале синхронізування часу стає «таємничими збоями автентифікації».
• Репутація SMB значно покращилася між версіями; SMB 3.x приніс шифрування й кращу продуктивність порівняно зі старим стереотипом «файловий шарінг = повільно».
• Брандмауер Windows раніше вважали клієнтським подразником. Тепер це перший контрольний шар у жорсткій базовій конфігурації серверів, і він добре інтегрується з політиками в масштабі.
• ReFS був спроектований для сценаріїв цілісності даних і великих томів, але його матриця підтримки (функції, завантаження, комбінації з дедупом) завжди була більше «політика підприємства», ніж «все дозволено».
• Журнали подій з часом стали структуруванішими, але розміри за замовчуванням все ще відображають оптимістичний світ, де аварії короткі, а аудитори поблажливі.
• UEFI та GPT — це не просто мода. Вони зменшують ймовірність, що ви отримаєте дивні обмеження завантаження і крихку розмітку розділів, успадковану з епохи BIOS/MBR.

Рішення до встановлення, які не виправити пізніше

Виберіть правильне видання і режим інсталяції

Використовуйте Server Core, якщо лише немає жорсткої вимоги для GUI-компонентів (деякі агенти постачальників, застарілі MMC-процеси або специфічні ролі). Core зменшує кількість патчів і поверхню атаки. Якщо ваша організація не готова — добре, встановіть Desktop Experience, але розглядайте це як тимчасовий технічний борг.

Рішення: приєднуватися до домену зараз чи пізніше

Приєднання пізніше іноді безпечніше, коли ви ще будуєте сховище/мережу і не хочете, щоб ГП боролися з вашими налаштуваннями. Але приєднання раніше може накласти базові політики безпеки і дати централізоване управління. Обидва варіанти допустимі — просто не «випадково» приєднуйтеся й не дивуйтеся, чому локальні налаштування постійно повертаються.

План сховища: диск ОС проти диску даних і що ви оптимізуєте

Розділяйте ОС і дані. Завжди. Тримайте том ОС нудним: передбачуваний розмір, багато вільного місця для оновлень і дампів, без даних застосунків. Помістіть дані на виділені томи з мітками, що правдиво описують призначення (не «New Volume»). Якщо використовуєте Storage Spaces — вирішуйте про дзеркало чи паритет на основі профілю вводу/виводу і очікувань відновлення, а не відчуттів.

Мережевий план: IP, DNS і правила маршрутизації

Запишіть передбачуваний IP, шлюз, DNS-сервери і чи має ця машина реєструватися в DNS. Вирішіть, чи використовуєте об’єднання NIC (teaming) і в якому режимі. Визначте, чи виконуєте VLAN-тегування в гіпервізорі чи в ОС. Сервер з двома «допоміжними» шлюзами за замовчуванням — це кар’єра з усунення несправностей у коробці.

Стратегія патчів: WSUS, Windows Update for Business чи вручну

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

Жарт #1: Ім’я сервера за замовчуванням — це як залишити багаж в аеропорту з написом «bag». Він поїде, тільки не туди, куди ви хотіли.

Чеклисти / покроковий план (з нуля до готовності)

Фаза 0: Перевірка прошивки і платформи

• Оновіть BIOS/UEFI, прошивку контролера сховища, прошивку NIC і iDRAC/iLO чи еквівалент перед встановленням ОС, коли це практично.
• Увімкніть завантаження через UEFI і підтвердіть план розмітки GPT.
• Підтвердіть налаштування віртуалізації, якщо потрібно (VT-x/AMD-V, SR-IOV за потреби).

Фаза 1: Інсталяція та негайні дії після інсталяції

• Встановіть Windows Server 2022 (Core, якщо можливо), виберіть правильне видання, задайте надійний локальний пароль адміністратора.
• Встановіть ім’я хоста, IP, DNS і стратегію синхронізації часу.
• Установіть драйвери постачальника навмисно (NIC/сховище), а не «те, що знайшов Windows».
• Запустіть Windows Update і перезавантажуйте доти, поки система не буде чистою.

Фаза 2: Базова конфігурація

• Налаштуйте базову політику брандмауера Windows; дозволяйте лише те, що потрібно.
• Задайте політику аварійних дампів і розмір сторінки, щоб ви могли розібратися з BSOD пізніше.
• Змініть розміри журналів подій і політику збереження.
• Увімкніть віддалене керування правильно (WinRM, PowerShell Remoting) з аудитовуваним обсягом доступу.

Фаза 3: Сховище та шлях даних

• Ініціалізуйте й відформатуйте диски даних з мітками, виберіть розмір одиниці розміщення відповідно до навантаження.
• Налаштуйте Storage Spaces/RAID з документованою стійкістю до відмов; протестуйте відмову, якщо можете (витягніть диск у лабораторії).
• Підтвердіть політику кеша запису і захист від втрати живлення (BBU/flash-backed cache).

Фаза 4: Докази резервного копіювання і відновлення

• Встановіть агент резервного копіювання, визначте завдання і підтвердіть application-aware резервні копії, якщо потрібно.
• Протестуйте відновлення принаймні одного файлу і одного шляху відновлення стану системи/застосунку.
• Документуйте очікування RPO/RTO простою мовою.

Фаза 5: Моніторинг і операційні гачки

• Встановіть агент(и) моніторингу, підтвердіть покриття метрик/оповіщень (CPU, пам’ять, затримка диска, помилки NIC, стан сервісів).
• Підтвердіть пересилання журналів подій або інґест у SIEM.
• Встановіть «стандартний пакет доказів» команд для інцидентів.

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

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

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

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber, CsName"
WindowsProductName : Windows Server 2022 Standard
WindowsVersion     : 21H2
OsBuildNumber      : 20348
CsName             : FS-PRD-01

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

Рішення: Якщо видання/версія неправильні, зупиніться і виправте. Не розгортайте продукцію на «майже правильно».

Завдання 2: Перевірте стан очікування перезавантаження (перед тим, як звинувачувати «випадкову» поведінку)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending' -ErrorAction SilentlyContinue | Out-String"

Що це означає: Якщо це повертає вміст (ключ існує), Windows часто перебуває в середині обслуговування. Деякі ролі/драйвери поводяться дивно до перезавантаження.

Рішення: Якщо є очікування перезавантаження — заплануйте його зараз, перш ніж «продовжити конфігурування» і створити напівзастосований стан.

Завдання 3: Перевірте ім’я хоста, приєднання до домену і стан захищеного каналу

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

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
True

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

Рішення: Якщо Test-ComputerSecureChannel не пройшов, виправте довіру (часто це час/DNS) перед встановленням служб, що залежать від домену.

Завдання 4: Підтвердіть IP-конфігурацію, DNS та пастки з «кількома шлюзами»

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DNSServer"
InterfaceAlias    : Ethernet0
IPv4Address       : 10.20.30.40
IPv4DefaultGateway: 10.20.30.1
DNSServer         : {10.20.0.10, 10.20.0.11}

Що це означає: У вас один шлюз за замовчуванням (добре), а DNS вказує на внутрішні резолвери (зазвичай правильно для серверів у домені).

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

Завдання 5: Перевірте розвʼязування DNS і реєстрацію

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName -Name corp.example -Type A"
Name      Type TTL Section IPAddress
----      ---- --- ------- ---------
corp.example A   600 Answer  10.20.0.20

cr0x@server:~$ powershell -NoProfile -Command "ipconfig /registerdns"
Windows IP Configuration

Registration of the DNS resource records for all adapters of this computer has been initiated. Any errors will be reported in the Event Viewer in 15 minutes.

Що це означає: Базовий DNS працює і сервер може реєструвати свої записи (критично для багатьох Windows-робочих процесів).

Рішення: Якщо у DNS Client events зʼявляються помилки реєстрації — виправте дозволи/налаштування очищення та підтвердіть правильні DNS-суфікси.

Завдання 6: Підтвердіть джерело синхронізації часу і зсув (Kerberos звертається)

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

Що це означає: Ви синхронізуєте час із контролером домену (типова поведінка для членів домену). Stratum вказує на якість джерела.

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

Завдання 7: Перевірте стан Windows Update і встановлені хотфікси

cr0x@server:~$ powershell -NoProfile -Command "Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOn"
HotFixID  InstalledOn
--------  -----------
KB503xxxx 1/28/2026 12:00:00 AM
KB503yyyy 1/14/2026 12:00:00 AM
KB503zzzz 12/10/2025 12:00:00 AM

Що це означає: Ви можете швидко довести рівень патчів. Це важливо, коли вендори запитують: «Ви актуальні?»

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

Завдання 8: Перевірте профіль брандмауера і ефективні правила

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

Що це означає: За замовчуванням вхідні зʼєднання блокуються (добре). Вихідні дозволені — це поширено; пізніше можна звузити через проксі або allow-list.

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

Завдання 9: Підтвердіть критичні сервіси (і що нічого зайвого не працює)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service | Where-Object {$_.Status -eq 'Running'} | Select-Object -First 10 Name, DisplayName, StartType"
Name    DisplayName                         StartType
----    -----------                         ---------
Dnscache DNS Client                         Automatic
LanmanServer Server                         Automatic
EventLog Windows Event Log                  Automatic
WinRM    Windows Remote Management (WS-Management) Automatic

Що це означає: Ви шукаєте «сюрпризні сервіси» (сторонні агенти, застарілі протоколи, випадкові оновлювачі від вендорів).

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

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

cr0x@server:~$ powershell -NoProfile -Command "Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, Size, OperationalStatus"
Number FriendlyName          PartitionStyle Size         OperationalStatus
------ ------------          -------------- ----         -----------------
0      NVMe RAID Controller  GPT            476.94 GB    Online
1      DataDisk01            GPT            3.64 TB      Online

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, SizeRemaining, Size"
DriveLetter FileSystemLabel FileSystem SizeRemaining Size
----------- -------------- --------- ------------- ----
C           OS             NTFS      120.45 GB     200 GB
D           DATA           NTFS      2.10 TB       3.64 TB

Що це означає: Використовується GPT (добре). Є чітке маркування і адекватне вільне місце.

Рішення: Якщо C: маленький — виправляйте зараз. Оновлення Windows, сховище компонентів і дампи покарають «мінімалізм».

Завдання 11: Перевірте налаштування цілісності файлової системи і запустіть швидке сканування

cr0x@server:~$ powershell -NoProfile -Command "Repair-Volume -DriveLetter C -Scan -Verbose"
VERBOSE: The volume was scanned and no problems were found.

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

Рішення: Якщо зʼявилися помилки — не встановлюйте застосунки, розслідуйте сховище/прошивку/драйвери негайно.

Завдання 12: Швидко перевірте лічильники продуктивності сховища (затримка каже правду)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\LogicalDisk(D:)\Avg. Disk sec/Read','\LogicalDisk(D:)\Avg. Disk sec/Write' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path, CookedValue"
Path                                          CookedValue
----                                          -----------
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/read 0.0021
\\FS-PRD-01\logicaldisk(D:)\avg. disk sec/write 0.0045

Що це означає: Затримка низька (мілісекунди). Для багатьох навантажень стійкі читання/записи понад ~20–30 мс — це початок болю.

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

Завдання 13: Підтвердіть підтримку TRIM для SSD-поверхневих томів

cr0x@server:~$ powershell -NoProfile -Command "fsutil behavior query DisableDeleteNotify"
NTFS DisableDeleteNotify = 0  (Disabled)
ReFS DisableDeleteNotify = 0  (Disabled)

Що це означає: «0» означає, що сповіщення про видалення (TRIM/UNMAP) увімкнені, що допомагає ресурсам SSD у багатьох стеків.

Рішення: Якщо увімкнено, але ваш бекенд сховища погано обробляє UNMAP (деякі тонкопривʼязані SAN), узгодьте з командою сховища перед тим, як змінювати налаштування сліпо.

Завдання 14: Підтвердіть версії драйверів для NIC і контролера сховища

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object {$_.Status -eq 'OK'} | Select-Object -First 3 FriendlyName, InstanceId"
FriendlyName                    InstanceId
------------                    ----------
Intel(R) Ethernet Server Adapter PCI\VEN_8086&DEV_1592&SUBSYS...

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_PnPSignedDriver | Where-Object {$_.DeviceName -like '*Ethernet*'} | Select-Object -First 1 DeviceName, DriverVersion, DriverDate"
DeviceName                               DriverVersion DriverDate
----------                               ------------ ----------
Intel(R) Ethernet Server Adapter         2.1.3.0       2024-11-02

Що це означає: Ви можете довести походження драйвера і його вік.

Рішення: Якщо у виробничому середовищі стоять вбудовані (inbox) драйвери для критичного обладнання — розгляньте драйвери від вендора. Але не «оновлюйте» під час інциденту без плану відкату.

Завдання 15: Перевірте розміри журналів подій і політику збереження (бо значення за замовчуванням скупі)

cr0x@server:~$ powershell -NoProfile -Command "wevtutil gl System | findstr /i \"maxSize retention\""
maxSize: 20971520
retention: false

Що це означає: 20 МБ — це крихітно в реальному житті. Retention false означає перезапис по мірі необхідності.

Рішення: Збільшіть розміри і/або пересилайте логи. Якщо цього не зробити, ви втратите ключові докази до того, як відкриєте Event Viewer.

Завдання 16: Підтвердіть конфігурацію аварійних дампів (страховка «ми не можемо відтворити»)

cr0x@server:~$ powershell -NoProfile -Command "wmic recoveros get DebugInfoType, MinidumpDirectory, OverwriteExistingDebugFile"
DebugInfoType  MinidumpDirectory           OverwriteExistingDebugFile
7              %SystemRoot%\Minidump       TRUE

Що це означає: DebugInfoType 7 зазвичай означає автоматичний дамп пам’яті. Розташування minidump визначене.

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

Налаштування сховища, яке вас не підведе

Том ОС: тримайте його чистим, достатньо великим і нудним

Дайте C: простір. Не «тільки достатньо». Простір. Компонентний магазин Windows росте, патчі розширюються і звужуються, а дампи потребують місця. Якщо ви віртуалізовані, thin-provisioning може допомогти — поки не перестане. У будь-якому випадку моніторьте вільне місце і встановіть оповіщення.

Томи даних: маркуйте, розділяйте і вибирайте розмір кластера навмисно

Більшість робочих навантажень Windows нормально працюють із стандартними розмірами алокації NTFS, але не всі. Бази даних і системи з великим трафіком можуть отримати вигоду від більших кластерів, але це рішення для конкретного навантаження. Не наслідуйте «64K кластери» просто тому, що хтось колись сказав це на конференції.

Для файлових серверів подумайте, як ви будете робити квоти, дедуплікацію і політики антивірусу. Для SQL дотримуйтеся рекомендацій вендора і вимірюйте. Для зберігання VM зверніть увагу на випадкові записувальні патерни і метадані.

Storage Spaces vs апаратний RAID vs SAN LUN

Апаратний RAID дає передбачувану поведінку, але потрібно перевіряти політику кешування і захист батареєю/флешем. Storage Spaces може бути відмінним, але він чутливий до конфігурації: колонки, інтерлив, стійкість і обізнаність шасі мають значення. SAN LUN перекладає складність на масив — добре, коли команда масиву компетентна, небезпечно, коли «хтось інший» володіє правдою.

Кеш запису: найшвидший спосіб втратити дані і найшвидший спосіб гарно виглядати в бенчмарках

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

Вибір файлової системи: NTFS vs ReFS (і коли не гратися)

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

Мережа: робіть нудно навмисно

Один шлюз за замовчуванням на хост (майже завжди)

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

Teaming NIC: робіть це з наміром

Teaming може підвищити стійкість, але додає шар, який ламається новими й цікавими способами. Якщо створюєте team — документуйте режим (switch independent vs LACP), хешування і де живе VLAN-тегування. Потім протестуйте відмову: витягніть кабель і подивіться на трафік.

DNS: не «допомагайте» собі до спліт-брейн

Сервери, що приєднані до домену, повинні використовувати внутрішні DNS. Публічні резолвери на члені домену — класичне джерело дивних речей (SRV-запити не працюють, AD-інтегровані зони ігноруються, періодичні проблеми із розвʼязуванням). Якщо потрібне інтернет-розвʼязування — налаштуйте форвардинг у вашій DNS-інфраструктурі, а не на випадкових серверах.

Ідентичність, час і ланцюги довіри

Синхронізація часу: вирішіть, хто авторитетний

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

Сертифікати: плануйте заздалегідь, якщо закінчуєте TLS локально

Якщо сервер хостить HTTPS-ендпоїнти (IIS, WinRM через HTTPS, кастомні сервіси), вирішіть стратегію сертифікатів раніше. Внутрішнє PKI? Публічний CA? Як ви автоматизуєте оновлення? Прострочені сертифікати — відмова, яка приходить у вигляді календарного нагадування, яке ви ігноруєте.

Локальний адміністратор: лише для крайніх випадків, під моніторингом

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

Базова безпека: зачиніть двері, але не себе

Почніть з менше ролей і функцій

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

Брандмауер: allow-list для вхідного і документуйте виключення

Встановіть вхід за замовчуванням у блокування (як показано раніше) і створюйте явні правила для потрібних сервісів. Називайте правила читаємими іменами: «Allow SMB from FileServerSubnet», а не «New Rule 47». Тримайте обсяг правил вузьким: IP-адреси/підмережі джерела, профілі і порти.

Віддалене керування: WinRM підходить; неконтрольований WinRM — ні

Увімкніть PowerShell Remoting для операцій, але обмежте, хто може ним користуватися. Розгляньте HTTPS-слухачі там, де потрібно. Якщо відкриєте WinRM широко без контролю — ви даруєте поверхню атаки.

Гігієна SMB: відключайте те, що не потрібно

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

Жарт #2: SMBv1 як факс-машина: іноді ще працює, і саме тому вона лякає.

Логування, телеметрія та збереження доказів

Змінюйте розміри журналів зараз, а не під час інциденту

Розміри журналів за замовчуванням настроєні на «адмін іноді дивиться Event Viewer», а не на реальний інцидентний аналіз. Збільшіть System, Application, Security і ролі-специфічні журнали (DNS Server, DFSR, Hyper-V, Failover Clustering тощо).

Пересилайте журнали поза коробкою

Локальні журнали крихкі. Атакувальники їх чистять, диски заповнюються, а ротація переписує. Пересилайте в центральний колектор/SIEM. Якщо це немає — хоча б пересилайте критичні журнали на Windows Event Collector. Коли сервер горить, вам потрібні докази десь ще.

Базові лічильники продуктивності

Щонайменше моніторте CPU, пам’ять, затримку диска, довжину черги диска (з контекстом), помилки/скиди мережі і ключовий стан сервісів. Затримка перемагає завантаження як предиктор проблем: диск при 20% завантаженості може все одно гальмувати ваш додаток, якщо I/O-патерни патологічні.

Резервні копії та відновлення: зробіть це реальним

Бекапи без тестів відновлення — це просто дорогі відчуття

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

Визначте RPO і RTO простими словами

Які дані ви можете втратити (RPO)? Скільки часу сервіс може бути недоступним (RTO)? Якщо не можете відповісти — у вас немає стратегії бекапів, у вас є хобі бекапів.

Захистіть бекапи від сервера

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

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

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

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

• Це один сервер чи багато?
• Це одна роль (файлшеринг, веб, AD, SQL) чи все?
• Будь-які патчі, перезавантаження, оновлення драйверів, зміни політик, поновлення сертифікатів?

Друге: перевірте чотири поширені насичення (CPU, пам’ять, затримка диска, мережа)

• CPU: тривале високе навантаження, довгі черги ready у віртуалізованому середовищі.
• Пам’ять: малий доступний обсяг пам’яті, інтенсивний пейджінг, обрізання working set.
• Диск: стрибки затримки, накопичення черг, помилки контролера.
• Мережа: скиди/помилки, невідповідність дуплексу, проблеми DNS, петлі маршрутизації.

Третє: перевірте розвʼязання і час

Проблеми з DNS і часом постійно маскуються під збій додатків. Якщо автентифікація чи виявлення сервісів дивні — перевірте Resolve-DnsName і w32tm на початку.

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

Шукайте скиди диска/контролера, попередження NTFS, відмови кластерів, падіння сервісів і помилки аудиту безпеки. Не поверхнево. Фільтруйте за часовим інтервалом навколо заявленого початку.

П’яте: ізолюйте: це хост, VM чи залежність?

Якщо віртуалізовано — порівняйте лічильники гостьової ОС з метриками хоста. Якщо сховище спільне — перевірте, чи інші системи бачать затримку. Якщо це залежність (AD/DNS/SAN) — перестаньте вважати це проблемою одного сервера.

Поширені помилки: симптом → корінна причина → виправлення

1) «Усе повільно після інсталяції»

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

Корінна причина: Драйвер сховища/контролера працює на загальному inbox-драйвері, кеш запису неправильно налаштований або RAID ініціалізується у фоновому режимі з деградованою продуктивністю.

Виправлення: Встановіть драйвери/інструменти від вендора, перевірте кеш + BBU/флеш-захист, підтвердіть статус ініціалізації RAID, виміряйте лічильники затримки диска і журнали подій контролера.

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

Симптоми: Помилки Kerberos, RDP відмовляє, GPO непослідовні, Test-ComputerSecureChannel періодично падає.

Корінна причина: Дрейф часу або неправильна конфігурація DNS (публічний DNS на члені домену, неправильний список суфіксів або застарілі записи).

Виправлення: Виправте DNS на внутрішні сервери, запустіть w32tm /resync, перевірте ієрархію часу DC, очистіть і перереєструйте записи DNS.

3) «Порти були відкриті вчора, заблоковані сьогодні»

Симптоми: Застосунок працює в одній мережі, але не в іншій; брандмауер поводиться непослідовно.

Корінна причина: Мережевий профіль змінився (Domain vs Public) через NLA/DNS досяжність; правила брандмауера обмежені для Domain профілю.

Виправлення: Відновіть визначення доменної мережі (досяжність DNS/DC), налаштуйте області правил правильно і уникайте створення правил, що працюють тільки за ідеальних умов.

4) «Місце на C: постійно зникає»

Симптоми: C: заповнюється несподівано, оновлення не проходять, сервер стає нестабільним.

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

Виправлення: Перенесіть дані/логи застосунків на том даних, змініть розмір C: при потребі, впровадьте ротацію/пересилання логів і встановіть оповіщення про рівень вільного місця.

5) «Бекапи проходять, але відновлення не працює»

Симптоми: Завдання бекапу зелене, але відновлення дає помилки або відновлені дані неповні.

Корінна причина: Облікові дані/дозволи не перевірені, налаштування VSS/application-aware неправильні або репозиторій бекапів недоступний під час інциденту.

Виправлення: Виконуйте тести відновлення, перевіряйте VSS-writer’и, забезпечте доступ до репозиторію за окремими обліковими даними і задокументуйте runbook відновлення.

6) «У нас немає логів з часу інциденту»

Симптоми: Event Viewer нічого корисного не показує; Security log перезаписано; прогалини в телеметрії.

Корінна причина: Розміри журналів за замовчуванням, політика перезапису і відсутність пересилання.

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

Три короткі корпоративні історії (що насправді відбувається)

Коротка історія 1: Інцидент через неправильне припущення

Вони розгорнули нову VM Windows Server 2022 для невеликого внутрішнього веб-додатка. Інженер розумно припустив, що «DNS в порядку», бо VM могла резолвити публічні домени. Додаток пішов у прод і одразу почав таймаутити при спробі автентифікувати користувачів.

Команда гналася за логами додатка, потім за налаштуваннями IIS, потім переписала шматок конфігурації. Нічого не допомогло. Це було переривчасто, а такі збої — найвитратніші.

Зрештою хтось запустив Resolve-DnsName для SRV-записів домену і отримав нісенітницю. VM була вказана на публічний резолвер «тимчасово» під час побудови. Публічний DNS не відповість на внутрішні AD SRV-запити. Kerberos іноді відпрацьовував з кешу, іноді падав залежно від шляху коду.

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

Коротка історія 2: Оптимізація, що обернулась проти

Міграція файлового сервера відставала. Щоб пришвидшити, хтось увімкнув агресивний кеш запису і кілька «настроювань продуктивності» за рекомендацією форумного допису 2016 року. Бенчмарки виглядали фантастично. Всі заспокоїлись.

Через два тижні сталася коротка втрата живлення в стояку. Не драматична — достатня, щоб відключити PDU. Сервери повернулися. Файловий сервер також, але користувачі почали повідомляти про пошкоджені файли й «документи, що не відкриваються».

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

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

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

Хост Windows Server 2022, що працював з критичним бізнес-сервісом, двічі впав з синім екраном за тиждень. Вендор попросив дампи і журнали подій. Історично це закінчується «не можемо відтворити» і довгим очікуванням.

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

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

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

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

1) Встановлювати Server Core чи Desktop Experience?

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

2) Який розмір має бути у диска C:?

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

3) NTFS чи ReFS для томів даних?

За замовчуванням — NTFS, якщо не можете обґрунтувати ReFS для конкретної ролі і перевірили підтримку функцій. ReFS корисний у деяких віртуалізаційних і сценаріях цілісності, але не є універсальним покращенням.

4) Чи треба встановлювати драйвери від вендора, чи достатньо драйверів Windows?

Для продукції настійно розгляньте драйвери/прошивку від вендора, особливо для фізичних серверів (NIC і сховище). Inbox-драйвери створені для широкої сумісності, а не обов’язково для кращої продуктивності або швидшого виправлення багів для вашого обладнання.

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

Перевірте лічильники затримки диска (Avg. Disk sec/Read і Write), потім зіставте з журналами подій на предмет скидів контролера і з таймаутами застосунків. Висока затримка при нормальному CPU — класичний підпис.

6) Чому синхронізація часу в чеклисті? Хіба це не автоматично?

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

7) Як розмірювати журнали подій?

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

8) Який мінімальний тест відновлення після інсталяції?

Відновіть файл і переконайтеся, що він відкривається. Якщо сервер хостить застосунок — виконайте application-consistent відновлення або принаймні перевірте стан VSS-writer’ів і переконайтеся, що дозволи та метадані зберігаються.

9) Чи варто відключати вихідний трафік у брандмауері Windows?

Не в перший день, якщо у вас немає процесної зрілості для цього. Блокування виходу — відмінний контроль, але воно вимагає дисциплінованих allow-list і вмінь усувати проблеми. Почніть з allow-list для вхідного й додавайте контроль виходу свідомо.

10) Як уникнути «таємного дрейфу конфігурації» після інсталяції?

Приєднуйте до домену з наміром і GPO-базлайнами, керуйте конфігурацією через автоматизацію, де можливо, і зберігайте запис встановлених ролей/функцій і затверджених агентів. Дрейф відбувається, коли ніхто не володіє «стандартом».

Висновок: наступні кроки, за які ви подякуєте собі

Після чистої інсталяції ваша мета не «щоб вона завантажилась». Ваша мета — «щоб її можна було діагностувати, патчити, відновити і щоб вона була нудною». Ось реальне визначення стабільності.

Зробіть наступне:

1. Запустіть завдання перевірки вище і збережіть виводи як базові докази.
2. Змініть розміри журналів подій і підтвердіть пересилання поза сервер.
3. Доведіть бекапи, відновивши щось реальне.
4. Налаштуйте моніторинг для затримки диска, вільного місця і стану сервісів до того, як користувачі знайдуть проблеми за вас.
5. Задокументуйте фінальний стан: мережеву конфігурацію, розклад сховища, рівень патчів і будь-які відхилення від стандарту.

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