Active Setup – Solve Problematic HKCU Keys…

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

Hello fellow packagers — ever have an issue with trying to get a program to lay down the HKEY_CURRENT_USER (HKCU) keys?  Well, let’s break down how to fix this issue.  I am going to show you how to set up Active Setup within your applications MSI/MST file in order to have this HKCU stay on the machine, no matter how many users log into the system. 

Active Setup helps to lay down Current User data when an application is deployed or even installed straight from the MSI itself.  Active Setup can be set to do a repair and check for the current user keys that the application needs in order to fully run right.  I am going to show this process, as its one of the most common processes to use with Active Setup.

Windows has keys that it will look for before it kicks off the full install of the MSI.  These keys can be found under:

HKLMSoftwareMicrosoftActive SetupInstalled Components<UID>

…and also under:

HKCUSoftwareMicrosoftActive SetupInstalled Components<UID>

The <UID> should be unique, based off the application you’re using.  Now, the best value to use for the <UID> would be the Globally Unique IDentifier (GUID); I suggest using the Product Code for the GUID.  There are many options you can use for the GUID, but for this example I am going to use the Product Code for the application.  This Code can be found in AdminStudio in a few locations: General Information, Property Manager or Direct Editor->Property table (these locations might be a little different depending on your packaging tool).  Most packaging tools will still have a Property table where you can find the Product Code.  Make sure to write down the GUID you will be using, as we will need this information later on.

So let’s take a deeper look into this process, in order to make these keys no longer an issue.  Let’s begin by opening the MSI we would like to edit.  You can also use a MST transform file if you are working with a vendor MSI.   

Once the application is open you will want to navigate to the Registry section of your MSI/MST.  When you are in the Registry section of your MSI/MST, navigate to:


Under the Microsoft folder, right click the folder and select New and make a new Key, in order to make a new folder under Microsoft.  We will label this folder “Active Setup”.

You might be saying “Hey, I don’t have a Software folder under HKLM”…  This is fine, it just means we need to make one.  It’s easy as pie; you would make the parent folders the same way we did with the “Active Setup” Folder.  Just make sure you build the folder structure as indicated above.

We need to set up two more folders the same way we did with our “Active Setup” folder.  This time, however, we will name the first folder “Installed Components”, under the “Active Setup” folder.  Under the new “Installed Components” folder, make another folder and label it “ProductCode”.

Once we have all our folders set up we need to make a “New string Value” under our “ProductCode” folder.  To do this you can right click on the “ProductCode” folder and you will see the option “New string Value” under the drop down list.  We are going to label our “New string Value” as “StubPath” (Windows will run anything under the “StubPath” whenever there is a command under it).  If the current user key is already on the system, msiexec will not run the repair again because the key is already in the location it should be.

When you have your “StubPath” string created, double click it; we need to make some changes to the values in this string.  You will see the Edit Data box come up; in this box we are going to use the following commands in the Value Data field:

Msiexec /fu (ProductCode or GUID) /qn

These are what the switches are doing that you are adding to the msiexec:

