Installing HKCU keys using a Windows Installer repair, Pt. II

2017-07-27T00:01:04+00:00 March 27th, 2013|Uncategorized|

Previously, in Pt. I of this series, I wrote about how to install HKCU registry keys (which can also be used for installing data anywhere in a user profile).  Now I’ll go into more depth on how to do this using the popular application packaging product Wise Package Studio.

Though Wise Package Studio has been discontinued by Symantec, it’s still quite popular in many packaging environments.  The main tool used for creating and editing Windows Installer projects in Wise Package Studio is the “Windows Installer Editor”, which was previously available alone as “Wise for Windows Installer” (wfwi.exe). 

Most of the packaging work will be done in the “Installation Expert” view, which is a slightly more “user friendly” or “cleaner” project editor.  After creating my new project, I’ll add a couple files to it.  The files I added are Process Explorer (procexp.exe) from “SysInternals” and it’s help file (procexp.chm).  Process Explorer is one of several extremely useful utilities available (free!) in the Sysinternals Suite

 

1.Wise

 

Next, I’ll add an “Advertised” desktop shortcut to “procexp.exe” from the “Shortcuts” page.  By default, when you add a shortcut to point to a file in your installation the “Advertised” check box is marked. 

 

2.Wise

 

Note that “Complete” is listed in the “Current Feature” drop down list.  By default, Wise starts with a feature named “Complete” and puts all files, registry keys, shortcuts, etc. under the “Complete” feature, but we need a “hidden” parent feature.  So, from the Features page “Add” a new feature.  Give it a name, select “<None>” from the Parent drop down list, “Hidden” from the Display drop down, and check the “Required Feature” check box; the rest of the defaults can be left.  After adding the hidden parent feature, I go into the “Complete” feature to select the hidden feature from its “Parent” drop down list. 

 

3.Wise

 

Finally, I add an HKCU registry key to the new hidden feature.  Notice now that I’ve added a new feature, I can select it from the “Current Feature” drop down list from all the pages in Installation Expert. 

 

4.Wise

 

After the project is compiled, the .MSI can be run on any system “per machine” with the “ALLUSERS” value set to ‘1’.  When a new user logs onto the machine and clicks on the advertised shortcut, the HKCU key will be installed by the windows installer repair. 

 Next time, I’ll take a look at implementing self repair using InstallShield.  I hope you found this tutorial enlightening, instructive, and maybe even a little fun.  Well..uh..instructive and enlightening should be good enough! 

 

 

 

Installing HKCU keys using a Windows Installer repair

2017-07-27T00:01:04+00:00 March 13th, 2013|Uncategorized|

One of the more common (and tricky) issues faced when installing an application in the enterprise is how to install user data.  Typically, the application installer is run silently with no user interaction in the “system” context with administrative privileges.  This method is commonly used so that the software can install in the background without disrupting the end users work.  Fortunately, this method works for a majority of software deployments, because the installer does not need to install anything in the “user” context. 

There are situations, however, when an application requires registry keys or some data files installed in the user’s profile prior to the applications first launch.  One common post-installation method used for installing user data is called “Active Setup”; a full explanation of how to implement this method is beyond the scope of this post… and besides… there’s already been a blog post on this topic

A major drawback of the Active Setup method is that any user logged on to the system when the silent installation occurred must log out of their profile and log back in.  The reason is because the mechanism which initiates Active Setup compares a Local Machine registry keys to one in the User’s profile when the user logs on.  A more convenient and functional method (and slicker, I must say) to install data to the user profile in the user context is by initiating a Windows Installer repair. 

By design, Windows Installer initiates “self repair” or “self healing” when an entry point to the installed application is launched.  Typically, the entry point is an “Advertised” shortcut.  When the user clicks on the shortcut, Windows Installer will perform an integrity check to verify all the “key paths” of the installed application are present; if not present, the Windows Installer repair will install any missing component(s) and their key path.  The key path of a component is typically a file or shortcut. 

