Где хранятся логи в windows server

Posted by
on September 27, 2016

Обновлено 23.03.2022

Всем привет, тема стать как посмотреть логи windows. Что такое логи думаю знают все, но если вдруг вы новичок, то логи это системные события происходящие в операционной системе как Windows так и Linux, которые помогают отследить, что, где и когда происходило и кто это сделал. Любой системный администратор обязан уметь читать логи windows.

Примером из жизни может служить ситуация когда на одном из серверов IBM, выходил из строя диск и для технической поддержки я собирал логи сервера, для того чтобы они могли диагностировать проблему. За собирание и фиксирование логов в Windows отвечает служба Просмотр событий. Просмотр событий это удобная оснастка для получения логов системы.

Как открыть в просмотр событий

Зайти в оснастку Просмотр событий можно очень просто, подойдет для любой версии Windows. Нажимаете волшебные кнопки

Откроется у вас окно просмотр событий windows в котором вам нужно развернуть пункт Журналы Windows. Пробежимся по каждому из журналов.

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

Журнал аудит, нужен для понимания кто и когда что сделал. Например вошел в систему или вышел, попытался получить доступ. Все аудиты успеха или отказа пишутся сюда.

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

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

Так же есть логи windows для более специфических служб, например DHCP или DNS. Просмотр событий сечет все :).

Фильтрация в просмотре событий

Предположим у вас в журнале Безопасность более миллиона событий, наверняка вы сразу зададите вопрос есть ли фильтрация, так как просматривать все из них это мазохизм. В просмотре событий это предусмотрели, логи windows можно удобно отсеять оставив только нужное. Справа в области Действия есть кнопка Фильтр текущего журнала.

Вас попросят указать уровень событий:

• Критическое
• Ошибка
• Предупреждение
• Сведения
• Подробности

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

Так что как видите разобрать логи windows очень просто, ищем, находим, решаем. Так же может быть полезным быстрая очистка логов windows:

• Как очистить просмотр событий с помощью PowerShell
• Как почистить все журналы windows с помощью скрипта

Посмотреть логи windows PowerShell

Было бы странно если бы PowerShell не умел этого делать, для отображения log файлов открываем PowerShell и вводим вот такую команду

В итоге вы получите список логов журнала Система

Тоже самое можно делать и для других журналов например Приложения

небольшой список абревиатур

• Код события — EventID
• Компьютер — MachineName
• Порядковый номер события — Data, Index
• Категория задач — Category
• Код категории — CategoryNumber
• Уровень — EntryType
• Сообщение события — Message
• Источник — Source
• Дата генерации события — ReplacementString, InstanceID, TimeGenerated
• Дата записи события — TimeWritten
• Пользователь — UserName
• Сайт — Site
• Подразделение — Conteiner

Например, для того чтобы в командной оболочке вывести события только со столбцами «Уровень», «Дата записи события», «Источник», «Код события», «Категория» и «Сообщение события» для журнала «Система», выполним команду:

Если нужно вывести более подробно, то заменим Format-Table на Format-List

Как видите формат уже более читабельный.

Так же можно пофильтровать журналы например показать последние 20 сообщений

Или выдать список сообщение позднее  1 ноября 2014

Дополнительные продукты

Так же вы можете автоматизировать сбор событий, через такие инструменты как:

• Комплекс мониторинга Zabbix
• Через пересылку событий средствами Windows на сервер коллектор
• Через комплекс аудита Netwrix
• Если у вас есть SCOM, то он может агрегировать любые логи Windows платформ
• Любые DLP системы

Так что вам выбирать будь то просмотр событий или PowerShell для просмотра событий windows, это уже ваше дело. Материал сайта pyatilistnik.org



Удаленный просмотр логов

• Первый метод

Не так давно в появившейся операционной системе Windows Server 2019, появился компонент удаленного администрирования Windows Admin Center. Он позволяет проводить дистанционное управление компьютером или сервером, подробнее он нем я уже рассказывал. Тут я хочу показать, что поставив его себе на рабочую станцию вы можете подключаться из браузера к другим компьютерам и легко просматривать их журналы событий, тем самым изучая логи Windows. В моем примере будет сервер SVT2019S01, находим его в списке доступных и подключаемся (Напомню мы так производили удаленную настройку сети в Windows).

