Журнал обновлений windows server 2016

Исторически для анализа работы агента и службы обновления 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:\WINDOWS\Logs\WindowsUpdate) и сформировать один файл WindowsUpdate.log.

Чтобы сформировать файл WindowsUpdate.log и поместить его в каталог C:\PS\Logs, выполните следующую команду в консоли PowerShell:

Get-WindowsUpdateLog -logpath C:\PS\Logs\WindowsUpdate.log

Copy-Item : Cannot find path 'C:\Program Files\Windows Defender\SymSrv.dll' because it does not exist. At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 char:5

В старых версиях Windows 10 при первом запуске командлет Get-WindowsUpdateLog скачает и установит сервер символов Microsoft (Microsoft Internet Symbol Store). В последних версиях Windows 10 выполняется онлайн доступ к серверу символов Microsoft в Azure. Затем командлет:

1. Собирает данные из всех .etl файлов;
2. Преобразует данные в CSV (по-умолчанию) или XML формат;
3. Переконвертирует данные из промежуточных файлов и добавляет их в текстовый файл журнала, указанного в параметре LogPath (если параметр LogPath не задан, файл WindowsUpdate.log создается на рабочем столе пользователя, запустившего команду).

Unknown( 10): GUID=5e0ee4cc-3618-f43a-06ca-9d3b0dabc11a (No Format Information found).

Откройте файл журнала с помощью такой команды PowerShell:

Invoke-Item -Path C:\PS\Logs\WindowsUpdate.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 '\sagent\s' -Path C:\PS\Logs\WindowsUpdate.log | Select-Object -Last 30

Можно отфильтровать события в логе по нескольким источникам:

Select-String -Pattern '\sagent\s|\smisc\s' -Path c:\PS\Logs\WindowsUpdate.log | Select-Object -Last 50

Аналогично вы можете искать события по номеру KB, ошибка (строки FAILED, Exit Code, FATAL).

Также вы можете сформировать файл WindowsUpdate.log для удаленного компьютера/сервера:

Get-WindowsUpdateLog -ETLPath \\PC221\C$\windows\Logs\WindowsUpdate -LogPath C:\PS\Logs\windowsupdatePC221.log

Также для анализа работы службы обновлений Windows может быть полезны журналы Event Viewer в разделе Applications and Services Logs -> Microsoft -> Windows –> WindowsUpdateClient -> Operational.

Для управления обновлениями из PowerShell вы можете использовать модуль PSWindowsUpdate.

При отладке работы клиента 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:\Windows\WindowsUpdate.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:\Windows\Logs\WindowsUpdate будет сформирован читаемый текстовый лог-файл 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:\Temp\WindowsUpdate\ и выполним обработку копии логов:

Get-WindowsUpdateLog -ETLPath "C:\Temp\WindowsUpdate\" -LogPath "C:\Temp\WU.log"

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

Get-WindowsUpdateLog -ETLPath "\\WS2016srv\C$\Windows\Logs\WindowsUpdate" -LogPath "C:\Temp\WU.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%\WindowsUpdateLog\SymCache.

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

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

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

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

Get-WindowsUpdateLog -SymbolServer "\\FileSrv\WS2016\WUSymCache"

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

Получить больше информации о логах, относящихся к работе 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

Historically, the WindowsUpdate.log plain text file has been used to analyze the operation of the Windows Update agent and service. However, the Windows Update logs in Windows 10 (Windows Server 2016/2019) are saved in the Event Tracing for Windows file format (ETW), instead of the usual text file. With such an action, the Windows developers planned to increase the performance of the logging subsystem and reduce the space occupied by the text files on the disk.

Thus, Windows Update events are no longer written in real time to the %windir%\WindowsUpdate.log file. Even though the file is still present in the root of the Windows folder, it only says that the ETW format is now used to collect WU logs.

