Enable Windows Installer logging

Windows includes a registry-activated logging service to help diagnose Windows Installer issues. This article describes how to enable this logging service.

Original product version: В Windows 10 — all editions, Windows Server 2012 R2
Original KB number: В 223300

The registry entry in this article is valid for all Windows operating systems.

Windows Installer logging

Windows Installer can use logging to help assist in troubleshooting issues with installing software packages. This logging is enabled by adding keys and values to the registry. After the entries have been added and enabled, you can retry the problem installation and Windows Installer will track the progress and post it to the Temp folder. The new log’s file name is random. However, the first letters are Msi and the file name has a .log extension. To locate the Temp folder, type the following line at a command prompt:

To enable Windows Installer logging manually, see the following section.

Enable Windows Installer logging manually

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

To enable Windows Installer logging yourself, open the registry by using Regedit.exe, and then create the following subkey and keys:

• Path: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
• Type: Reg_SZ
• Value: Logging
• Data: voicewarmupx

The letters in the value field can be in any order. Each letter turns on a different logging mode. Each letter’s actual function is as follows for MSI version 1.1:

• v — Verbose output
• o — Out-of-disk-space messages
• i — Status messages
• c — Initial UI parameters
• e — All error messages
• w — Non-fatal warnings
• a — Start up of actions
• r — Action-specific records
• m — Out-of-memory or fatal exit information
• u — User requests
• p — Terminal properties
• + — Append to existing file
• ! — Flush each line to the log
• x — Extra debugging information. The x flag is available only in Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.
• * — Wildcard. Log all information except the v and the x option. To include the v and the x option, specify /l*vx.

This change should be used only for troubleshooting and should not be left on because it will have adverse effects on system performance and disk space. Each time that you use the Add or Remove Programs item in Control Panel, a new Msi*.log file is created. To disable the logging, remove the Logging registry value.

Enable Windows Installer logging with Group Policies

You can enable logging with Group Policies by editing the appropriate OU or Directory Group Policy. Under Group Policy, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then select Windows Installer.

Double-click Logging, and then click Enabled. In the Logging box, enter the options you want to log. The log file, Msi.log, appears in the Temp folder of the system volume.

For more information about MSI logging, see Windows Help. To do this, search by using the phrase msi logging, and then select Managing options for computers through Group Policy.

The addition of the x flag is available natively in Windows Server 2003 and later operating systems, on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

Windows application install log

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз я вас научил определять кто именно перезагрузил сервер, это полезный навык при расследовании инцидентов. Бывают ситуации, что на сервер используют большое количество пользователей с одинаковыми правами, и вдруг куда-то пропадает одна из программ, вы видите что ее нет, логично, что нужно выяснить кто именно удалил программу. Вот этим мы и займемся, я вас научу получать информацию, кто установил или удалил программу в Windows.

Как узнать кто установил программу и когда

И так у меня есть тестовый сервер с операционной системой Windows Server 2019 и я на него в качестве демонстрации буду устанавливать Microdoft Edge Chromium, FireFox Mozilla, а так же LogParser. Все события, что генерируются в операционной системе Windows появляются в просмотре событий, это лог файлы разбитые по журналам.

Открываем логи Windows, журнал «Приложение (Application)» или «Система (System)«, все зависит от инсталлятора которым собран пакет, так как есть те, что используют метод MsiInstaller , но есть и другие. Теперь запускаем инсталлятор LogParser. После установки я открываю журнал «Приложение», где я вижу ряд событий,

первое это событие с ID 1040 покажет вам начало установки программы:

Далее идет сообщение с кодом ID 10000.

Далее вы увидите событие, где заканчивается установка программы ID 1042

Завершается сеанс событием с кодом ID 10001

И заканчивается установка программы событием с кодом ID 11707

Иногда вы можете увидеть событие с ID 1033.

Если вы внимательны, то можете обратить внимание, что источником событий тут выступает MsiInstaller. Зная это вы легко можете произвести фильтрацию. Для этого в правой части найдите пункт «Фильтр текущего журнала»

В источниках событий выберите из выпадающего списка пункт MsiInstaller.

В итоге у меня получилось вот так.