Далее вы выбираете вкладку «События», выбираете нужный журнал, в моем примере я хочу посмотреть все логи по системе. С моей точки зрения тут все просматривать куда удобнее, чем из просмотра событий. Плюсом будет, то что вы это можете сделать из любого телефона или планшета. В правом углу есть удобная форма поиска

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

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

Вот пример фильтрации по событию 19.

Очень удобно экспортировать полностью журнал в формат evxt, который потом легко открыть через журнал событий. Так, что Windows Admin Center, это мощное средство по просмотру логов.

• Второй метод

Второй способ удаленного просмотров логов Windows, это использование оснастки управление компьютером или все той же «Просмотр событий». Чтобы посмотреть логи Windows на другом компьютере или сервере, в оснастке щелкните по верхнему пункту правым кликом и выберите из контекстного меню «Подключиться к другому компьютеру«.

Указываем имя другого компьютера, в моем примере это будет SVT2019S01

Если все хорошо и нет блокировок со стороны брандмауэра или антивируса, то вы попадете в удаленный просмотр событий .если будут блокировки, то получите сообщение по типу, что не пролетает трафик COM+.

Так же хочу отметить, что есть целые системы агрегации логов, такие как Zabbix или SCOM, но это уже другой уровень задач. На этом у меня все, с вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

findstr "Fail" *.log >> fail.txt

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Get-Content -Path 'C:Program FilesUpdate ServicesLogFilesSoftwareDistribution.log' | Out-Host -Paging

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

>Get-Content -Path "C:WindowsWindowsUpdate.log" -Tail 5 -Wait

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Select-String -Path "C:WindowsSystem32LogFilesFirewallpfirewall.log" -Pattern 'Drop' | Select-Object -Last 20 | Format-Table Line

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

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Select-String 'C:WindowsClusterReportsCluster.log' -Pattern ' err ' ‑Context 3

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Get-Content 'C:Windowsdebugnetlogon.log' | Select-Object -First 30 -Skip 45

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

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

Get-WinEvent -ListLog *

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Get-WinEvent -LogName 'System' -MaxEvents 20

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

Get-WinEvent -FilterHashTable @{LogName='System';ID='1','6013'}

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Get-WinEvent -FilterHashtable @{LogName='system'} | Where-Object -FilterScript {($_.Level -eq 2) -or ($_.Level -eq 3)}

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

• Get-EventLog.
• Get-WinEvent.

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

SELECT 
 extract_token(text, 0, ' ') as date, 
 extract_token(text, 1, ' ') as time,
 extract_token(text, 2, ' ') as action, 
 extract_token(text, 4, ' ') as src-ip,  
 extract_token(text, 7, ' ') as port 
FROM 'C:WindowsSystem32LogFilesFirewallpfirewall.log' 
WHERE action='DROP' AND port='3389'
ORDER BY date,time DESC

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManagerOperational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%System32WinevtLogsMicrosoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%test.evtx.

Данные будем получать таким запросом:

SELECT
 timegenerated as Date, 
 extract_token(strings, 0, '|') as user,
 extract_token(strings, 2, '|') as sourceip 
FROM '%temp%test.evtx'
WHERE EventID = 21
ORDER BY Date DESC

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

