Windows Event Collector

You can subscribe to receive and store events on a local computer (event collector) that are forwarded from a remote computer (event source). The Windows Event Collector functions support subscribing to events by using the WS-Management protocol. For more information about WS-Management, see About Windows Remote Management.

Event Forwarding and Event Collection Architecture

Event collection allows administrators to get events from remote computers and store them in a local event log on the collector computer. The destination log path for the events is a property of the subscription. All data in the forwarded event is saved in the collector computer event log (none of the information is lost). Additional information related to the event forwarding is also added to the event. For more information about how to enable a computer to receive collected events or forward events, see Configure Computers to Forward and Collect Events.

Subscriptions

The following list describes the types of event subscriptions:

• Source-initiated subscriptions: allows you to define an event subscription on an event collector computer without defining the event source computers. Multiple remote event source computers can then be set up (using a group policy setting) to forward events to the event collector computer. For more information, see Setting up a Source Initiated Subscription. This subscription type is useful when you do not know or you do not want to specify all the event sources computers that will forward events.
• Collector-initiated subscriptions: allows you to create an event subscription if you know all the event source computers that will forward events. You specify all the event sources at the time the subscription is created. For more information, see Creating a Collector Initiated Subscription.

Windows Event Collector Functions

For more information and code examples that use the Event Collector functions, see Using Windows Event Collector.

For more information about the functions used to collect and forward events, see Windows Event Collector functions.

Централизованный сбор логов в Windows с разных компьютеров штатными средствами

А вы в курсе, что в винде, начиная с 2008R2 есть замечательная возможность – собирать логи с разных компьютеров в сети, в одном месте? Эта функция называется Windows Event Forwarding. Сегодня покажу как её настроить.

Настраивать функцию можно двумя способами.

Collector Initiated – это когда сервер, на который должны поступать все записи о событиях сам шлет запросы на машины в сети, и получает с них логи.

Source initiated – когда, компьютеры сами стучаться на сборщик и отправляют ему информацию. Настройка тут производится посредством GPO, где указывается адрес сборщика событий.

Я покажу как собирать логи на примере Collector Initiated.

Первым делом, необходимо настроить машины, с которых нужно собирать логи.

Для этого на них должно быть включено удаленное управление, или другими словами – должен быть настроен winrm. Чтобы его настроить необходимо выполнить команду от имени администратора:

Либо можно воспользоваться powershell

Дальше необходимо добавить учетную запись пользователя, или компьютера, на который будут отправляться логи (если вы по какой-то причине не захотите указывать при настройке учетную запись пользователя) в группу Event Log Readers. Но, в некоторых случаях членства в данной группе может быть недостаточно, тогда придется добавлять учетки в группу администратора.

Также если вы хотите собирать журналы безопасности, тогда придется учетной записи Network Service дать право на их чтение. Сделать это можно командой:

Тут все указанные SIDы – стандартные, мы добавляем запись (A;;0x1;;;S-1-5-20).

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

Если у вас много компьютеров, тогда процесс выдачи прав можно сильно упростить выполнив команду в PowerShell:

Как вы поняли, в папке, откуда вы выполните эту команду должно быть 2 файла:

Computers.txt – список компьютеров, на которых нужно выполнить команду. Каждый – с новой строки.

Security.ps1 – тут только наша команда — wevtutil set-log security /ca:O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

На этом настройка отдающих – завершена. Переходим к настройке сервера, где всё будет храниться.

Первым делом включим службу Windows Event Collector, для этого, от имени администратора выполним:

В оснастке службы должна будет появиться данная служба, с типом запуска Delayed Start.

Следующим шагом укажем физическое расположение файла журнала, т.к. если вы задумались о централизованном сборе логов, то их наверняка у вас будет не мало. По этому, лучше под это мероприятие выделить отдельный диск, на который и будут писаться события. Также лучше бы его ограничить по размеру, к примеру 2ГБ, что бы логами можно было относительно комфортно пользоваться.

Запускаем оснастку просмотр событий – eventvwr.msc, windows logs, правой кнопкой по Forwarded Events. И ограничиваем размер, чтобы логи не терялись – лучше выбрать Archieve the log when full, do not owerride events. И конечно указываем путь, где файл должен лежать.

Дальше, создадим подписку – правой кнопкой по Subscriptions – Create Subscription