The disadvantage of the new logging method for administrators – now you can’t quickly analyze the Windows Update Agent service, find error codes in the WindowsUpdate.log text file (see the Complete List of Windows Update Error Codes), check the WSUS agent settings and analyze the update installation history.

You can convert ETW events to the plain text WindowsUpdate.log file for more convenient analysis of update service events. To do this, use the PowerShell cmdlet – Get-WindowsUpdateLog. This cmdlet allows you to collect information from all .etl files (they are stored in C:\WINDOWS\Logs\WindowsUpdate) and create a single WindowsUpdate.log text file.

To generate the WindowsUpdate.log file and save it in the C:\PS\Logs, run the following command in the PowerShell console:

Get-WindowsUpdateLog -logpath C:\PS\Logs\WindowsUpdate.log

Copy-Item : Cannot find path 'C:\Program Files\Windows Defender\SymSrv.dll' because it does not exist. At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 char:5

In older Windows 10 builds, the first time you run the Get-WindowsUpdateLog cmdlet, it downloads and installs the Microsoft Internet Symbol Store. Newest versions of Windows 10 access the Microsoft Character Server in Azure online. Then the cmdlet:

1. Reads the data from all .etl files;
2. The data are converted into CSV (by default) or XML format;
3. The data from the file in an intermediate format will be converted and added to the log text file specified in the LogPath parameter (if the parameter in LogPath is not specified, WindowsUpdate.log is created on the desktop of the user running the command)

Tip. Another way to analyze ETL files, but somewhat more complicated, is by using Tracefmt.exe utility to receive data from .etl.

Open the log file using this PowerShell command:

Invoke-Item -Path C:\PS\Logs\WindowsUpdate.log

In some cases, in the WindowsUpdate.log file you can see such strings:

Unknown(140): GUID=53212e4cc-4321-f43a-2123-9ada0090bc12b (No Format Information found).

This means that you don’t have the Windows Symbol server installed (today you cannot download a separate Windows symbols installer, because it is automatically downloaded from the symbol store in Azure). For isolated environments, you can use the offline version of the symbol server according to the article Offline Symbols for Windows Update.

Tip. Please, note that the created WindowsUpdate.log file is static and is not updated in real time as in previous Windows versions. To update the file, you need to run Get-WindowsUpdateLog cmdlet once again or create a script that automatically updates the file at some frequency (the file is overwritten).

It is quite difficult to analyze the resulting WindowsUpdate.log file, because it collects data from many event sources:

• AGENT – Windows Update agent events;
• AU – automatic update;
• AUCLNT – user interaction;
• HANDLER – update installer management;
• MISC – common WU info;
• PT – synchronization of updates with local datastore;
• REPORT – reports collection;
• SERVICE – wuauserv service start/stop events;
• SETUP – installing new versions of the Windows Update client;
• DownloadManager – downloading updates to local cache using BITS;
• Handler, Setup – installer headers (CBS , etc.);
• and many others.

You can select the last 30 events from the Windows Update Agent (agent) with a simple regular expression:

Select-String -Pattern '\sagent\s' -Path C:\PS\Logs\WindowsUpdate.log | Select-Object -Last 30

You can filter events in the WindowsUpdate.log by several sources:

Select-String -Pattern '\sagent\s|\smisc\s' -Path c:\PS\Logs\WindowsUpdate.log | Select-Object -Last 50

Similarly, you can parse the text file for events by KB number, errors (FAILED, Exit Code, FATAL).

You can also generate the WindowsUpdate.log file for the remote computer or server:

Get-WindowsUpdateLog -ETLPath \\ny-srf-1\C$\windows\Logs\WindowsUpdate -LogPath C:\PS\Logs\windowsupdate-ny-srf-1.log

You can also use Event Viewer logs to analyze the operation of the Windows Update service. Expand the following Event View section: Applications and Services Logs -> Microsoft -> Windows –> WindowsUpdateClient -> Operational.

You can use the PSWindowsUpdate module to manage updates from PowerShell cli.