Создание подписки на события в Windows с Event Subscriber

Про большую часть проблем, которые происходят с операционной системой и оборудованием, можно узнать через логи и журналы. В Windows, логи, называются так же событиями (events), а для их просмотра используется интерфейс под названием "Просмотр событий" (Event Viewer). События хранятся на компьютере, на котором они же и создаются. Такая ситуация может вызвать неудобства, если вы работаете со множеством серверов. Мы можем использовать функционал, который называется "Подписки" (Event Subscription) для сбора таких логов в одном месте. Как это можно сделать и будет рассмотрено, на примерах, в этой статье.

Как работают подписки на события

Главный компьютер (сервер), который будет получать и хранить события с других хостов, называют "сборщиком" (collector). Он может работать в двух режимах:

Коллектор может подключаться к выбранным компьютерам сам и забирать с них обновления (в GUI называется "Инициировано сборщиком"/ "Colletor Initiated"). Так же называют pull подпиской;
Компьютеры (клиенты) сами отправляют события на сборщик (сервер) (в GUI "Инициировано исходным компьютером"/"Source Computer Initiated"). Так же называется "event forwarding" или push подпиской.

Моменты, которые я отмечу для "Colletor Initiated":

Обработка логов - ресурсоемкая задача. Если сервер-коллектор будет забирать логи одновременно - это может задействовать большое количество ресурсов;
В подписку могут быть добавлены только доменные компьютеры. В т.ч. вы не можете указывать группы в подписке, а только отдельно компьютеры;
Политики использовать не обязательно и общая настройка немного проще.

То что я отмечу для "Source Computer Initiated":

Первоначальная настройка может вызвать сложности, решение которых может занять существенное время;
Клиенты сами отправляют логи, что делает нагрузку на сервер меньше;
Легче автоматизируется, если вы хотите добавлять клиентов автоматически;
Можно добавить как группы, так и компьютеры. Компьютер может быть в рабочей группе или домене.

Мой личный выбор - использовать "Collector Initiated" где количество клиентов меньше 10. Если планируется больше, то "Source Computer Initiated". С точки зрения нагрузки - количество клиентов вообще может не играть роли, если клиенты создают по одному логу в 10 минут.

Microsoft, например, рекомендует использовать 4 процессора и 16 ГБ ОЗУ для нагрузки в 2000-4000 клиентов. Как я смог понять это так же равно 3000 событий в секунду.

Логи физически хранятся на дисках. Если логов приходит много, то стоит обратить внимание на скорость дисков.

Предварительная настройка

На обоих сервере и клиенте должен быть включен сервис WinRM и выполнена первоначальная его настройка. Это можно сделать одной из следующих команд.

# cmd
winrm qc

# powershell
Enable-PSRemoting

Проверить, что сервис запущен на обоих компьютерах можно с помощью одной команды.

Get-Service -ComputerName 'localhost' -Name '*WinRM*' | fl *

WinRM, в зависимости от настроек, может использовать протокол HTTP на 5985/TCP порту либо HTTPS на 5986/TCP порту. Это же касается и сбора событий с компьютеров.

Если вы используете компьютеры, которые находятся в домене, у вас по умолчанию используется Kerberos. В некоторых других случаях может использоваться NTLM. В обоих случаях (Kerberos/NTLM или HTTP/HTTPS), обмен логов зашифрован и подключения проходят аутентификацию. Случай с HTTPS используется, когда вы хотите чтобы аутентификация была так же с помощью сертификатов SSL/TLS. Это может понадобиться, когда у вас компьютер вне домена и вы будете использовать NTLM. Вариант с HTTPS, в статье, рассматривается от части.

Выбранные порт должен быть открыт на всех ПК. Проверить, что порт открыт и за ним стоит сервис можно через следующую команду Powershell.

Test-NetConnection -ComputerName 'localhost' -Port 5985

Еще один важный момент - это работа сервиса подписок WEC (Windows Event Collector) на сервере, который будет собирать и хранить логи. По умолчанию, этот сервис, выключен. Вы должны включить его на сервере.