Тут нужно ввести имя, выбрать лог, куда должны складываться события (по умолчанию – Forwarded Events, по этом ему мы и меняли расположение и размер).

Сразу идем в Advanced Settings и указываем пользователя, от имени которого будет действовать сборщик (если вы указывали имя компьютера ранее на клиентах, тогда этот шаг пропускаем).

Выбираем события, которые должны собираться – select events. Тут можете настроить под себя, как вам угодно. Но не стоит выбирать абсолютно всё, то есть и стандартные логи, и логи приложений, иначе практически наверняка у вас выскочит ошибка, во время сбора логов, о слишком большом запросе.

Осталось только добавить компьютеры, с которых хотим собирать информацию – select computers. После добавления каждого из компьютеров лучше сразу жать test, чтобы удостовериться, что всё будет работать как надо.

Выжидаем некоторое время, и смотрим на статус созданного коллектора. Если он активный, значит в скором времени в forwarded events начнут появляться записи.

Но на этом еще не всё. Когда к вам начнут прилетать записи, вы скорее всего увидите, что для записи отсутствуют описания. Что-то вроде:

The description for Event ID X from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Частично данную незадачу можно решить, выполнив команду:

И перезапустив службу Windows Event Collector. По умолчанию, за место events установлен RenderedText. И по умолчанию события пререндерятся на удаленных компьютерах и отправляются с локализованными строками, из-за чего есть вероятность, что события не будут распознаны. Кроме того, изменение на Events немного снизит нагрузку на сеть и компьютеры – источники.

Но и после изменения параметра /cf проблема может уйти только частично. Как правило, указанные выше записи будут появляться для каких-то костюмных служб, которых нет на сборщике, например Exchange или SharePoint или еще что-то.

В событии внизу будет указано, кто является источником сообщения, из чего можно сделать вывод – чего не хватает.

Все источники и то, на какие DLL они завязаны можно посмотреть в реестре – HKLM\SYSTEM\CurrentControlSet\services\eventlog. Тут всё разбито по логам, типа Application, System и т.п. Соответственно если нужного источника тут нет, то его необходимо экспортировать с компьютера, где он есть. Соответственно и нужные, как правило, DLLки, со словарями можно посмотреть в этих ветках реестра – это параметры, где есть file в названии. Пути до файлов, для удобства, после импорта можно менять.

Если события пишет небольшое приложение, то источников для него, скорее всего будет 1-2, и их можно спокойно перенести руками, но вот если это что крупное, например exchange, то источников там уже 147. Согласитесь, такое количество руками переносить – мазохизм. Поэтому был написан скрипт, который всё сделает за нас.

Что нужно делать:

Копируем скрипт export-log на сервер, где нужная служба есть, переходим в папку со скриптом и запускаем его от имени администратора с ключом, которым является часть имени источника событий. Например, если мы увидели в просмотре событий, что нет описаний для MSExchange Certificate, то скрипт можно запустить так:

Если источником событий является Microsoft-Sharepoint Foundation, то запустить можно с ключом sharepoint.

Скрипт создаст папку, пройдется по всем разделам eventlog, сделает дамп всех разделов, где в имени присутствует ключ, исходя из путей в параметрах скопирует в папку нужные файлы, а также создаст текстовый файл со списком сдампленных разделов.

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

Скрипт скопирует нужные файлы, импортирует записи в реестр, и изменит пути до файлов в параметрах. Я сделал, чтобы файлы копировались в папку C:\CustomEvents\[ключ], соответственно папка C:\CustomEvents\ должна существовать.

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

Во время настройки этого хозяйства я столкнулся с некоторыми неприятными моментами, оставлю описание этих моментов тут.

1. На парочке серверов были непонятки с WinRM. В диспетчере серверов статус удаленного управления был обозначен как неизвестный. При попытке выполнить winrm qc выскакивало сообщение

WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.

Error number: -2147024894 0x80070002
The system cannot find the file specified.

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

Google настойчиво предлагал добавить правила в firewall:

Но для меня это результата не дало, равно как и его включение, отключение и изменение его конфигурации.

Как выяснилось, именно данная ошибка была связана с локализацией системы, на нее был установлен языковой пакет. После изменения языка системы – ошибка ушла, и команда отработала штатно, но доступа – не появилось.

Посмотрел на прослушиваемые порты командой netstat -ant — обнаружил, что порт winrm ( 5985) слушается только на адресе 127.0.0.1

