Installation Logging: How To Create a Verbose Windows Installer Log and Submit it With Your Question (Including .MSIs That are INSIDE Setup.exes)

Among others, I monitor the Windows Installer zone and Installer zone.

I find that many of the questions could be answered much more quickly if a Windows Installer verbose log were submitted with the question.  

However, I do not always have the time to explain how to do this in each thread, so I thought I would explain it in an article.

In fact, you may be reading this because I referenced you here from a question you asked.

I hope you take the time to generate the Windows Installer log because it can easily eliminate days of back and forth on a question you have posted.

Why Take The Time To Generate a Windows Installer Log?
Windows Installer logging is very exhaustive.  In fact, in full verbose mode it differs very little from the programmers debug log that Microsoft developers would use to debug the Windows Installer service.

The effect of this is that almost any problem can be determined by examining a Windows Installer log - with no need to re-run an exact test scenario and be at the machine in question.

Windows Installer logging can be controlled either by a group policy registry key or on the command line.

Logging From the Command Line
The command line is appropriate when you can run a command line in the EXACT same context that the problem package is running.  For instance, a login script processes just like running msiexec.exe manually for the same user.   However, a package running through your software distribution system uses different user accounts, servers and folder locations.

Here is the logging command line:

msiexec.exe /i packagename.msi /L*v c:\fullpath\to\log\logname.log

The "/L" switch turns on logging.  The "*v" tells Windows Installer to generate the maximum level of information.  

The log name (c:\fullpath\to\log\logname.log) is required and needs to point to a NON-Network location (latency is too high) that the user running msiexec has write permissions for.  This can be set to %TEMP%\logname.log to ensure the user running it will be able to write to the location.

This command line will need to be run under the EXACT user id on the EXACT computer where the failure is occurring.

Logging Using the Policy

Logging using the Group Policy (GP) or Registry Keys (REG) applies to many more circumstances.  In the below list of benefits of using the group policy, we have identified the items that benefit from using a registry key to change the logging, rather than an official group policy in active directory.

Here are the circumstances it covers:

When choosing to use the registry for a temporary test, I am a big advocate of using .REG files.  As background, here is the registry key that stores the policy: HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer.

It is easy to message up this registry key and there is one other advantage to a .REG as well:


For this purpose I use MSI-Verbose-Logging-ON.reg to turn on verbose logging:
MSI-Verbose-Logging-ON.reg

And MSI-Verbose-Logging-OFF.reg to turn logging off again:
MSI-Verbose-Logging-OFF.reg

These registry files are simply manipulating the same registry key that group policy does.  So if your organization has a group policy set to change the MSI Logging policy as well - just remember that the registry key will be reset on the next group policy refresh cycle.

Once you have the logging policy in place (either by group policy or .REG file), you will need to re-trigger the problem situation, whether it is a self-heal, an initial install, a reconfiguration, a re-install, etc.

Locating a Policy/Registry Generated Log
When using group policy or the registry to generate a log, it is given a random name and located in the user specific temporary folder.

The file name follows the format templated "MSI?????.LOG" - where "?" is a random alpha or numeric character.

The log is placed in the TEMP folder of the "user who Started the Package.  In the case of a login script, this would be the actual user of the system.  In the case of a software distribution system, this would be the user account that it uses for installing with admin rights.  Some distribution systems have several special user accounts and some simply use the built-in SYSTEM account.

Although Windows Installer itself uses the SYSTEM account while processing the package, the log is always stored in the TEMP folder of the user who started MSIEXEC with the package name.  (known as the client side instance of MSI).

What Windows Installer Logging Cannot Catch (What If I Do Not Get a Log?)
There is several types of errors that can occur BEFORE the Windows Installer log even starts - usually resulting in no Windows Installer log being generated.  For instance, if the .MSI file cannot be found, then a verbose log is never started.

In the case of command line logging from a console window (not a script), if you are using the /qn switch, simply remove it and you will see the command shell reports that the .MSI cannot be located.  If using a shell script (.CMD/.BAT), it should be updated to check the errorlevel after executing msiexec.exe.

BONUS: Separating An .MSI File From an EXE Wrapper
The "Debug" policy which is set by the .REG files in this article will cause the MSIEXEC command line to be visible in the first lines of the log.  There is one very specific situation where this information can be handy.  

Many administrators wish to remove .MSI files from their wrapper EXEs so that they can have more control over the command line (add transforms, etc) or run them in group policy.  Many times, however, these .MSIs can detect that they were not called by the EXE wrapper they were stored in or next to.  When using the Debug command line you can see the command line that the setup.exe uses to start the .MSI file.   Many times using this command line will cause the .MSI to run stand alone.

This solution does not work in every instance because it is also possible for the .MSI to have critical interactive dependencies on the setup.exe (rather than just launch time dependencies).  For instance Windows Installer allows for a setup developer to create the UI of the setup program in a completely different EXE based technology.

You will also want to examine the passed properties carefully for machine specific data - the setup.exe could be doing some advanced detection of something on each machine and passing it to the .MSI, in which case automating the properties for EVERY other machine would create a problem.

CSI:\> Windows
Be The Expert: Put Apps on Windows 7, Virtualization and 64-bit
http://csi-windows.com