wecutil.exe qc

# проверяем работу службы через Powershell
Get-Service -Name 'Wecsvc' | fl *

Отправка событий на сервер-сборщик

Вариант настройки, когда клиенты сами обращаются к серверу.

Настройка отправляющего хоста

Для того, чтобы компьютер-клиент знал куда отправлять логи, ему нужно указать URL сервера. Этот url можно указать в групповой (или локальной) политике по пути:

Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Пересылка событий
Computer Configuration -> Administrative Templates -> Windows Components -> Event Forwarding

По этому пути открыть политику "Настроить конечный диспетчер подписи" и указать строку следующего типа.

Server=http://<полное доменное имя сборщика>:5985/wsman/SubscriptionManager/WEC,Refresh=60

В этой строке, соответственно, нужно указать FQDN сервера, на который будут отправляться события. В моем случае это 'sr2.domain.local'. Значение "Refresh=60" значит, что раз в 60 секунд будут проверяться новые подписки, а не время отправки логов.

Если вы планировали делать https сервер, то нужно будет указать иной порт (5986) и дополнительно заполнить параметр открытого ключа.

Настройка принимающего сервера

Кроме включенных сервисов (WEC и WinRM) и открытых портов нужно изменить разрешения для URL, которое настраивалось через политику выше. Разрешения по умолчанию могут не работать.

Дело в том, что в редакциях 2012 и старше, права на чтение запросов поступающих на URL 'http://ВашСервер:5985/wsman/', выдается только сервису - WinRM. Служба подписок 'Wecsvs' так же нуждается в доступе к этому URL. Эта ситуация может отличаться в разных редакциях. У Microsoft не всегда было описание этой проблемы и даже сейчас его сложно найти. Проверить есть ли права в вашем случае можно через следующую команду.

netsh http show urlacl url=http://+:5985/wsman/

Если у вас отображается один пользователь и в параметре SDDL только одна пара скобок "(...)" (как в примере выше), то это говорит об отсутствии нужных разрешений. Чтобы добавить пользователя мы должны удалить предыдущую запись и добавить новую запись.

# удаление
netsh http delete urlacl url=http://+:5985/wsman/
# добавление (рекомендую запускать в CMD, а не Powershell)
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

Создание подписки

После этого можно открыть Event Viewer и настраивать подписку нажав следующие кнопки.

В новом окне нужно указать название подписки, например "Сервера SQL". "Конечный журнал" - это место, в которое будут попадать логи. Чаще всего используется журнал "Перенаправленные события" так как он пустой и удобен для сбора логов (не будет путаницы). Часть параметров можно менять после создания подписки.

В данном случае мы используем тип подписки, где клиенты сами отправляют события. Этому типу подписки соответствует настройка "Инициировано исходным компьютером". Мы должны открыть это окно и добавить в список компьютеры, от которых ожидаем отправку событий.

В окне "Выбрать события" можно выбрать журналы, их уровень и установить разные фильтры. Для диагностики и тестирования лучше выбирать один журнал и несколько событий. Большое количество журналов может расходовать весомое количество ресурсов. Во вкладке 'XML' настройки так же можно менять. XML так же можно копировать и использовать в других подписках (в т.ч. импорт через wecutil.exe).

В окне "Дополнительно" указывается протокол и скорость передачи событий. Эти настройки соответствуют следующим значениям:

Обычный (Normal) - отправка либо по достижению 5 событий либо раз в 15 минут;
Уменьшенная пропускная способность (Minimize Bandwith) - раз в 6 часов;
Уменьшенная задержка (Minimize Latency) - раз в 30 секунд.

После нажатия кнопок "Ок" подписка будет создана.

При открытии "Состоянии выполнения" вы должны увидеть зеленные галочки у компьютеров, которые вы добавляли. Они могут появиться не сразу (в моем случае это пару минут). Все события будут попадать в журнал "Перенаправленные события".

Зеленые отметки не всегда говорят, что все работает. Например, после подобных настроек у вас будут отправляться большая часть журналов, но некоторые так и не появятся. Например, для журнала "Безопасность" (Security) нужно будет так же изменить параметры доступа.