Теперь когда события отфильтрованы по источнику MsiInstaller, вам будет еще легче найти кто установил, что установил и когда. В моем примере это сделал ROOT\Администратор.

Так же событие ID 11707 с пользователем «SYSTEM (СИСТЕМА)» вы можете обнаружить, когда люди используют «Software Store» в SCCM

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

Автоматизация оповещения по событиям 11707

Теперь когда вы знаете, как находить события по установке программ в системах семейства Windows, вам нужно автоматизировать данный процесс. Например, получать по почте, кто установил, где и что. В этом нам поможет конечно же PowerSell. Смысл автоматизации состоит в том, что вы на нужном сервере создаете задание в планировщике Windows, где будет запускаться скрипт PowerShell. Я вам приведу два скрипта, первый тот, что гуляет на просторах интернета.

Тут главное заполнить:

• Адрес вашего SMTP сервера
• От кого будет письмо
• Кому отправлять письмо
• Пароль от ящика отправителя

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

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

Так же вам никто не запрещает просто открыть PowerShell и ввести не сложный код:

Напоминаю, что select-object -first 1 выводит первое событие, можете увеличить на нужное вам.

Как найти события установки программ не методом MsiInstaller

Как я и писал выше не все инсталляторы программ используют метод MsiInstaller, например при установке Edge Chrome или Mozilla Firefox, вы в журнале «Приложение» не обнаружите события с кодом ID 11707. В таком случае вам нужно перейти в журнал «СИСТЕМА (SYSTEM)» и сразу отфильтровать события по номеру ID 7045.

Выглядит событие ID 7045 вот так:

Имя службы: Mozilla Maintenance Service
Имя файла службы: «C:\Program Files (x86)\Mozilla Maintenance Service\maintenanceservice.exe»
Тип службы: служба режима пользователя
Тип запуска службы: Вручную
Учетная запись службы: LocalSystem

Имя службы: Microsoft Edge Elevation Service
Имя файла службы: «C:\Program Files (x86)\Microsoft\Edge\Application\80.0.361.111\elevation_service.exe»
Тип службы: служба режима пользователя
Тип запуска службы: Вручную
Учетная запись службы: LocalSystem

Как узнать кто удалил программу с сервера или компьютера

По аналогии с установкой, процесс деинсталляции или как его еще называют удаление, генерирует свои события в журналах Windows. Если мы говорим, про источник MsiInstaller из журнала «Приложение (Application)», то нам нужно фильтровать события по ID 11724 и ID 1034.

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

Дополнительно

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

Event ID 10 is logged in the Application log after you install Service Pack 1 for Windows 7 or Windows Server 2008 R2

This article provides a script to solve the event ID 10 that’s logged after you install Service Pack 1 for Windows 7 or Windows Server 2008 R2.

Original product version: В Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1
Original KB number: В 2545227

Symptoms

After you install Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 SP1 using integrated media, the following WMI error is logged in the application log after every reboot:

Cause

This issue originated in the Windows 7 SP1 DVD/ISO creation process. There was an issue in the creation process that caused a WMI registration to remain in the DVD/ISO. Since the registration is designed to work only during the DVD/ISO creation process, it fails to run on a live system and causes these events. These events aren’t indicative of any issue in the system and can be safely ignored. If you want to prevent these events from getting generated and want to remove this specific WMI registration manually, run the workaround script.

Resolution

To resolve the issue, run a script to stop the Event ID 10 messages. To run the script, follow these steps:

In Notepad, create a new document named Workaround.txt.

Copy the following script into notepad:

Save the text as Workaround.vbs.

Open an elevated command prompt:

1. Select Start.
2. Select Programs.
3. Right-click on Command Prompt.
4. Choose run as administrator.

Change Directory to the one containing workaround.vbs, for example, CD c:\users\%username% .

Run the script workaround.vbs.

After running the script, the Event ID 10 errors related to this event should stop occurring. This script doesn’t remove any of the existing entries in the Event log, they would need to be manually cleared out of the application event log.

There can be other reasons for Event ID 10 error messages. This workaround only prevents the error message listed above from occurring.

More information

This particular Event ID 10 error message listed above can be safely ignored. It isn’t indicative of a problem with the Service Pack or with the operating system.