показало, что iis слушает только на адресе 127.0.0.1

Помогло выполнение команд:

Вторая команда – необязательно, т.к. если в списке прослушиваемых адресов нет адресов, то прослушиваются все адреса системы.

2. Мы подцепили лог на диск iSCSI и после перезагрузки системы, данный лог стабильно отваливается. Связано это, скорее всего с тем, что после перезагрузки – iSCSI диски, либо переподключаются, либо изначально долго подключаются, и всё это происходит уже после запуска службы event log. Тут помогло указание в свойствах неправильного пути до лога, и когда система ругнется, что путь не верен – нужно указать верный путь, тогда файл подцепится.

Я добавил в планировщик заданий, на событие start up — простенький файл содержащий следующие строчки:

Сбор данных о загрузочных событиях Windows Server 2016

В Windows Server 2016 есть не особенно известная функция «Сбор данных о настройках и загрузочных событиях». Она позволяет удаленно собирать информацию о событиях, произошедших в процессе загрузки системы. Такая возможность особенно полезна при поиске «плавающих» проблем во время загрузки ОС.

В статье я расскажу, как можно удобно собирать эти недостающие сведения.

Ниже приводятся типы событий, информацию о которых можно узнать с помощью функции «Сбор данных о настройках и загрузочных событиях»:

1. Загрузка модулей ядра и драйверов.
2. Перечисление устройств и инициализация их драйверов.
3. Верификация и установка файловых систем.
4. Запуск исполняемых файлов.
5. Запуск и завершение обновлений системы.

После сбора всех необходимых данных о событиях на сервере-сборщике для их анализа можно использовать хорошо знакомые инструменты – Event Viewer, Wevutil или PowerShell.

Далее мы рассмотрим, как настроить сервер и удаленные узлы для сбора данных.

Поддерживаемые ОС

Роль сборщика может выполнять исключительно Windows Server 2016 – это может быть либо сервер с возможностями рабочего стола, либо Server Core.

Ниже приведена таблица с интернет-ресурса TechNet, в которой показаны поддерживаемые виртуализованные типы ОС для сборщиков и целевых компьютеров:

Узел виртуализации	Виртуальная машина-сборщик	Целевая виртуальная машина
Windows 8.1	да	да
Windows 10	да	да
Windows Server 2016	да	да
Windows Server 2012 R2	да	нет

На серверы, с которых вы хотите собирать данные, должна быть установлена или Windows Server 2016, или Windows 10. Кроме того, в качестве целевого узла может выступать компьютер с Nano Server. Также можно собирать данные из окон системы Windows Server 2016, даже если они работают как виртуальная машина на компьютерах с Windows Server 2012 R2.

Конфигурация узла сборщика

Для получения и отображения ETL-событий с целевых компьютеров необходимо настроить узел сборщика. Первое – необходимо подключить службу сбора событий, используя один из нижеуказанных методов.

При помощи DISM:

Также можно установить этот компонент с помощью Server Manager GUI:

Установка службы с помощью диспетчера сервера.

После установки службы сбора событий вы получите доступ к новой службе – Boot Event Collector, запущенной под учетной записью Network Service.

Свойства Boot Event Collector.

Существует также инструмент командной строки bevtcol.exe, который можно запустить с некоторыми полезными параметрами. Он поможет протестировать ваши настройки перед установкой полного сервиса.

Параметры bevtcol.exe.

Например, можно запустить bevtcol.exe – config NewConfig.xml – checkOnly только для проверки правильности файла конфигурации. И потом выйти без запуска самого процесса.

Затем вам нужно проверить, были ли созданы файлы конфигурации по умолчанию на узле сборщика – это поможет вам создать свой первый файл конфигурации компьютера-сборщика.

В папке C:\ProgramData\Microsoft\BootEventCollector\Config, вы увидите три XML файла конфигурации, созданные сразу после установки сервиса.

Файлы конфигурации XML.

Active.xm содержит аналогичную Empty.xml конфигурацию. Каждая новая конфигурация должна быть сохранена в этом файле:

• Empty.xml – содержит минимально необходимые элементы конфигурации, с установленными по умолчанию значениями;
• Example.xml – содержит полезные примеры конфигураций.

*XML-файл с пример*ом конфигурации.

Если взглянуть на структуру папки С:\ProgramData\Microsoft\BootEventCollector, можно увидеть, что разные папки созданы для разных целей:

