Posts Tagged ‘Bundling’

Basic MSI – Public_Property as Component Install Location

February 2nd, 2012 by Derek Socall | No Comments | Filed in Application Packaging, Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

Sometimes enterprise level packaging can be quite complex, having requirements for variables, sources, destinations, etc., that are all over the map — and all over the network. 

For instance, what if you are working with application bundle files in an MSI that are not intended to be local to the device?  In that case, how does one use a “public property” that contains a path to a network drive as the destination for files to be installed in a basic MSI?

Well, that leads us to this item from Kathy at the Flexera Community Forum:

“If you’re installing the file through a component, you can use a type 35 custom action sequenced after CostFinalize to set the destination folder for the component to the value in the property.”

This translates to using a “Set Directory” custom action.

Steps:

  1. Create a new component.
  2. Under the new component, create a folder under a location that will always exist (such as under the INSTALLDIR/TARGETDIR location).
  3. Add any files needing to be installed to said folder.
  4. Create a public property with the full destination path as its value (where you want the files to end up eventually).
  5. Create a “Set Directory” custom action.
  6. Source of the CA is the directory created in Step 2.
  7. Target of the CA is the public property created in Step 4 (inputted as [PUBLIC_PROPERTY]).
  8. Leave the rest of the CA choices as the default options aside from the “Install Execute Sequence”.   Change the setting to “After CostFinalize”. 
  9. Complete the CA with default options.

The public property can be populated through many different means (a VBS, command-line, etc.) making it quite flexible.  The files will install to the location specified in the public property!

 

Did you like this? Share it:

Tags: , , , , , , , ,

Logging Windows Installer transactions…

January 5th, 2012 by Paul Opper | No Comments | Filed in Computer Support, Desktop Management, Desktop OS, Microsoft, Windows 7

Building and deploying Windows packages in enterprise deployments can be a challenge when it goes smoothly, but especially difficult when the package deployment hits bumps in the road.  Just when you think you’ve got that application perfectly bundled, tested, and deployed, an unforeseen interaction can knock the legs out from under you.

And of course, the behavior of  Windows Installer itself can be frustrating and may even seem a bit mysterious; making app deployment even more of a challenge.  The installer follows very explicit rules for everything it does, and enforces them rigidly.  Creating a log file for an .MSI installation might just be the saving grace – providing insight when troubleshooting installation errors and other unexpected behavior.

Most application packagers are aware that a verbose log file can be can be generated by passing the parameter /l*v install.log to the Windows Installer engine  (msiexec.exe).  But what about when Windows Installer unexpectedly initiates a “self repair”, or errors occurs during an application uninstall?

Here’s one thing that can help:  There is a registry value that can be set which causes all Windows Installer transactions on a system (installs, uninstalls, repairs, etc.) to be logged to a file.  Just add the following key to the registry:

Warning:  Don’t goof around in the registry if you don’t know what you’re doing.  Seriously.  Don’t.

Registry key: HKLM\Software\Policies\Microsoft\Windows\Installer
Value Name: Logging
Value Data (Reg_SZ): voicewarmup

Note that which temp directory the log file is created in depends on the user account under which the Windows Installer transaction was run.  All the relevant information is logged: custom actions, property states, feature states, and error codes.  These can be very helpful in resolving the issue!

Did you like this? Share it:

Tags: , , , , ,