MSI Log Files

MSI log files can be incredibly useful for creating silent installations of vendor provided MSI's - for example, an application that has a serial number, or asks various questions, if you do a manual install fully logged (msiexec.exe /i /L*v c:\temp\funkylog.log) and then look in the log for the command line - it will change as the installation progresses but often things that the installation asks the user for are uses as properties, which can be entered in the command line, or in an MST and aid a silent installation.

Local Admin Check - VBScript

Check if the current user is a local administrator using the Windows Installer service.

Dim oInst, oSess, iAdmin, oProducts
Const msiUILEVELNONE = 2
Set oInst = CreateObject("WindowsInstaller.Installer")
oInst.UILevel = msiUILEVELNONE
Set oProducts = oInst.Products
Set oSess = oInst.OpenProduct(oProducts(0))
iAdmin = oSess.Property("AdminUser")
If iAdmin = 1 Then
Msgbox "You are a local administrator!", vbInformation, "ADMINISTRATOR"
Else
Msgbox "You are not a local administrator!", vbCritical, "NON-ADMIN"
End If

Restart for the Setup Capture Process

Many applications come up with a message after installation stating you must now restart the Computer.

Some packagers and Instructors are taught that during the setup capture of an application you MUST restart the Computer to capture any file updates and or registry changes that take place.

This is not always true.

Many times after the installation of an application simply running any and or all shortcuts that are created before doing the End Capture will update or create the Registry keys and files needed for the application package to work properly. Being able to bypass the restart during the setup capture does save time and depending what kind of environment you are packaging in (hopefully a VMware OS only environment) you will not capture any Registry keys or files that are not needed for the application package to function properly.

I have found that doing the steps above works atleast 80% of the time.

All about MSI Re-Packaging

First of all MSI installations are already in a in a distributable format, so there is no benefit to recreating the setup. MSI packages are full of internal references, which cannot be captured and recreated. These internal references are critical to the self-healing functionality of MSI packages and are fundamental to their operation.

Repackaging an MSI may result in uninstall problems and other Windows Installer related problems. Finally, and perhaps most important, when the vendor releases and update or patch (MSP) for the product, it will be designed to update their MSI and not yours. When repackaging, all of the globally unique identifiers (GUIDs) used to identify items in the package are regenerated and will not match up to the updates provided by the software vendor package.

There are no changes that cannot be implemented at install-time using an MST (transform) file. Aside from dictating installation preferences, you can add, delete or change any items you wish. I have had some people challenge the fact that the capabilities of MST negate the need to repackage an MSI. While the statement is certianly a fact- it can admittedly be a very difficult task to carry out when dealing with certian packages. Have you given up on MST and repackaged an MSI? Please rate the applications difficulty and provide comments in the software's Package Knowledge base entry. Fighting with a package right now? The Package Knowledge base may hold some answers for you. Also visit our package development message board.