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.

Практическое руководство. Запись сведений о службах в журнал How to: Log Information About Services

По умолчанию все проекты служб Windows могут взаимодействовать с журналом событий приложения и записывать в него сведения и исключения. By default, all Windows Service projects have the ability to interact with the Application event log and write information and exceptions to it. Чтобы указать, что эта функциональность должна быть в вашем приложении, можно использовать свойство AutoLog . You use the AutoLog property to indicate whether you want this functionality in your application. По умолчанию ведение журнала включено для любой службы, созданной с помощью шаблона проекта службы Windows. By default, logging is turned on for any service you create with the Windows Service project template. Можно использовать статическую форму класса EventLog для записи сведений в журнал, и тогда не потребуется создавать экземпляр компонента EventLog или вручную регистрировать источник. You can use a static form of the EventLog class to write service information to a log without having to create an instance of an EventLog component or manually register a source.

Установщик службы автоматически регистрирует каждую службу в проекте как допустимый источник событий для журнала приложений на компьютере, где установлена служба, если включено ведение журнала. The installer for your service automatically registers each service in your project as a valid source of events with the Application log on the computer where the service is installed, when logging is turned on. Служба записывает сведения каждый раз, когда служба запускается, останавливается, приостанавливается, возобновляется, устанавливается или удаляется. The service logs information each time the service is started, stopped, paused, resumed, installed, or uninstalled. Она также записывает все возникающие ошибки. It also logs any failures that occur. Вам не нужно писать никакой код для записи в журнал при использовании этого поведения по умолчанию; служба обрабатывает это автоматически. You do not need to write any code to write entries to the log when using the default behavior; the service handles this for you automatically.

Если вы хотите выполнять запись в другой журнал событий, отличный от журнала приложения, то необходимо задать для свойства AutoLog значение false , создать собственный пользовательский журнал событий в коде службы и зарегистрировать службу в качестве источника записей для этого журнала. If you want to write to an event log other than the Application log, you must set the AutoLog property to false , create your own custom event log within your services code, and register your service as a valid source of entries for that log. Затем вам придется написать код для выполнения записи в журнал всякий раз, когда происходит интересующее вас действие. You must then write code to record entries to the log whenever an action you’re interested in occurs.

Если вы используете пользовательский журнал событий и настроили службу для записи в этот журнал, не пытайтесь обратиться к этому журналу до установки свойства ServiceName службы в коде. If you use a custom event log and configure your service application to write to it, you must not attempt to access the event log before setting the service’s ServiceName property in your code. Журналу событий нужно значение этого свойства, чтобы зарегистрировать службу в качестве допустимого источника событий. The event log needs this property’s value to register your service as a valid source of events.

Включение ведения журнала событий по умолчанию для службы To enable default event logging for your service

Установите для свойства AutoLog вашего компонента значение true . Set the AutoLog property for your component to true .

По умолчанию для свойства задано значение true . By default, this property is set to true . Вам не нужно задавать это явно, если только вы не создаете более сложную обработку, такую как оценка условия и последующая установка свойства AutoLog в зависимости от результата этого условия. You do not need to set this explicitly unless you are building more complex processing, such as evaluating a condition and then setting the AutoLog property based on the result of that condition.

Отключение ведения журнала событий для службы To disable event logging for your service

Установите для свойства AutoLog вашего компонента значение false . Set the AutoLog property for your component to false .

Настройка ведения пользовательского журнала To set up logging to a custom log

Задайте для свойства AutoLog значение false . Set the AutoLog property to false .

Чтобы использовать пользовательский журнал, необходимо задать в свойстве AutoLog значение false. You must set AutoLog to false in order to use a custom log.

Настройте экземпляр компонента EventLog в приложении службы Windows. Set up an instance of an EventLog component in your Windows Service application.

Создайте пользовательский журнал, вызвав метод CreateEventSource и задав исходную строку и имя файла журнала, который хотите создать. Create a custom log by calling the CreateEventSource method and specifying the source string and the name of the log file you want to create.

Укажите в свойстве Source компонента EventLog исходную строку, созданную на шаге 3. Set the Source property on the EventLog component instance to the source string you created in step 3.

Выполняйте запись в журнал, вызывая метод WriteEntry в экземпляре компонента EventLog . Write your entries by accessing the WriteEntry method on the EventLog component instance.

Следующий код показывает, как настроить ведение пользовательского журнала. The following code shows how to set up logging to a custom log.

В этом примере кода экземпляр компонента EventLog называется eventLog1 ( EventLog1 в Visual Basic). In this code example, an instance of an EventLog component is named eventLog1 ( EventLog1 in Visual Basic). Если на шаге 2 вы создали экземпляр с другим именем, измените код соответствующим образом. If you created an instance with another name in step 2, change the code accordingly.

How to: Log Information About Services

By default, all Windows Service projects have the ability to interact with the Application event log and write information and exceptions to it. You use the AutoLog property to indicate whether you want this functionality in your application. By default, logging is turned on for any service you create with the Windows Service project template. You can use a static form of the EventLog class to write service information to a log without having to create an instance of an EventLog component or manually register a source.

