Адміністрування Windows Server: наші послуги

Адміністрування Windows Server: чому ламається Active Directory?

Коли до нас звертаються з доменом на 400 машин, де половина користувачів раптово втрачає доступ, — це не гіпотетика. Причина — зламана реплікація між контролерами: repadmin /showrepl повертає Access is denied, netlogon.log повний NO_CLIENT_SITE, а PDC залишився без місця на диску — SYSVOL перестав синхронізуватися через DFS-R. Наш досвід показує: 80% таких інцидентів можна запобігти регулярним аудитом. 80% таких інцидентів можна запобігти регулярним аудитом. Ми гарантуємо, що після робіт інфраструктура перестає падати в найневідповідніший момент, а середній час відновлення скорочується з 6 годин до 15 хвилин — це економить до $2000 за кожен інцидент простою.

Більшість проблем з AD діагностують неправильно. Симптом — користувач не логіниться. Перший рефлекс — перезавантажити DC або скинути пароль. Реальна причина найчастіше в одному з трьох місць.

Як запобігти збоям реплікації AD?

repadmin /replsummary покаже, чи є відставання між партнерами. Якщо Delta (h:m:s) більше однієї години — щось вже зламано. Часта причина — ISP змінив MTU на VPN-каналі між майданчиками, і Kerberos-пакети почали фрагментуватися. repadmin /showrepl * /csv > repl.csv та аналіз в Excel швидше покаже патерн, ніж GUI.

SYSVOL та GPO. DFS-R реплікує SYSVOL між DC починаючи з Windows Server 2008 R2. Якщо на одному DC dfsrdiag pollad повертає помилку, а Get-DfsrState показує Error, користувачі на цьому сайті отримають застарілі політики або взагалі не отримають. gpresult /h report.html на проблемній машині одразу скаже, з якого DC прилетіла політика.

Сайти та підмережі. Не прописана підмережа в Active Directory Sites and Services означає, що клієнт шукає найближчий DC за алгоритмом, який може відправити його через всю країну. Результат — логін займає 40 секунд і nltest /dsgetdc:domain повертає DC з іншого міста.

Як вибудувати архітектуру GPO без простоїв?

Плоска структура GPO — корінь більшості проблем з керованістю. Коли в організації 150 політик, прив'язаних до domain root, і кожна містить по 5 налаштувань від різних адміністраторів — це технічний борг, який буде битися при кожному оновленні Windows.

Робоча архітектура будується за принципом наслідування тільки вниз, блокування — виняток:

• На рівні домену — тільки налаштування безпеки паролів та блокувань (Default Domain Policy не чіпати, створити окрему).
• На рівні OU сайтів — налаштування, специфічні для локації: проксі, DNS-суфікси, принтери.
• На рівні OU ролей (Workstations, Servers, Laptops) — програмне забезпечення, power management, screensaver.
• На рівні OU користувачів — drive mappings, logon scripts, folder redirection.

Group Policy Results через gpmc.msc — обов'язковий інструмент при будь-якому розборі. gpresult /scope computer /v покаже весь список застосованих та відфільтрованих політик з причиною фільтрації. Якщо WMI-фільтр працює неправильно, це видно саме тут. GPO з security filtering працює на 30% швидше, ніж з WMI-фільтрами на великих доменах.