• ETL – это каталог для хранения собранных ETL-файлов;
• Logs, как следует из названия, хранят log-файлы для службы сбора.

ETL and log file folders.

Теперь мы можем создать наш первый файл конфигурации. Создайте новый XML-файл в каталоге %SystemDrive%\ProgramData\Microsoft\BootEventCollector\Config и скопируйте содержимое конфигурации, указанной ниже, в .xml-файл.

В файле конфигурации есть несколько важных моментов.

Во-первых, Collector – в этом узле мы указали версию файла конфигурации и имя log-файла.

Во-вторых, collectorport – указывает номер порта для сбора входящих событий. Нам также необходимо настроить один и тот же номер порта на целевых компьютерах.

В третьих, forwarder – здесь мы указываем характеристики ETL-файлов. Эти характеристики могут быть следующими:

1. File определяет шаблон имени файла. <# 3>– это трехзначный индекс файла при обращении, такой как 001, 002 и т.д. используется для обозначения имени компьютера. Таким образом, в нашем примере файлы будут собраны в папке Etl\COMPUTERNAME\ с именем COMPUTERNAME_00x.

2. Size определяет максимальный размер ETL-файла.

3. Nfiles определяет количество созданных ETL-файлов в обращении. Каждый новый файл создается, как только размер предыдущего достигает ограничения, определенного параметром Size.

4. ToXML — опциональный параметр, определяющий полезную нагрузку, с которой ETW-события во время пересылки преобразуются в XML. None — это значение, установленное по умолчанию. Оно всегда пересылает события в двоичном формате по мере их получения. Если вы установите значение «ALL», полезная нагрузка будет постоянно преобразовываться в XML.

Этот параметр на самом деле является своего рода защитой, поскольку события ETW были разработаны для их интерпретации компьютерами, на которых они и были сгенерированы.

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

В четвертых, target – здесь можно указать настройки целевого узла. Например, IP-адрес, MAC-адрес или GUID, чтобы настроить компьютеры для приема подключений. Также можно указать anyAllowed, чтобы принимать все подключения.

Вы можете указать несколько целевых компьютеров, добавив дополнительные target-узлы:

• в описанном выше случае, указаны два целевых компьютера: один с IP-адресом и один с MAC-адресом;
• Key – это ключи шифрования, которые мы собираемся получить позже, при настройке целевых компьютеров;
• Computer value – это имя целевого компьютера, который должен быть занесен в ETW-записи, когда они преобразуются в XML.

После того, как вы закончите с файлом конфигурации, сохраните его и настройте целевой узел.

Настройка целевого компьютера

Чтобы настроить целевые компьютеры для отправки ETW-событий, необходимо активировать передачу событий. Вы можете активировать ее локально с помощью команды bcdedit или удаленно с помощью команды PowerShell Remote и Enable-SbecBcd.

В моей лаборатории у меня есть доступ к моим целевым компьютерам, поэтому я буду использовать bcdedit:

• HostIP – это имя компьютера-коллектора, которое мы конфигурировали ранее;
• Port – это номер порта, который мы указали в файле конфигурации;
• Key – это ключ шифрования, который нам нужно указать в файле конфигурации.

Активация передачи событий через команду bcdedit.

Я настроил ключи шифрования. Вы можете проверить конфигурацию с помощью следующей команды bcdedit:

Проверка конфигурации события BCD.

Теперь я могу вернуться к моему серверу и применить новый файл конфигурации, который я создал ранее, с указанными ключами. Set-SbecActiveConfig cmdlet нам в этом поможет:

Применение файла конфигурации на компьютере-сборщике.

Получение принятой конфигурации.

И наконец последний шаг – настройка целевых компьютеров для отправки ETW-событий.

На сервере выполните следующую команду:

Настройка целевого компьютера для отправки ETW-событий.

На сервере файл конфигурации active.xml обновился с моими настройками.

Обновленный файл active.xml.

Также был создан новый log-статус:

Обновленный log-файл.

Кроме того, создается новый ETL-файл, который уже может собирать информацию о настройках и загрузочных событиях с целевого компьютера (Server01). После перезапуска одного из ваших серверов, в нем появится информация:

Собранные ETL-файлы.

Теперь можно открыть собранные ETL-файлы в инструменте просмотра событий Windows:

События, собранные после первой перезагрузки целевого компьютера.

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