Если в работе Windows 2016 появляется какая-то нестабильность, или появляются ошибки запускаустановки приложений, то это может быть связано с появлениями ошибок в самой операционной системе.
Все системные ошибки и предупреждения можно найти в «Журнале системы«.
В нем сохраняется информация о событиях, записываемых системными компонентами Windows.
Для просмотра и сохранения системного журнала нужно выполнить шаги:
Открыть «Пуск«:
Открыть «Средства администрирования» -> «Просмотр событий«
В открывшемся окне выбрать «Просмотр событий» -> «Журналы Windows» -> «Система«
Экспорт журнала
Системный журнал в полном объеме можно выгрузить путем нажатия на ссылку «Сохранить все события как…«
После нажатия ссылки «Сохранить все события как…» нужно выбрать путь и имя файла для сохраняемого журнала.
При сохранении файла возможно появление окна «Отображение сведений«.
В данном окне нужно выбрать пункт «Отображать сведения для следующих языков: Русский«
Posted by
on September 27, 2016
This post will show you where the .evtx log files can be found in Windows Server 2016, as well as how they can be viewed with Event Viewer.
Viewing Log Files
The easiest way to view the log files in Windows Server 2016 is through the Event Viewer, here we can see logs for different areas of the system.
Event viewer can be opened through the MMC, or through the Start menu by selecting All apps, Windows Administrative Tools, followed by Event Viewer.
Through Event Viewer we have the ability to search the logs for a particular string, export the logs to a file, and even schedule a task to take place each time a specific event occurs.
Log File Location
While this allows us to read the logs, you may be after the full path to where the actual .evtx files are stored. These log files can be found in the C:WindowsSystem32winevtlogs folder, as shown below.
These files can be double clicked and they will automatically open with Event Viewer, and these are the files that are read when browsing through Event Viewer
Note that specific applications may have their own custom log locations, in which case you will need to check the vendors documentation regarding log file location.
Summary
We have seen that important application, security and system events that have been logged are stored in the C:WindowsSystem32winevtlogs directory as .evtx files, which can be viewed through Event Viewer.
При отладке работы клиента 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 и наполнит символьный кеш в каталоге:
То есть, с точки зрения текущего пользователя, который выполняет командлет, путь может иметь вид типа C:UsersAppDataLocalTempWindowsUpdateLogSymCache
В нашем примере в каталог символьного кеша было загружено около 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, можно получить информацию о том с каких IP и какие пользователи подключались к виртуальному серверу, и когда они это делали.
Приведенная ниже инструкция может быть использована также на десктопных версиях Windows.
Рассмотрим некоторые наиболее распространенные коды связанные со временем запуска и завершения работы сервера.
1149: Присутствие данного кода говорить об успешной аутентификации пользователя на сервере. (Remote Desktop Services: User authentication succeeded)
21: данный код говорить об успешном входе в систему, то-есть пользователь увидел окно рабочего стола. (Remote Desktop Services: Session logon succeeded)
24: это событие говорить об успешном отключении от RDP (Remote Desktop Services: Session has been disconnected)
25: говорит об переподключении к RDP сессии. (Remote Desktop Services: Session reconnection succeeded)
23: пользователь нажал Logoff и вышел из системы (Remote Desktop Services: Session logoff succeeded )
39: пользователь лично отключился от RDP сессии (не просто закрыл RDP окно). Или его отключил другой пользователь или администратор.
Как просмотреть данные события?
Нажмите Win+R и введите eventvwr
В левой части панели откройте «Журналы Windows => Система»
В колонке Event ID мы увидим список событий, произошедших во время работы Windows. Журнал событий можно сортировать по идентификатору события.
Для того что бы отсортировать нужные нам события, с правой стороны, выберем «Фильтр текущего журнала»
Теперь введите нужные нам события, через запятую, 1149,39,25,24,23,21 и нажмите Ок.
Теперь мы можем наблюдать журнал событий с завершением работы нашего сервера VPS.
Данные ивенты, можно посмотреть в разных разделах. Например:
EventId 1149,4624,4625 — фильтруем в Windows Logs => Security
EventId 25,24,21,39 — фильтруем в Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operational
EventId 23 — Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-LocalSessionManager -> Operationa
Теперь вы можете самостоятельно проверить по кто и когда заходил по RDP на Ваш сервер.
Исторически для анализа работы агента и службы обновления Windows используется текстовый файл WindowsUpdate.log. Однако в Windows 10 (Windows Server 2016/2019) вместо привычного текстового файла логи Windows Update ведутся в формате Event Tracing for Windows (ETW). За счет этого увеличивается быстродействие подсистемы записи логов и экономится место на диске.
Таким образом, события Windows Update теперь больше не записываются в реальном времени в файл %windir%WindowsUpdate.log. И хотя сам файл все еще присутствует в корне папки Windows, в нем лишь указано, что для сбора логов теперь применяется формат ETW.
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
Главное неудобство для администраторов – теперь вы не можете быстро проанализировать текстовый файл WindowsUpdate.log, найти ошибки в службе агента обновлений Windows (см. полный список ошибок Windows Update), проверить настройки WSUS и проанализировать историю установки обновлений.
Вы можете сконвертировать события ETW в привычный текстовый формат WindowsUpdate.log для более удобного анализа событий службы обновлений. Для этого используется командлет PowerShell — Get-WindowsUpdateLog. Данный командлет позволяет собрать информацию со всех .etl файлов (хранятся в каталоге C:WINDOWSLogsWindowsUpdate) и сформировать один файл WindowsUpdate.log.
Чтобы сформировать файл WindowsUpdate.log и поместить его в каталог C:PSLogs, выполните следующую команду в консоли PowerShell:
Get-WindowsUpdateLog -logpath C:PSLogsWindowsUpdate.log
В Windows Server 2016 при запуске командлета
Get-WindowsUpdateLog
может появиться ошибка отсутствующего файла SymSrv.dll:
Copy-Item : Cannot find path 'C:Program FilesWindows DefenderSymSrv.dll' because it does not exist. At C:Windowssystem32WindowsPowerShellv1.0ModulesWindowsUpdateWindowsUpdateLog.psm1:56 char:5
Файл “C:Program FilesWindows DefenderSymSrv.dll” обычно отсутствует, если на сервере не установлен антивирус Windows Defender.
Чтобы исправить ошибку, вы можете установить Defender, скопировать файл SymSrv.dll с другого Windows Server 2016/ Windows 10 или поиском найти его в каталоге “C:WindowsWinSxS” (у меня каталог назывался C:WindowsWinSxSamd64_windows-defender-service-cloudclean_…) и скопировать его в папку C:Program FilesWindows Defender.
В старых версиях Windows 10 при первом запуске командлет Get-WindowsUpdateLog скачает и установит сервер символов Microsoft (Microsoft Internet Symbol Store). В последних версиях Windows 10 выполняется онлайн доступ к серверу символов Microsoft в Azure. Затем командлет:
- Собирает данные из всех .etl файлов;
- Преобразует данные в CSV (по-умолчанию) или XML формат;
- Переконвертирует данные из промежуточных файлов и добавляет их в текстовый файл журнала, указанного в параметре LogPath (если параметр LogPath не задан, файл WindowsUpdate.log создается на рабочем столе пользователя, запустившего команду).
В некоторых случаях в журнале WindowsUpdate.log вы видеть такие строки
Unknown( 10): GUID=5e0ee4cc-3618-f43a-06ca-9d3b0dabc11a (No Format Information found).
Это значит, что у вас не установлен сервер символов Windows Symbol (сейчас нельзя скачать отдельную программу установки Windows symbols, т.к. они автоматически загружаются из хранилища символов в Azure). Для изолированных сред вы можете использовать офлайн версию сервера символов согласно статье Offline Symbols for Windows Update.
Откройте файл журнала с помощью такой команды PowerShell:
Invoke-Item -Path C:PSLogsWindowsUpdate.log
Совет. Обратите внимание, что созданный файл WindowsUpdate.log является статическим и не обновляется в реальном времени, как в предыдущих версиях Windows. Чтобы обновить данные журнала обновлений, нужно еще раз запустить командлет Get-WindowsUpdateLog, либо создать скрипт, автоматически обновляющий файл с какой-то периодичностью (файл перезатирается).
Анализировать получившийся файл WindowsUpdate.log довольно сложно, т.к. в нем собираются данные из множества источников:
- AGENT- события агента Windows Update;
- AU – автоматическое обновление;
- AUCLNT- взаимодействие с пользователем;
- HANDLER- управление установщиком обновлений;
- MISC- общая информация;
- PT- синхронизация обновлений с локальным хранилищем;
- REPORT- сбор отчетов;
- SERVICE- запуск/выключение службы wuauserv;
- SETUP- установка новых версий клиента Windows Update;
- DownloadManager – загрузка обновлений в локальных кэш;
- Handler, Setup – заголовки установщиков (CBS и т.п.);
- И т.д.
Вы можете выбрать последние 30 событий от агента обновления Windows (agent) с помощью простого регулярного выражения:
Select-String -Pattern ‘sagents’ -Path C:PSLogsWindowsUpdate.log | Select-Object -Last 30
Можно отфильтровать события в логе по нескольким источникам:
Select-String -Pattern ‘sagents|smiscs’ -Path c:PSLogsWindowsUpdate.log | Select-Object -Last 50
Аналогично вы можете искать события по номеру KB, ошибка (строки FAILED, Exit Code, FATAL).
Также вы можете сформировать файл WindowsUpdate.log для удаленного компьютера/сервера:
Get-WindowsUpdateLog -ETLPath \PC221C$windowsLogsWindowsUpdate -LogPath C:PSLogswindowsupdatePC221.log
Также для анализа работы службы обновлений Windows может быть полезны журналы Event Viewer в разделе Applications and Services Logs -> Microsoft -> Windows –> WindowsUpdateClient -> Operational.
Для управления обновлениями из PowerShell вы можете использовать модуль PSWindowsUpdate.