About Derek.Socall

This author has not yet filled in any details.
So far Derek.Socall has created 3 blog entries.

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)” (http://www.autoitscript.com/site/autoit/). 

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…



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.


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


Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113