Чому Event Viewer — це не «для тих, хто шукає неприємностей»

Windows Server веде десятки журналів, але 95% адмінів дивляться туди тільки після інциденту. Це проблема: майже всі великі поломки (диск, AD, мережа, безпека) залишають слід у вигляді менших попереджувальних івентів за години-дні до того, як проблема стане видимою користувачу. Якщо моніторинг налаштований під ці конкретні Event ID — ви виграєте час, інколи цілий тиждень.

1. Event ID 41 — Kernel-Power

Source: Microsoft-Windows-Kernel-Power · Log: System · Severity: Critical

Сервер вимкнувся «брудно» — без чистого shutdown. Найчастіше: збій живлення, перегрів CPU, BSOD без логування, відмова блока живлення.

Дія: якщо повторюється — перевірити UPS, температуру, журнал BSOD у C:\Windows\Minidump. Один-два рази на півроку — терпимо. Кілька разів на тиждень — серйозно.

2. Event ID 6008 — Previous shutdown unexpected

Source: EventLog · Log: System · Severity: Error

Парний близнюк #41. EventLog при старті фіксує, що минулий shutdown не був чистим. Якщо #41 ловить «факт смерті», то #6008 — «факт того, що ми повернулись у незрозумілому стані».

Дія: моніторити разом з #41, ставити алерт, якщо за добу більше 1 події.

3. Event ID 7 — Bad block on disk

Source: Disk · Log: System · Severity: Error

«The device, \Device\Harddisk0\DR0, has a bad block.» Прямий сигнал від драйвера диска: на диску знайдено пошкоджений сектор. Не SMART, не chkdsk — реальний bad block при читанні.

4. Event ID 153 — IO error on logical disk

Source: Disk · Log: System · Severity: Warning

«The IO operation at logical block address X for disk Y was retried.» Це означає, що операція з диском не вдалась з першого разу, але система її повторила і отримала результат. Тобто диск ще працює, але повільно і з помилками.

Дія: запустити chkdsk /scan, перевірити SMART (smartctl -a або вендор-утиліта), запланувати заміну.

5. Event ID 55 — NTFS structure corrupted

Source: Ntfs · Log: System · Severity: Error

«The file system structure on volume X is corrupt and unusable.» NTFS виявив пошкодження у файловій системі. Може бути наслідком #7/#153, або наслідком жорсткого вимкнення під час запису.

Дія: запустити chkdsk C: /f /r у вікні обслуговування. Перед цим — повний бекап.

6. Event ID 1102 — Audit log was cleared

Source: Eventlog · Log: Security · Severity: Information

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

7. Event ID 4625 — Failed logon

Source: Microsoft-Windows-Security-Auditing · Log: Security · Severity: Information

Невдала спроба входу. Один-два за день — нормально (хтось ввів пароль не з тієї розкладки). Десятки за хвилину з різних IP — атака брутфорсу через RDP/SMB.

Дія: налаштувати алерт на «> 20 #4625 за 5 хвилин з одного IP». Закрити RDP від інтернету (firewall, VPN, port-knock) або поставити IPBan.

8. Event ID 4740 — Account locked out

Source: Microsoft-Windows-Security-Auditing · Log: Security · Severity: Information

Account Lockout Policy спрацювала: акаунт заблоковано після N невдалих спроб. Може бути наслідком брутфорсу (#4625) або «застряглої» сесії на іншій машині, яка ходить зі старим паролем.

Дія: подивитись Source Workstation у деталях події — звідки йшли спроби. Якщо це робоча станція легітимного користувача — там, ймовірно, кешований старий пароль (RDP, mapped drive, scheduled task).

9. Event ID 1014 — DNS resolution timeout

Source: DNS Client Events · Log: System · Severity: Warning

«Name resolution for the name X timed out after none of the configured DNS servers responded.» Сервер не зміг достукатись до жодного DNS-сервера протягом таймауту.

Дія: якщо одиничне — терпимо. Якщо постійно — перевірити мережу, конфігурацію DNS клієнта, доступність DNS-серверів. Часто перший симптом перед тим, як AD «відвалиться» від домен-контролерів.

10. Event ID 36874 — Schannel TLS handshake failed

Source: Schannel · Log: System · Severity: Error

«An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server.» Хтось намагається з'єднатись з сервером, але алгоритми шифрування не співпадають.

Дія: якщо ви вимикали старі TLS/cipher suites — це нормальні події від клієнтів, які ще не оновились. Якщо ні — перевірте конфігурацію Schannel у реєстрі (HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL).

11. Event ID 1058 — Group Policy failed to apply

Source: Microsoft-Windows-GroupPolicy · Log: System · Severity: Error

«The processing of Group Policy failed.» Сервер не зміг застосувати групові політики — найчастіше через DNS, SYSVOL replication, або проблеми з ACL на GPO.

Дія: запустити gpresult /h gpresult.html, переглянути звіт. Перевірити доступ до SYSVOL з сервера.

12. Event ID 1000 — Application error

Source: Application Error · Log: Application · Severity: Error

Падіння конкретного процесу з адресою винуватцем (faulting module). Дозволяє швидко зрозуміти, який саме DLL/EXE впав.

Дія: подивитись «Faulting module name» — часто це чітко вказує на драйвер або сторонній compoнент. Збирати такі події у моніторинг по конкретним продуктам (наприклад, M.E.Doc, BAS, sql).

Як налаштувати моніторинг цих подій без сторонніх інструментів

Windows вміє сам запускати дію у відповідь на конкретну подію. Прямо у Event Viewer:

1. Знайти потрібну подію (наприклад, Event ID 7 з Source Disk).
2. ПКМ → Attach Task To This Event….
3. Вказати дію: запустити PowerShell-скрипт, який надішле email через Send-MailMessage (для старих) або через System.Net.Mail.SmtpClient + Microsoft.Graph для O365, або просто WebHook у Telegram-бота.

Підсумок

Зведений короткий перелік ID, який варто скопіювати у свою «cheat sheet»:

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