The installer for your service automatically registers each service in your project as a valid source of events with the Application log on the computer where the service is installed, when logging is turned on. The service logs information each time the service is started, stopped, paused, resumed, installed, or uninstalled. It also logs any failures that occur. You do not need to write any code to write entries to the log when using the default behavior; the service handles this for you automatically.

If you want to write to an event log other than the Application log, you must set the AutoLog property to false , create your own custom event log within your services code, and register your service as a valid source of entries for that log. You must then write code to record entries to the log whenever an action you’re interested in occurs.

If you use a custom event log and configure your service application to write to it, you must not attempt to access the event log before setting the service’s ServiceName property in your code. The event log needs this property’s value to register your service as a valid source of events.

To enable default event logging for your service

Set the AutoLog property for your component to true .

By default, this property is set to true . You do not need to set this explicitly unless you are building more complex processing, such as evaluating a condition and then setting the AutoLog property based on the result of that condition.

To disable event logging for your service

Set the AutoLog property for your component to false .

To set up logging to a custom log

Set the AutoLog property to false .

You must set AutoLog to false in order to use a custom log.

Set up an instance of an EventLog component in your Windows Service application.

Create a custom log by calling the CreateEventSource method and specifying the source string and the name of the log file you want to create.

Set the Source property on the EventLog component instance to the source string you created in step 3.

Write your entries by accessing the WriteEntry method on the EventLog component instance.

The following code shows how to set up logging to a custom log.

In this code example, an instance of an EventLog component is named eventLog1 ( EventLog1 in Visual Basic). If you created an instance with another name in step 2, change the code accordingly.

Enable Service Log on for run as accounts

Security best practice is to disable interactive and remote interactive sessions for service accounts. Security teams, across organizations have strict controls to enforce this best practice to prevent credential theft and associated attacks.

System Center 2019 — Operations Manager supports hardening of service accounts and does not require granting the Allow log on locally user right for several accounts, required in support of Operations Manager.

Earlier version of Operations Managers has Allow log on locally as the default log on type. Operations Manager 2019 uses Service Log on by default. This leads to the following changes:

• Health service uses log on type Service by default. Operations Manager 1807 and earlier versions, it was Interactive.
• Operations Manager action accounts and service accounts now have Log on as a Service permission.
• Action accounts and Run As accounts must have Log on as a Service permission to execute MonitoringHost.exe. Learn more.

Changes to Operations Manager action accounts

The following accounts are granted Log on as a Service permission during the Operations Manager 2019 installation, and during upgrade from previous versions:

Management Server Action account

System Center configuration service and System Center data access service accounts

Agent action account

Data Warehouse Write account

Data Reader account

After this change, any Run As accounts created by Operations Manager administrators for the management packs (MPs) require the Log on as a Service right, which administrators should grant.

View log on type for management servers and agents

You can view the log on type for management servers and agents from the Operations Manager console.

To view the log on type for management servers, go to Administration > Operations Manager Products> Management servers.

To view the log on type for agents, go to Administration > Operations Manager Products> Agents.

Agent/gateway that is not yet upgraded, display Log on type as Service in console . Once the agent/gateway is upgraded, the current log on type will be displayed.

Enable service log on permission for Run As accounts

Follow these steps:

Sign in with administrator privileges to the computer from which you want to provide Log on as Service permission to a Run As accounts.

Go to Administrative Tools and click Local Security Policy.

Expand Local Policy and click User Rights Assignment.

In the right pane, right-click Log on as a service and select Properties.

Click Add User or Group option to add the new user.

In the Select Users or Groups dialogue, find the user you wish to add and click OK.

Click OK in the Log on as a service Properties to save the changes.

If you are upgrading to Operations Manager 2019 from a previous version or installing a new Operations Manager 2019 environment, follow the steps above to provide Log on as a service permission to Run As accounts.

Change log on type for a health service

If you need to change the log on type of Operations Manager health service to Allow log on locally, configure the security policy setting on the local device using the Local Security Policy console.

Here is an example:

Coexistence with Operations Manager 2016 agent

With the log on type change that is introduced in Operations Manager 2019, the Operations Manager 2016 agent can coexist and interoperate without any issues. However, there are a couple of scenarios that are affected by this change:

• Push install of agent from the Operations Manager console requires an account that has administrative privileges and the Log on as a service right on the destination computer.
• Operations Manager Management Server action account requires administrative privileges on management servers for monitoring Service Manager.

Troubleshooting

If any of the Run as accounts do have the required Log on as a Service permission, a critical monitor-based alert appears. This alert displays the details of the Run As account, which does not have Log on as a Service permission.

On the agent computer, open Event Viewer. In the Operations Manager log, search for the event ID 7002 to view the details about the Run As accounts that require Log on as a Service permission.

Parameter	Message
Alert Name	Run As account does not have requested log on type.
Alert Description	The Run As account must have the requested log on type.
Alert Context	Health Service could not log on, as the Run As account for management group (group name) has not been granted the Log on as a service permission.
Monitor	(add monitor name)

Provide Log on as a Service permission to the applicable Run As accounts, which are identified in the event 7002. Once you provide the permission, event ID 7028 appears and the monitor changes to healthy state.