SELECT
 TO_LOCALTIME(TO_TIMESTAMP(EXTRACT_PREFIX(TO_STRING([#Fields: date-time]),0,'T'), 'yyyy-MM-dd')) AS Date,
 COUNT(*) AS [Daily Email Traffic] 
FROM 'C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsMessageTracking*.LOG'
WHERE (event-id='RECEIVE') GROUP BY Date ORDER BY Date ASC

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

$LogQuery = New-Object -ComObject "MSUtil.LogQuery"
$InputFormat = New-Object -ComObject "MSUtil.LogQuery.FileSystemInputFormat"
$InputFormat.Recurse = -1
$OutputFormat = New-Object -ComObject "MSUtil.LogQuery.CSVOutputFormat"
$SQLQuery = "SELECT Top 20 Path, Size INTO '%temp%output.csv' FROM 'C:*.*' ORDER BY Size DESC"
$LogQuery.ExecuteBatch($SQLQuery, $InputFormat, $OutputFormat)
$CSV = Import-Csv  $env:TEMP'output.csv'
$CSV | fl 
Remove-Item $env:TEMP'output.csv'
$LogQuery=$null
$InputFormat=$null
$OutputFormat=$null

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

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

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.

В работе системного администратора, нередко возникает необходимость посмотреть логи сервера (Server Logs), с какими задачами работал сервер в конкретное время, какие действия совершали пользователи. Причины возникновения этой необходимости могут быть разные:

• Сбой в работе сервера;
• Выявление неблагонамеренных действий;
• Анализ рабочих процессов.

Всю необходимую информацию можно получить в логи сервера (Server Logs), то есть файлах, в которые вносятся записи о различных процессах, действиях пользователей, и т.п. Но, для этого необходимо понимать, где хранятся эти данные, а главное, как с ними работать.

Что такое логи сервера?

Собственно говоря, само слово «логи сервера», является банальной транслитерацией, от словосочетания «server log», которое переводится как «журнал сервера».

Существуют следующие типы логов:

• Ошибки – записи, фиксирующие различные сбои в работе сервера, или при обращении к конкретным функциям или задачам. С их помощью можно быстро ликвидировать разные баги и сбои;
• Доступ – записи, которые фиксируют точные дату и время подключения конкретного пользователя, каким образом он попал на сайт, и т.д. Позволяют проводить аналитическую работу, а также находить уязвимые места, в тех случаях, когда ресурс пытались взломать;
• Прочее – записи с данными о работе разных компонентов сервера, например, почты.

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

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

Тем не менее, для большинства рядовых пользователей записи в log-файлах, представляют собой просто странный набор символов. А значит, нужно понять, как правильно их читать.

Как правильно читать логи сервера?

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

Итак, запись лога доступа, из файла access.log:

mysite.biz 25.34.94.132 — — [21/Nov/2017:03:21:08 +0200] «GET /blog/2/ HTTP/1.0» 200 18432 «-» «Unknow Bot (http://www.unknow.com/bot; [email protected])»

Что она обозначает:

• mysite.biz – домен сайта, которым вы интересуетесь;
• 34.94.132 – IP-адрес, который использовал пользователь при заходе на сайт;
• [21/Nov/2017:03:21:08 +0200] – дата, точное время и часовой пояс пользователя;
• GET – запрос, который отправляется для получения данных. В том случае, если пользователь передает данные, запрос будет «POST»;
• /blog/2/ — относительный адрес страницы, к которой был обращен запрос;
• HTTP/1.0 – используемый протокол;
• 200 – код ответа на запрос;
• 18432 – количество данных, переданных по запросу, в байтах;
• Unknow Bot (http://www.unknow.com/bot; [email protected]) – данные о роботе, или реальном человеке, который зашел на сайт. В том случае, если это человек, будет отображена ОС, тип устройства и т.д. В конкретном примере на сайт зашел робот-парсер, принадлежащий ресурсу unknow.com.

Таким образом, мы узнали, что с IP-адреса 25.34.94.132, двадцать первого ноября, 2017-го года, в три часа, двадцать одну минуту и восемь секунд, на наш сайт заходил бот, принадлежащий другому веб-ресурсу. Он отправил запрос на получение данных, и получил 18432 байт информации.

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

Логи ошибок, можно посмотреть в файле с говорящим именем – error.log. Они выглядят следующим образом:

[Sat Oct 1 18:23:28.719615 2019] [:error] [pid 10706] [client 44.248.44.22:35877]

PHP Notice: Undefined variable: moduleclass_sfx in

/var/data/www/mysite.biz/modules/contacts/default.php on line 13

Что здесь написано?

1. Дата, время и тип ошибки, а также IP-адрес, который использовал посетитель;
2. Тип события, в данном случае – «PHP Notice» (уведомление), а также уточнение, что в данном случае, мы имеем дело с неизвестной переменной;
3. Местоположение файла с уведомлением, а также строка, на которой оно находится.

Если говорить просто, то в данном случае мы имеем сообщение о том, что первого октября, в 18:23, 2019-го года, произошла ошибка, связанная с модулем контактов.

Разумеется, даже после расшифровки, полученные данные не так просто проанализировать. Именно поэтому, для удобной обработки данных из логов сервера, используется различное программное обеспечение. К таким программам относятся: Awstats, Webtrends, WebAlyzer, и многие другие.

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

Логи серверов на Windows

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

Существует несколько уровней событий:

• Подробности;
• Сведения;
• Предупреждение;
• Ошибка;
• Критический.

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

Логи SQL сервера

На сегодняшний день, базы данных SQL, являются наиболее распространенным способом работы с большими объемами информации. В первую очередь, логи sql сервера, стоит изучить, если вы не уверены в том, что какие-то процессы были успешно завершены. Этими процессами могут быть:

• Резервное копирование;
• Восстановление данных;
• Массовые изменения;
• Различные скрипты, и программы для обработки данных.

Для того, чтобы просмотреть записи в логах, можно использовать SQL Server Management Studio, либо другой, удобный вам редактор текстов. Записи распределены по журналам следующих типов:

• Сбор данных;
• Database Mail;
• SQL Сервер;
• События Windows;
• Журнал заданий;
• Коллекция аудита;
• SQL Сервер, агент.

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

Как включить или выключить запись логов сервера?

Для того, чтобы осуществить эту операцию, нужно зайти в административную панель вашего хостера. Как правило, в основном меню есть раздел «Журнал», или «Логи», в котором можно включить или выключить запись данных о предоставленном доступе, ошибках, и т.п.

Где находятся логи сервера?

Расположение журналов, зависит в первую очередь от используемой вами операционной системы.

Логи серверов с CentOS, или Fedora, хранятся в дирректории «/var/log/».

Названия файлов:

• Журнал ошибок – «error.log»;
• Журнал nginx – «nginx»;
• Журнал доступов – «log»;
• Основной журнал – «syslog»;
• Журнал загрузки системы – «dmesg».

Логи ошибок, связанных с работой MySQL, находятся в директории «/var/lib/mysql/», в файле «$hostname.err».

Для операционных систем Debian и Ubuntu, логи сервера располагаются в папке «/var/log/», в файлах:

• Nginx — журнал nginx;
• /mysql/error.log – журнал ошибок для баз данных MySQL;
• Syslog – основной журнал;
• Dmesg – загрузка системы, драйвера;
• Apache2 – журнал веб-сервера Apache.

Как видите, у всех ОС, основанных на Linux, логи сервера, как правило имеют одинаковые названия, и директории.

С логами для Windows server, дело обстоит несколько иначе. Если нужно просмотреть журналы, необходимо войти в систему, нажать клавиши «Win» и «R», после чего откроется окно просмотра событий, где есть возможность подобрать интересующие нас логи.

Если вы хотите посмотреть логи PowerShell, то необходимо открыть программу и ввести команду: «Get-EventLog -Logname ‘System’».

Все данные будут выведены в виде удобной таблицы.

Пример работы с логами сервера

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

Можно потратить много времени на выяснения причины, а можно просто посмотреть логи доступа и проверить, с каких IP, и кто заходил на ваш сайт, в выбранные промежуток времени. Вполне вероятно, что вы обнаружите большое количество переходов с нескольких IP-адресов, которые делались автоматически, то есть ваш сайт попал под DDoS-атаку.

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

Вывод

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

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

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

У систем, основанных на Linux, как правило примерно одинаковое расположение файлов с логами, что существенно упрощает работу с ними.

У Windows Server, есть свой собственный графический интерфейс для чтения логов, который весьма удобен, и позволяет быстро получить необходимую информацию.

Загрузка…

При отладке работы клиента Windows Update в Windows Server 2016 одним из ключевых источников получения информации является лог, который ведёт системная служба «Windows Update«. В отличие от предыдущих версий Windows Server, где этот лог имел простой текстовый формат и мог быть прочитан любым текстовым редактором, в Windows Server 2016, как и в Windows 10, прежний текстовый формат лога сменился на бинарный формат Event Trace Log (ETL) механизма Event Tracing for Windows (ETW). Соответственно, для извлечения информации из такого лога требуются дополнительные инструменты типа специализированного командлета PowerShell. А в случае, если диагностируемая серверная система имеет ограниченный доступ в Интернет, то с получением читаемого формата данных ETL у нас могут возникнуть проблемы. Рассмотрим такую проблемную ситуацию и способ её решения.

Итак, при открытии лог-файла C:WindowsWindowsUpdate.log, который исторически использовался администраторами в предыдущих версиях ОС Windows Server, мы увидим в этом файле сообщение, говорящее о смене формата лога и необходимости использовать PS-командлет Get-WindowsUpdateLog:

Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.

For more information, please visit http://go.microsoft.com/fwlink/?LinkId=518345

При вызове командлета Get-WindowsUpdateLog без указания дополнительных параметров из множества лог-файлов с расширением *.etl, хранящихся в каталоге C:WindowsLogsWindowsUpdate будет сформирован читаемый текстовый лог-файл WindowsUpdate.log на рабочий стол текущего пользователя, запустившего командлет.

Однако, открыв этот файл, вместо читаемых событий мы можем увидеть нераспознанные записи с разными идентификаторами следующего вида:

...
1601.01.01 03:00:00.0000000 1352  1784  Unknown( 10): GUID=d1317ae8-ec05-3e09-4a50-d3b2ce02f784 (No Format Information found).
1601.01.01 03:00:00.0000000 1352  1784  Unknown( 10): GUID=d1317ae8-ec05-3e09-4a50-d3b2ce02f784 (No Format Information found).
1601.01.01 03:00:00.0000000 1352  1784  Unknown( 63): GUID=e26dfe10-35bf-3106-db9d-9a51a6a0981f (No Format Information found).
1601.01.01 03:00:00.0000000 1352  1784  Unknown( 30): GUID=018fc11d-8257-3169-8741-635574c6ffe0 (No Format Information found).
...

Данная проблема связана с отсутствием доступа к Интернет-сервису, предоставляющему по HTTP-запросу актуальные версии символов отладки (Microsoft Internet Symbol Server), которые используются для интерпретации при обработке ETL-логов.

Такое поведение командлета Get-WindowsUpdateLog имеет место быть на Windows 10 версий до 1709 (OS Build 16299), в том числе и на Windows Server 2016, который относится к версии 1607 (OS Build 14393).
Об этом указано в описании к самому командлету.

В качестве самого простого решения данной проблемы может быть открытие прямого доступа к Интернет-узлу msdl.microsoft.com на пограничном шлюзе или прокси-сервере предприятия. Однако, в некоторых случаях, исходя из требований ИБ, такой доступ открыть не представляется возможным. Как же прочитать логи в таком случае?

В качестве одного из вариантов решения может быть обработка логов на другой машине, имеющей доступ в Интернет. Для этого скопируем *.etl логи на систему Windows 10 или Windows Server 2016, имеющую доступ в Интернет, например во временный каталог C:TempWindowsUpdate и выполним обработку копии логов:

Get-WindowsUpdateLog -ETLPath "C:TempWindowsUpdate" -LogPath "C:TempWU.log"

Либо, без предварительного копирования можем сразу попробовать обработать логи прямо с удалённой машины:

Get-WindowsUpdateLog -ETLPath "\WS2016srvC$WindowsLogsWindowsUpdate" -LogPath "C:TempWU.log"

Однако, при попытке получить читаемый лог, извлечённый с Windows Server 2016 1607 (14393), например, на более новой системе Windows 10 21H2 (19044) мы можем получить примерно следующий результат:

...
2022.04.05 19:44:14.5857095 1352  2928  Unknown         Unknown
2022.04.05 19:44:14.5857173 1352  2928  Unknown         Unknown
2022.04.05 19:44:15.5861231 1352  1784  Unknown         Unknown
2022.04.05 19:44:15.5861305 1352  1784  Unknown         Unknown
2022.04.05 19:44:15.5882899 1352  1784  Unknown         Unknown
...

При этом свои логи Windows Update с помощью командлета Get-WindowsUpdateLog на этой же системе с Windows 10 21H2 могут формироваться без каких-либо проблем.

Как я понимаю, связано это с тем, что для формирования читаемого лога с Windows Server 2016 1607 нам потребуется иметь символьный кеш, совместимый именно с этой версией ОС.

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

• Сформировать символьный кеш на серверной системе нужной версии, выпустив на время её в Интернет (или только конкретно к узлу msdl.microsoft.com) и выполнив командлет Get-WindowsUpdateLog;
• Скопировать полученный символьный кеш в общедоступный сетевой каталог и использовать его в дальнейшем в качестве локального источника при работе с других серверов, отключенных от Интернет.

Итак, предоставляем на время какому-либо серверу с аналогичной версией ОС (Windows Server 2016 1607) прямой доступ в Интернет и выполняем на этом сервере командлет Get-WindowsUpdateLog. В ходе выполнения команды сервер подключится к интернет узлу msdl.microsoft.com и наполнит символьный кеш в каталоге:

%temp%WindowsUpdateLogSymCache.

То есть, с точки зрения текущего пользователя, который выполняет командлет, путь может иметь вид типа C:Users{Username}AppDataLocalTempWindowsUpdateLogSymCache

В нашем примере в каталог символьного кеша было загружено около 14 MB контента.

Копируем всё содержимое каталога в отдельную сетевую шару, которую в дальнейшем можно будет использовать в качестве источника символьного кеша для всех серверов с аналогичной версией ОС и не имеющих доступа в Интернет.

После этого на сервере, не имеющем доступа в Интернет, выполняем команду формирования читаемого лога с использованием символьного кеша из сетевой шары:

Get-WindowsUpdateLog -SymbolServer "\FileSrvWS2016WUSymCache"

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

Получить больше информации о логах, относящихся к работе Windows Update, в том числе и о структуре этих логов, можно из документа «Microsoft Docs : Windows — Deployment — Windows Update log files».

Обратите внимание также на то, что при отладке работы клиента Windows Update в Windows Server 2016 перед погружением в вышеописанный ETL-лог для первичного анализа ситуации могут пригодится журналы Event Viewer, которые можно найти в разделе Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient.

---

Дополнительные источники информации:

• Microsoft Docs : Offline Symbols for Windows Update — Windows drivers
• TechNet Forums : Windows Update Logs are not generated properly for Windows Server 2016 build 1607

В этой статье мы рассмотрим, как получить и проанализировать логи RDP подключений в Windows. Логи RDP подключений позволяют администраторам терминальных RDS серверов/ферм получить информацию о том, какие пользователи подключались к серверу, когда был выполнен вход и когда сеанс завершен, с какого устройства (имя или IP адрес) подключался пользователь.

Описанные методики получения и исследования RDP логов применима как к Windows Server 2022/2019/2016/2012R2, так и для десктопных версий Windows 11, 10, 8.1 c.

События RDP подключений в журналах Windows (Event Viewer)

Когда пользователь удаленно подключается к RDS серверу или удаленному столу Windows (RDP), информация об этих событиях сохраняется в журналы Windows. Рассмотрим основные этапы RDP подключения и связанные с ними события в Event Viewer.

1. Network Connection
2. Authentication
3. Logon
4. Session Disconnect/Reconnect
5. Logoff

Network Connection: – событие установления сетевого подключение к серверу от RDP клиента пользователя. Событие с EventID – 1149 (Remote Desktop Services: User authentication succeeded). Наличие этого события не свидетельствует об успешной аутентификации пользователя. Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> Terminal-Services-RemoteConnectionManager -> Operational. Включите фильтр по данному событию (ПКМ по журналу-> Filter Current Log -> EventId 1149).

С помощью PowerShell можно вывести список всех попыток RDP подключений:

$RDPAuths = Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -FilterXPath '<QueryList><Query Id="0"><Select>*[System[EventID=1149]]</Select></Query></QueryList>'
[xml[]]$xml=$RDPAuths|Foreach{$_.ToXml()}
$EventData = Foreach ($event in $xml.Event)
{ New-Object PSObject -Property @{
TimeCreated = (Get-Date ($event.System.TimeCreated.SystemTime) -Format 'yyyy-MM-dd hh:mm:ss K')
User = $event.UserData.EventXML.Param1
Domain = $event.UserData.EventXML.Param2
Client = $event.UserData.EventXML.Param3
}
} $EventData | FT

В результате у вас получится список с историей всех сетевых RDP подключений к данному серверу. В событии содержится имя пользователя, домен (если используется NLA аутентификация, при отключенном NLA текст события выглядит иначе) и IP адрес компьютера пользователя.

Authentication: – успешная или неудачная аутентификация пользователя на сервере. Журнал Windows -> Security. Здесь нас могут интересовать события с EventID – 4624 (успешная аутентификация — An account was successfully logged on) или 4625 (ошибка аутентификации — An account failed to log on). Обратите внимание на значение LogonType в событии.

• LogonType = 10 или 3 — при входе через терминальную службу RDP —.
• LogonType = 7, значит выполнено переподключение к уже существующему RDP сеансу.
• LogonType = 5 – событие RDP подключения к консоли сервера (в режиме mstsc.exe /admin)

Вы можете использовать события с ошибками аутентификации для защиты от удаленного перебора паролей через RDP. СВы можете автоматически блокировать на файерволе IP адреса, с которых выполняется подбор пароля, простым PowerShell скриптом (см. статью).

При этом имя пользователя содержится в описании события в поле Account Name, имя компьютера в Workstation Name, а имя пользователя в Source Network Address.

Обратите внимание на значение поля LogonID – это уникальный идентификатор сессии пользователя, с помощью которого можно отслеживать дальнейшую активность данного пользователя. Но при отключении от RDP сессии (disconnect) и повторного переподключения к той же сессии, пользователю будет выдан новый TargetLogonID (хотя RDP сессия осталась той же самой).

Вы можете получить список событий успешных авторизаций по RDP (событие 4624) с помощью такой команды PowerShell.

Get-EventLog security -after (Get-date -hour 0 -minute 0 -second 0) | ?{$_.eventid -eq 4624 -and $_.Message -match 'logon type:s+(10)s'} | Out-GridView

Logon: – RDP вход в систему, EventID – 21 (Remote Desktop Services: Session logon succeeded. Это событие появляется после успешной аутентификации пользователя. Этот журнал находится в разделе Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Как вы видите, здесь можно узнать идентификатор RDP сессии для пользователя — Session ID.

Событие с EventID – 21 (Remote Desktop Services: Shell start notification received) означает успешный запуск оболочки Explorer (появление окна рабочего стола в RDP сессии).

Session Disconnect/Reconnect – события отключения и переподключения к сессии имеют разные коды в зависимости от того, что вызвало отключение пользователя (отключение по неактивности, заданному в таймаутах для RDP сессий; выбор пункта Disconnect в сессии; завершение RDP сессии другим пользователем или администратором и т.д.). Эти события находятся в разделе журналов Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational. Рассмотрим RDP события, которые могут быть полезными:

• EventID – 24 (Remote Desktop Services: Session has been disconnected) – пользователь отключился от RDP сессии.
• EventID – 25 (Remote Desktop Services: Session reconnection succeeded) – пользователь переподключился к своей имеющейся RDP сессии на сервере.
• EventID – 39 (Session <A> has been disconnected by session <B>) – пользователь сам отключился от своей RDP сессии, выбрав соответствующий пункт меню (а не просто закрыл окно RDP клиента). Если идентификаторы сессий разные, значит пользователя отключил другой пользователь (или администратор).
• EventID – 40 (Session <A> has been disconnected, reason code <B>). Здесь нужно смотреть на код причины отключения в событии. Например:
  • reason code 0 (No additional information is available) – обычно говорит о том, что пользователь просто закрыл окно RDP клиента.
  • reason code 5 (The client’s connection was replaced by another connection) – пользователь переподключился к своей старой сессии.
  • reason code 11 (User activity has initiated the disconnect) – пользователь сам нажал на кнопку Disconnect в меню.

Событие с EventID – 4778 в журнале Windows -> Security (A session was reconnected to a Window Station). Пользователь переподключился к RDP сессии (пользователю выдается новый LogonID).

Событие с EventID 4779 в журнале Windows -> Security (A session was disconnected from a Window Station). Отключение от RDP сеанса.

Logoff: – выход пользователя из системы. При этом в журнале Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational регистрируется событие с EventID 23 (Remote Desktop Services: Session logoff succeeded).

При этом в журнале Security нужно смотреть событие EventID 4634 (An account was logged off).

Событие Event 9009 (The Desktop Window Manager has exited with code (<X>) в журнале System говорит о том, что пользователь инициировал завершение RDP сессии, и окно и графический shell пользователя был завершен.

EventID 4647 — User-initiated logoff

Получаем логи RDP подключений в Windows с помощью PowerShell

Ниже представлен небольшой PowerShell скрипт, который выгружает из журналов терминального RDS сервера историю всех RDP подключений за текущий день. В полученной таблице указано время подключения, IP адрес клиента и имя пользователя (при необходимости вы можете включить в отчет другие типы входов).

Get-EventLog -LogName Security -after (Get-date -hour 0 -minute 0 -second 0)| ?{(4624,4778) -contains $_.EventID -and $_.Message -match 'logon type:s+(10)s'}| %{
(new-object -Type PSObject -Property @{
TimeGenerated = $_.TimeGenerated
ClientIP = $_.Message -replace '(?smi).*Source Network Address:s+([^s]+)s+.*','$1'
UserName = $_.Message -replace '(?smi).*ssAccount Name:s+([^s]+)s+.*','$1'
UserDomain = $_.Message -replace '(?smi).*ssAccount Domain:s+([^s]+)s+.*','$1'
LogonType = $_.Message -replace '(?smi).*Logon Type:s+([^s]+)s+.*','$1'
})
} | sort TimeGenerated -Descending | Select TimeGenerated, ClientIP `
, @{N='Username';E={'{0}{1}' -f $_.UserDomain,$_.UserName}} `
, @{N='LogType';E={
switch ($_.LogonType) {
2 {'Interactive - local logon'}
3 {'Network conection to shared folder)'}
4 {'Batch'}
5 {'Service'}
7 {'Unlock (after screensaver)'}
8 {'NetworkCleartext'}
9 {'NewCredentials (local impersonation process under existing connection)'}
10 {'RDP'}
11 {'CachedInteractive'}
default {"LogType Not Recognised: $($_.LogonType)"}
}
}}

Можно экспортировать логи RDP подключений из журнала в CSV файл (для дальнейшего анализа в таблице Excel). Экспорт журнала можно выполнить из консоли Event Viewer (при условии что логи не очищены) или через командную строку:

WEVTUtil query-events Security > c:pssecurity_log.txt

Или с помощью PowerShell:

get-winevent -logname "Microsoft-Windows-TerminalServices-LocalSessionManager/Operational" | Export-Csv c:psrdp-log.csv  -Encoding UTF8

Если ваши пользователи подключаются к RDS серверам через шлюз удаленных рабочих столов Remote Desktop Gateway, вы можете обрабатывать логи подключений пользователей по журналу Microsoft-Windows-TerminalServices-Gateway по EventID 302. Например, следующий PowerShell скрипт выведет полную историю подключений через RD Gateway указанного пользователя:

$rdpusername="kbuldogov"
$properties = @(
@{n='User';e={$_.Properties[0].Value}},
@{n='Source IP Adress';e={$_.Properties[1].Value}},
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='Target RDP host';e={$_.Properties[3].Value}}
)
(Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-Gateway/Operational';ID='302'} | Select-Object $properties) -match $rdpusername

Список текущих RDP сессий на сервере можно вывести командой:

qwinsta

Команда возвращает как идентификатор сессии (ID), имя пользователя (USERNAME)и состояние (Active/Disconnect). Эту команду удобна использовать, когда нужно определить ID RDP сессии пользователя при теневом подключении.

Список запущенных процессов в конкретной RDP сессии (указывается ID сессии):

qprocess /id:157

Логи RDP подключений на клиентах Windows

Также вы можете изучать логи исходящих подключений на стороне RDP клиента. Они доступны в журнале событий Application and Services Logs -> Microsoft -> Windows -> TerminalServices-ClientActiveXCore -> Microsoft-Windows-TerminalServices-RDPClient -> Operation.

Например, событие с Event ID 1102 появляется, когда компьютер устанавливает подключение с удаленным RDS хостом Windows Server или компьютером с Windows 10/11 с включенной службой RDP (десктопные версии Windows также поддерживают несколько одновременных rdp подключений).

The client has initiated a multi-transport connection to the server 192.168.31.102.

Следующий RDP скрипт выведет историю RDP подключений на указанном компьютере (для получения событий Event Log используется командлет Get-WinEvent):

$properties = @(
@{n='TimeStamp';e={$_.TimeCreated}}
@{n='LocalUser';e={$_.UserID}}
@{n='Target RDP host';e={$_.Properties[1].Value}}
)
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-RDPClient/Operational';ID='1102'} | Select-Object $properties

Скрипт возвращает SID пользователей, которые инициировали RDP подключения на этом компьютере и DNS имена/IP адреса серверов, к которым подключались пользователи. Вы можете преобразовать SID в имена пользователей.

Также история RDP подключений пользователя хранится в реестре.

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

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

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

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

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

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

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

winrm qc

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

Enable-PSRemoting

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

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

 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)

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

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

Wevtutil get-log security

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

Invoke-Command -ComputerName (Get-Content .computers.txt) -FilePath .security.ps1

Как вы поняли, в папке, откуда вы выполните эту команду должно быть 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, для этого, от имени администратора выполним:

wecutil qc

В оснастке службы должна будет появиться данная служба, с типом запуска 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.

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

wecutil ss "AllServers" /cf:Events

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

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

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

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

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

Скрипт лежит на GitHub — https://github.com/sanglyb/ps-copy-log-source

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

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

.export-log exchange

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

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

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

.import-log exchange

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

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

PS

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

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:

netsh advfirewall firewall add rule name="Windows Remote Management (HTTP-In)" dir=in action=allow service=any enable=yes profile=any localport=5985 protocol=tcp

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

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

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

Выполнение команды

netsh http show iplisten

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

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

netsh http delete iplisten ipaddress=127.0.0.1
netsh http add iplisten ipaddress=0.0.0.0

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

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

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

ping -n 240 127.0.0.1
wevtutil set-log ForwardedEvents /lfn:"E:Forwarded EventsForwardedEvents.evtx"