/f – Repair
 /u – all required user-specific registry entries
 /qn – Silent mode with no UI.

 (For other repair options and switches I have added a link to Microsoft’s “msiexec” page:

This new key will run once the application is launched.  Make sure to test your application out, and check those keys you have made.  The best way to check the MSI/MST is to launch the MSI/MST though the command line. 

I hope this helps to clear up and issues with Current User key, and gives you a better understanding on how to fix the issue.


Basic MSI – A Simple Need (Part 2): Refresh the Desktop

2017-07-27T00:01:07+00:00 March 21st, 2012|Uncategorized|

(For background, please see Part 1 of this post)

Now that the Broadcom WIDCOMM Bluetooth Software desktop icon has been removed, we need a simple way of refreshing the desktop from within the MSI. 

The Post-Icon Removal MSI-Called Desktop Refresh

At first thought, it seemed that there must be VBScript out there that could accomplish this remedial task. 

Scouring the web turned up several suggestions, but none of them worked properly.  Some would work from a script being manually executed, but then would fail if executed through a custom action (WScript method access challenges, to name one).  Others simply didn’t work at all.  Trying to give focus to the desktop, and then using a “sendkey” function for a “F5″ refresh, wasn’t going to cut it this time either.  C code, found on the web, claimed it could accomplish what was needed; but not having much experience with writing and compiling C made it an unviable option.  The proposed solution would need to work regardless of what was open and running on the desktop during the installation.

After consulting with the Application Packaging Team at Coretek, a suggestion was proposed by Voltaire Toledo to use AutoIT to generate a script.  AutoIT “…is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting.  It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys)” ( 

It was amazing how easy it was to create the script using AutoIT.  The best part was that it worked!  Here are the steps:

    1. Download and install AutoIt v3 from the site above.
    2. Create a folder in which to store AutoIT scripts.
    3. Right click in the folder.  Under “New”,  select “AutoIT v3 Script”.
    4. Rename the script to something more appropriate.
    5. Right-click the script and choose “Edit Script”.  The AutoIt SciTE script editor will open:

Script Editor

    1. Open an “Untitled”, empty, script window on first launch.  Enter the following line of code, with any additional comments, in the editor window:

ControlSend(‘Program Manager’, ”, ”, ‘{F5}’)

Hint – As seen above, “;” delimits a comment

  1. Save the script and close the script editor.
  2. Right-click on the recently-created script and choose “compile script”.  Choose either the 32-bit or 64-bit option (depending on the architecture of the system on which the executable will be run).
  3. The resulting executable file will appear in the script folder.

Now that an executable exists that can refresh the desktop, in any one of the aforementioned scenarios, it must be added to the basic MSI’s installation routine. 

This can be accomplished using a custom action from within InstallShield.  Here are the steps:

    1. Open the existing MSI or MST in InstallShield.
    2. Create a new custom action in InstallShield:

Custom InstallShield Action

  1. Choose to run an executable from the binary table.
  2. Click the “Browse” button to browse to the executable that was created from the AutoIt script earlier.
  3. Set the script to “immediate execution” and “always execute”.  Add any necessary install conditions to control when the custom action runs (at install, uninstall, maintenance mode, etc.).
  4. Ensure that the custom action is placed in the MSI’s execution sequence AFTER the changes to the desktop have been made (the registry key has been deleted as explained in Part 1), so that the desktop refresh shows the intended changes!

Viola!  Mission achieved!


Basic MSI – A Simple Need (Part 1): Delete a Difficult Desktop Icon

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

Sometimes it’s necessary to refresh the desktop after certain actions are performed through a MSI.  It may be that the desktop background has changed, or that icons have changed and need to be refreshed, etc. 

Removing a Difficult Desktop Icon

In our particular case (and as is used in the examples in this post), Broadcom’s WIDCOMM Bluetooth Software was installed.  This example customer always removes icons from the start menu and desktop in application installers deployed in the enterprise.  This is where a seemingly simple customization became a challenging one — it’s a good thing that I’m always up for a challenge!

Normally, removing icons from the desktop would require the packager to write a script to delete “.lnk” files from the current user or “AllUsers” profile’s “Desktop” folder.  However, in our scenario, the “My Bluetooth Places” icon is unique in that it cannot be so easily deleted:

My Bluetooth Places

Thanks go out to “Scorps” at the Video Help Forums for demonstrating how to get this done through the Windows registry.  Here are the steps:

  1. Open up the registry editor (Start> Run> regedit)
  2. Browse to the following key:
  3. Delete the entire key {6af09ec9-b429-11d4-a1fb-0090960218cb}!
  4. Refresh the desktop to apply/show the changes.

With that being said, creating a VBScript to delete a registry key is relatively simple:

Option Explicit 
Dim WshShell, regKeyDelete 
Set WshShell=CreateObject("WScript.Shell") 
WshShell.RegDelete regKeyDelete


Refreshing the desktop, on the other hand, posed to be a challenge!  Stay tuned to Part 2 to see how this task was accomplished…



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.