One  method for installing Current User registry keys post install is to add a top level “Hidden Feature” (note: the feature doesn’t really have to be hidden, but we do this to ensure that whoever runs the install doesn’t have the option not to install it) to the install which contains all the HKCU keys.  Mark the feature as “required” and make it the “Parent” feature to all other features in your MSI.  Move all HKCU keys to the same component in the required feature.  Finally, add an “advertised” to your application to facilitate the repair.  After the application is installed (in the system context), when a user click on the advertised shortcut a self repair will occur to install the components with the missing key paths… IF the key path doesn’t exist.

Ya see…this blog post was partly inspired by a setup I encountered on a customer location which attempted to use this method for installing the required HKCU registry keys.  When I tested the application, it was not behaving as expected.  I looked into the .MSI that installed it and found that everything had been laid out according to the prescribed method detailed above… except… the component key path holding the HKCU keys was actually an HKLM registry key which already existed on my system!  Thus, the self repair would never “kick off”.  When attempting to initiate a controlled Windows Installer repair, you must ensure the component key path is truly unique, or the repair won’t happen. 

I hope you enjoyed this little insight into Windows Installer and find this method to install user data helpful.  This was just a high level overview; next week, I’ll follow up with a more detailed post on how to implement this functionality. 

 

 

Don’t Rename Vendor-Provided .MSI Files…

2017-07-27T00:01:04+00:00 December 5th, 2012|Uncategorized|

When packaging an application for deployment in the enterprise, you must also identify it’s dependencies — additional software required for the application to successfully install and function.  Often times these dependencies are redistributable run-times for Microsoft Visual Studio.  These redistributables are so common, they are often packaged separately and “chained” to the dependent application.

This method of installing dependencies usually works pretty well; the deployment tool determines whether to install the package, based on it’s previous installation history.  If, however, the dependency was installed outside the deployment tool’s domain — by an application a user downloaded, for example  — you may encounter errors when the dependency is re-run; this could fail your entire application package chain.

Fortunately, many (but not all — always test!) Microsoft redistributables, like “Visual C++ 2008 SP1 Redistributable Package (x86)“,  are authored so that they can install over an existing install — without actually modifying anything or going into “maintenance mode”.  The screen shot below illustrates that the Windows Installer services runs the .MSI package, and verifies that it’s already installed with the same product code, package code, component IDs, etc., and simply exits without modifying the existing install.  This can be a packager’s saving grace in an unpredictable enterprise environment.

 

Wise Compatibility Key

 

Recently, however, I came across an issue with my philosophy of simply letting the redistributable re-run over an existing install. 

A package I had developed started failing.  After checking the logs, I noticed the failure occurred during the install of the dependent runtime  “Visual C++ 2008 SP1 Redistributable Package (x86)”.  The runtime install was exiting with a Windows Installer general failure code of “1603”. 

A look at the detailed installation log shows a more confusing error: “Error 1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi”.

With some help from my co-worker (Windows Installer guru Urb Bernier) we were able to find the issue: the .MSI that originally installed the Visual C++ runtime was extracted from the vendor’s .EXE bootstrap and…RENAMED!  A grievous offense in the application packaging world!  Well, that may be a bit dramatic, but it certainly violates all “best practices”.  When extracted from the vendor provided setup file “vcredist_x86.exe”, the .MSI is named “vc_red.msi”.  Perhaps the packager may have renamed the file in order to distinguish the 32-bit setup file from the 64-bit setup? 

The error “1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi” is Windows Installer’s way of saying it can’t access the file in the path; the “cached” path to the .MSI that originally installed the Visual C++ runtime.

You see, the issue is that you can rename the .MSI, install it successfully, re-run it successfully, and uninstall it successfully; provided you do all of these actions using the renamed .MSI.  If, however, the actual vendor install runs on that same machine, whether from the bootstrap .exe or from the extracted .MSI, it will exit with a Windows Installer general error code “1603”.