Настройка доступа для журнала "Безопасность" (Security)

Локальный доступ, к некоторым журналам, требует отдельных прав. Эти права есть у локальных групп "Читатели журнала событий" (Event Log Readers). Журналам "Безопасность" будет читать сервис "Network Service". Т.е. мы должны добавить эту учетную запись в журнал.

Добавить учетную запись можно через политики и собственноручно. Ниже показан вариант, где пользователь "Network Service" добавлялся в группу для сбора логов с домен контроллера.

Если это не домен-контроллер, то учетная запись добавляется в локальную группу через "Управление компьютером".

После добавления пользователей компьютеры нужно будет перезагрузить т.к. иначе "Network Service" не начнет работу. После перезагрузки, в моем случае, события начали приходить меньше чем за 1 минуту.

Добавить пользователя можно так же через политику, что рассмотрено на другом варианте подписки.

Сбор событий с компьютеров

Так как мы настраиваем сценарий, когда сервер-коллектор будет сам заходить на хосты и забирать логи, мы должны определиться с пользователем и правами для него.

Выдача разрешений на чтение журналов

Кроме открытия порта и запуска сервисов, в зависимости от ситуации, вам может понадобиться добавить в группу "Читатели журнала событий" разные учетные записи:

Учетная запись пользователя или компьютера, который будет забирать логи с удаленных компьютеров. Исключение - администраторы т.к. они уже имеют эти права.
Учетная запись "NETWORK SERVICE", если вы планируете собирать логи с журнала "Безопасность" ("Security"). Даже если вы являетесь администратором - это понадобится.

Как добавляется пользователь в локальную группу - было продемонстрировано в подписке, которая рассматривалась выше. Добавить пользователей в группу можно так же скриптом или через разные политики.

Вариант, показанный на скриншоте ниже, работает через политику "Группы с ограниченным доступом" ("Restricted Groups"). Будьте осторожны т.к. учетные записи, которые добавляются через эту политику, перезаписывают локальных пользователей в соответствующей группе. Чтобы добавить учетную запись - вам нужно:

Открыть или создать политику, затем пройти по соответствующему пути (видно на скриншоте ниже), нажать правой клавишей по "Группы с ограниченным доступом" и выбрать вариант "Добавить группу";
Через кнопку "Обзор" выбрать локальную группу в которую вы планируете добавлять учетные записи. В нашем случае это "Читатели журнала событий" или "Event Log Readers";
Выбрать пользователя, которого вы планируете использовать для сбора логов. В случае, если вы хотите добавить компьютер, то в конце нужно дописать "$", как и в примере ниже с "SR2". Так же добавьте "NETWORK SERVICE", если планируете собирать события из журнала "Безопасность".

Результат работы политики можно увидеть после применения политики, открыв группу локально.

Для того чтобы учетная запись "NETWORK SERVICE" полноценно заработала - потребуется перезагрузка компьютера.

Создание подписки

Откройте "Event Viewer" и нажмите следующие кнопки для создания подписки:

Переходим на страницу подписок;
Открываем окно создания подписки;
Выберете имя для подписки;
Тип подписки, в этом случае, "Инициировано сборщиком";
Окно для добавления компьютеров.

В новом окне добавьте компьютер с которого хотите собирать события.

Добавление компьютера для сбора логов в Windows

В следующем окне выберете типы журналов, событий и т.д., которые планируете забирать с удаленного компьютера. Рекомендую не выбирать большое количество журналов так как это нагрузит систему (при выборе больше 10 штук у вас появится аналогичное предупреждение).

В последнем окне вы можете выбрать тип учетной записи, которую настраивали в предыдущих шагах и скорость получения событий. В моем случае - это учетная запись компьютера SR2. Если вы настраивали пользователя, то вам нужно будет ввести логин и пароль.

Настройки доставки событий следующие:

Обычная (Normal) - раз в 15 минут или по достижению 5 событий;
Уменьшенная пропускная способность (Minimize Bandwidth) - раз в 6 часов;
Уменьшенная задержка (Minimize Latency) - раз в 30 секунд.

Настройка завершена. Проверьте, что у вас нет ошибок в окне с подписками.

Расширенные настройки подписок через wecutil и wevutil

Wecutil (Windows Event Collector Utility) - программа для настройки подписок, wevtutil (Windows Event Utility) - управление событиями.

Выведем более подробную информацию о конкретной подписке.

wecutil gs "Название подписки"

Мы можем изменить время отправки событий, которое в предыдущем случае равнялось 30000 миллисекундам (30 секунд). Для этого изменим профиль и установим новое значение.

wecutil ss "НазваниеПодписки" /cm:Custom
wecutil ss "НазваниеПодписки" /dmlt:"Миллисекунды"

Через интерфейс WEC можно увидеть данные XML, которые относятся только к событиям, но через wecutil можно экспортировать подписку полностью.

wecutil gs "Название подписки" /f:xml > filename.xml

Этот XML файл можно так же импортировать в качестве новой подписки. Вы так же можете изменить XML файл тем самым минуя некоторых настроек, которые доступны только через 'wecutil'.

wecutil cs C:\filename.xml

Обратите внимание, что вы должны будете удалить строку с версией и кодировкой XML документа и так же изменить название. Иначе вы будете получать ошибку "Code 0x80070057 The parameter is incorrect". Так же обращайте внимание на строку "ConfigurationMode", если она стоит в "Normal". Импортируемые подписки могут быть либо в режиме "Custom" или без блока "Delivery".

Подписку можно обновить, используя измененный XML документ, но это часто приводит к ошибкам.

wecutil ss TestSubs2 /c:C:\filename.xml

Некоторые подписки имеют ограничения на количество событий отправляемых за раз. В документациях есть два упоминания, как это можно изменить. Первый - через 'wecutil' и параметр 'DeliveryMaxItems'.

Wecutil ss “SubscriptionNameGoesHere” /dmi:1

Второй вариант - через WinRM и параметр 'MaxBatchItems'. Сам я его не использовал если что.

# просмотр
winrm get winrm/config
# меняем на 5
winrm set winrm/config @{MaxBatchItems="5"}

Поиск ошибок

Хоть и функционал подписок достаточно простой, но его настройка может привести к десяткам ошибок. Усложняет задачу то, что многие ошибки никак не отображаются - события просто не пересылаются. Ниже только часть ошибок, которую я решил на собственном опыте.

Общая диагностика

Первым, что стоит проверить - это открыты ли порты и запущены ли сервисы. Winrm должен быть запущен на обоих компьютерах. Сервис Wecsvc - собирает события и он должен работать только на сервере.

Get-Service -Name 'Winrm','Wecsvc' | select name,status

Порт должен быть открыт на обоих компьютерах.

'SR1','SR2' | Test-NetConnection -Port 5985

Вы так же можете попробовать подключиться через Winrm используя пользователя у которого есть такие права (у группы 'Читатели журналов событий' таких прав нет). Таким образом вы исключите проблему с Winrm.

$cred = Get-Credential
Invoke-Command -ScriptBlock {Get-Location} -Credential $cred -ComputerName 'SR1'

Если у вас не проходит подключение по Winrm, то может проблема в TrustedHost и NTLM подключении, если вы работаете вне домена. В Trusted Host добавляются компьютеры, которым разрешено подключение к текущему. В примере ниже команда, которая разрешает подключаться любым компьютерам.

Set-Item wsman:localhost/client/trustedhosts *

Самым главным окном, которое может рассказать об ошибке, является окно состояния подписки.

Примерно такой же результат можно увидеть, если посмотреть на подписку через консоль.

wecutil gr "НазваниеПодписки"

Кнопка "Повторить" так же может быть полезна, после изменения настроек.

Другие кандидаты на поиск ошибок - это журналы:

Журналы Windows -> Система;
По пути Application and Services Logs (Журналы приложений и служб) -> Microsoft -> Windows -> журналы EventCollector / Eventlog-Forwarding / Windows Remote Management.