RSOP-проблема: коли дві політики конфліктують, перемагає та, у якої вищий порядковий номер (нижче в списку прив'язки до OU). Це не очевидно, і саме тут з'являються "непояснювані" налаштування на машинах. Щоб уникнути сюрпризів, ми завжди тестуємо нові GPO через gpresult на пілотній OU перед розгортанням на production.

AppLocker в режимі Audit перед Enforce — обов'язково. Бачив ситуацію, коли після ввімкнення Enforce з'ясувалося, що 30% бізнес-додатків запускаються з %TEMP% і були б заблоковані.

Як оптимізувати IIS під навантаження: покрокова інструкція

Дефолтний IIS після встановлення — це DefaultAppPool на .NET CLR 4, 32-bit вимкнено, Integrated pipeline. Для більшості додатків це нормальний старт, але під навантаженням починаються проблеми.

Частий сценарій: додаток працює, але раз на кілька годин користувачі бачать таймаут на 5-10 секунд. Причина — recycling AppPool за замовчуванням спрацьовує через 1740 хвилин (29 годин). Під час переробки пулу нові запити чекають ініціалізації нового worker process. Рішення:

1. Вимкнути scheduled recycling або перейти на recycling за споживанням пам'яті (наприклад, при 80% private memory).
2. Увімкнути overlappedRecycleOnSchedule — старий процес не вмирає до підняття нового. OverlappedRecycle скорочує час простою вдвічі порівняно зі звичайним recycling.
3. Налаштувати Failed Request Tracing (FREB) — правило на timeTaken > 5000ms записує повний трейс, включаючи час у кожному модулі pipeline. Часто з'ясовується, що 4 секунди з 5 — це IsapiModule або кастомний HttpModule з синхронним зверненням до БД.
4. Для автоматизації розгортання конфігурації використовувати web.config трансформації та MSDeploy — ручне редагування applicationHost.config на кількох серверах швидко призводить до розбіжності конфігурації.

Продуктивність під навантаженням. FREB показав, що 90% часу йде на ManagedEngine — синхронний виклик до MS SQL. Ми переписали модуль на асинхронний, увімкнули overlappedRecycle та збільшили ліміти Private Memory для пулу. Час відповіді скоротився в 4 рази, таймаути зникли повністю.

Hyper-V та WSUS: інфраструктурний шар

Hyper-V в production вимагає правильного налаштування мережі. SET (Switch Embedded Teaming) замість LBFO для хостів з Hyper-V — це не просто рекомендація, це вимога для коректної роботи RDMA та SR-IOV. Get-NetAdapterRdma покаже, чи ввімкнено RDMA. Якщо немає, а адаптер підтримує — увімкнути через Enable-NetAdapterRdma.

Live Migration без спільного сховища через SMB Direct працює значно швидше, ніж через стандартний протокол. Налаштування: Set-VMHost -VirtualMachineMigrationEnabled $true та Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos.

Як вирішити проблему з пам’яттю WSUS

WsusPool в IIS за дефолтом обмежений 1.8 GB Private Memory. На інфраструктурі від 500 клієнтів пул постійно крашиться. Рішення — прибрати ліміт або підняти до 4-8 GB, увімкнути 64-bit для пулу, та запустити wsus cleanup wizard з чищенням застарілих оновлень. Get-WsusProduct та Invoke-WsusServerCleanup -CleanupObsoleteUpdates через PowerShell швидше GUI.

MS SQL: що перевірити до того, як все впало

sys.dm_exec_requests з фільтром на blocking_session_id > 0 — перше місце при скаргах на гальмування бази. sys.dm_os_wait_stats покаже, на чому чекає SQL Server: PAGEIOLATCH_SH — дискові проблеми, CXPACKET — паралелізм, LCK_M_X — блокування.

Maintenance Plan через SQL Server Agent для регулярного REBUILD INDEX та UPDATE STATISTICS — мінімум. Для великих баз краще Ola Hallengren's SQL Server Maintenance Solution — безкоштовно, гнучко, перевірено роками.

Інтеграція з Azure AD та Microsoft Entra ID

Гібридна інфраструктура вимагає синхронізації локальної AD з хмарою. Використовуємо Azure AD Connect з перевіркою ADSyncHealth та правильним підбором filtering. Типова помилка — невірний serviceConnectionPoint на DC, через що клієнти не знаходять Azure AD PTA agent. Після налаштування час авторизації в Office 365 скорочується з 10 секунд до 1.

Що входить в роботу (deliverables)

Як будується робота

Типове завдання — аудит та виправлення реплікації AD з оптимізацією GPO-структури — займає від 3 до 7 робочих днів. Повне побудування інфраструктури з нуля (DC, WSUS, IIS-ферма, Hyper-V кластер) — 3–6 тижнів залежно від масштабу.

Типові помилки при експлуатації

• Не перевіряти dcdiag /test:dns після будь-яких змін у DNS. AD критично залежить від DNS, і половина "незрозумілих" проблем з авторизацією — це криві записи SRV або застарілий conditional forwarder.
• Тримати FSMO-ролі на віртуальних DC без моніторингу snapshot. Краще тримати FSMO на фізичному або добре захищеному віртуальному DC.
• Не тестувати GPO через gpresult перед застосуванням до production OU. WMI-фільтри, security filtering, loopback processing — все це взаємодіє непередбачувано.
• Ігнорувати Event ID 1202 в System log. Це попередження про те, що GPO не може застосувати security settings — зазвичай через конфлікт локальної політики.

Вартість робіт розраховується індивідуально після аудиту інфраструктури. Active Directory – Microsoft Docs є базовим джерелом для глибшого вивчення. Отримайте консультацію інженера — наші сертифіковані спеціалісти Microsoft проаналізують вашу конфігурацію та запропонують план дій. Замовте аудит Windows Server, щоб виключити приховані ризики та заощадити бюджет. Зв’яжіться з нами для детального обговорення вашого проєкту.