Packaging applications can sometimes be a frustrating task; because no matter how much forethought and care you put into your package, it can always be thwarted.  To be fair, I guess the same could be said for just about any other job.  

However, I hope this example illustrates why you should not rename vendor provided .MSI files!

 

Thinking Outside The Bundle…

2017-07-27T00:01:07+00:00 June 6th, 2012|Uncategorized|

Once you’ve honed your packaging skills, and created some cool application bundles; you’re not done yet.
 
Having a great bundle installation without the ability to cleanly remove that bundle is like having a powerful engine in a motorcycle… with no brakes.  Oh sure; it’s great as long as you’re going forward, but if you need to stop and make changes (for example, if you have to change enterprise mail system clients), you just might have no choice but to re-image every motorcycle.  Okay, that’s where the metaphor breaks down a bit, but you get my point.
 
Anyway, here are a couple issues that I see as important that — if left unattended — could really grow into larger problems.
 
The bundle “Uninstall” – one should put as much effort in testing and implementing “best practices” for the bundle UNinstall as we do for the install.  By default, a bundle’s uninstall actions are simply the Install actions in reverse; this is OK for simple bundles, like a bundle that installs only one .MSI.  However, many bundles are more complex.  Ensuring your bundle uninstalls without error is also important.
 
I disable the default “Uninstall” action for most of my bundles and add custom uninstall actions to avoid errors, especially for bundles that install dependent bundles (I generally leave dependent bundles installed).  This leads me to…
 
Dependent bundles – I think most packagers are aware that it is a best practice to determine an application’s dependencies and, whenever possible, bundle the dependencies as standalone bundles to allow the software deployment/management system (for example, ZCM) to manage them.  This will reduce errors when an application attempts to install a package that is already installed or uninstall a shared dependency; it also saves time.
 
If you keep these things in mind, you can get on your bad motorbundle and ride…  and stop when you want…
🙂
 
 

Windows Installer Verbose Log Analyzer…

2017-07-27T00:01:08+00:00 March 7th, 2012|Uncategorized|

All software packagers know that an installation log file is critical for understanding and analyzing the behavior of an installation package, particularly with Windows Installer .MSI packages.  Many, however, are not aware of a very helpful utility that can be used to help read log files.

Microsoft provides a tool called “Windows Installer Verbose Log Analyzer” with the Windows SDK for Windows 7 and .NET Framework Service Pack 1.  The log analyzer, WiLogUtl.exe, provides a graphical interface that allows you to interact with the log and presents critical installation information in an easy to read format.

 

 

The entire SDK is approximately 1.4 GB; but if you only want to install WiLogUtl.exe, as well as a few other handy utilities like Orca, select only Win32 Development Tools on the Install Options install dialog.  By default the log analyzer is installed to C:Program FilesMicrosoft SDKsWindows

[version number]BinWiLogUtl.exe.

One particularly handy feature of WiLogUtl.exe is the ability to view a log file in an HTML format.  This special format presents the installer actions in a color coded layout which allows you to easily distinguish errors from custom actions, standard actions and other information in the log.  The interface includes buttons to quickly navigate through the log.

 

Another very useful feature of the log analyzer is the Property button, which allows you to see all the installer properties and – more importantly – their values, in one window.  Often times unexpected installation behavior can be attributed to incorrect property values.

 

 

The States button provides a view of the installation’s features and components; also very handy.

 

Understanding the root cause of unexpected installation behavior and resolving it can help ensure that your package won’t cause problems in production – and the Windows Installer Verbose Setup Log Analyzer can help save time doing it.

 

 

Basic MSI – Public_Property as Component Install Location

2017-07-27T00:01:08+00:00 February 1st, 2012|Uncategorized|

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!

 

Logging Windows Installer transactions…

2012-01-04T23:42:41+00:00 January 4th, 2012|Uncategorized|

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: HKLMSoftwarePoliciesMicrosoftWindowsInstaller
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!