Ошибок нет, но логи не приходят

Ошибки могут не появляться если вы создали подписку одновременно на несколько журналов. Вам нужно отметить только один журнал и посмотреть "Состояние выполнения". У вас либо появится ошибка, либо начнут приходить события.

Такая ошибка, как минимум, может произойти когда вы выбрали журнал "Безопасность" с каким-то другим журналом, но не дали права учетной записи "Wecsvc" на чтение данных по URL "http://+:5985/wsman/".

Ошибка 0x80338095 при проверке состояния подключения

Исчезает либо установкой "Оптимизация обработки событий" с "Уменьшенная задержка" в "Обычная" либо даем пользователю "Wecsv" читать данные с URL Wsman с помощью следующей команды (объяснение команды было в статье выше).

# удаление существующей записи
netsh http delete urlacl url=http://+:5985/wsman/
# добавление новой
netsh http add urlacl url=http://+:5985/wsman/ sddl="D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)"

Изменение задержки может убрать ошибку, но логи могут не появляться.

Ошибка (0x5): Отказано в доступе

Связано с тем, что учетная запись компьютера или пользователя, которую настраивали для подключения, не имеет прав для подключения к компьютеру. Изменяется пользователь в следующем окне.

Ошибка 0x80338126

В этом случае либо закрыт порт/протокол на фаерволе или он указан неверный. Часть команд, которые могут помочь в диагностике.

Посмотреть, что порт открыт, на обоих компьютерах, можно с помощью следующей команды:

Test-NetConnection -ComputerName "SR1" -Port 5985

Проверим, что сервисы запущены и URL по 5985 порту принимает подключение:

Get-Service 'Winrm','Wecsvc'
netsh http show urlacl url=http://+:5985/wsman/

В некоторых случаях нужно убедиться, что WinRM принимает подключение с любых IP и вообще прослушивает 5985 порт на loopback (127.0.0.1) интерфейсе. С этим может быть связана так же ошибка с ID 10149.

winrm enumerate winrm/config/listener

Ну и самое главное, что верный порт указан в самой подписке:

Ошибка 0x138C и 5004

Если у вас добавлен пользователь "NETWORK SERVICE" и есть нужные права на канал WSMAN, то почитайте статью на сайте Microsoft (касается Windows Server 2008-2012 R2). Она основана на добавлении прав через реестр, но в моем случае, на 2019, были использованы решения описанные выше.

Работа с другими журналами приложений и служб

Журналы так же имеют свои права на чтение и запись. Некоторые приложения могут перезаписывать эти права тем самым убирая возможность чтения у служб Windows. Я лично с такой проблемой не сталкивался, но алгоритм проверки следующий...

На компьютере клиента зайдите в свойства журнала с которым у вас есть проблемы и скопируйте его полное название.

В следующей команде замените название журнала на ваше. Эта команда выведет конфигурацию журнала.

wevtutil gl /r:localhost "НазваниеЖурнала"

Если посмотреть на пример выполненной команды на скриншоте ниже, то видно, что там используется SID группы "Читатели журнала событий" ("S-1-5-32-573").

Если у вас этой записи нет, то вы можете добавить ее руками. Вам нужно будет скопировать старые разрешения и добавить их к новым SDDL. Значения, которые устанавливаются перед SID значат следующее:

0x01: Read;
0x02: Write;
0x04: Clear;
A - allow.

В примере ниже нужно заменить старые права. SDDL соответствует группе читателей событий.

wevtutil set-log "НазваниеЖурнала" /ca:СтарыеПрава(A;;0x1;;;S-1-5-32-573)

Пример с добавлением SDDL для примера.

Такие же изменения можно посмотреть и увидеть в реестре по пути "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Название журнала".

Эти же права можно выдать через политики и они так же могут перезатирать существующие значения:

Computer Configuration - Policies - Administrative Templates - Windows Components - Event Log Service;
Конфигурация компьютера - Политики - Административные шаблоны - Компоненты Windows - Службы журнала событий.