Home > Blogs > VMware ThinApp Blog


ThinApp, the Taskbar, and Start Menu Pinning

Recently I was asked if there was a way to pin ThinApp packages to the Start Menu and Taskbar in Win 7. Well, depending upon what your desired outcome is, there are both long and short answers.

Let's dig into them here…

What is "Pinning"?
First off, what is "Pinning" in Win 7 (and Vista too)? Basically, "Pinning" is the ability for a Windows User to tack an application to the Start Menu or Quick Launch areas which the User wishes to have easy and quick access to. But, to better explain, let's first review our history of the Windows Start Menu and Taskbar.

Start Menu History
In Win XP, Microsoft gave us the Quick Launch bar and an "enhanced" Start Menu with which to better access our Windows applications. Some of our more geeky friends referred to this new look in Win XP as the "Crayola™ look" and many enterprises turned this off because at the time, this new enhancement used more resources.

ThinApp  WinXP Enhanced
Taking a closer look at the Start Menu and Quick Launch section in the below image, we see there are a number of areas such as the Pinned Apps in the upper left, the Recent Programs on the left, the main/original Start Menu as a sub-menu of "All Programs" and then the old Programs Folder Links at the top of the main/original Start Menu.

And at the very bottom in the task bar is the Quick Launch bar.

ThinApp  WinXP Enhanced Start Menu
Again, many enterprise companies turned this off as it was undesired, either from utilizing too many resources on older systems, because of unfamiliarity, because of a simple dislike, or from a combination of the aforementioned reasons. In those scenarios, the Start Menu and Quick Launch had a more simplistic Win 2k style look and feel as shown below.

ThinApp  WinXP Classic Start Menu
Pointing out a few things in the above image, you'll notice there are some things which previously existed in the Classic Start Menu (Programs Folder Links, main Start Menu with folders and links, and the Quick Launch) and some things which are missing (Recently Used Programs and Pinned Apps).

So why did Microsoft add "Pinning" in Win 7 (officially called "Jump Lists") and not just utilize the existing XP Start Menu and features?

From what I've gathered in research of this question, the shortest and easiest answer is, 3rd party application manufacturers often times abused the shortcut location placements in the Start Menu, and many times they essentially "spammed" the start menu with unnecessary shortcuts for application configurations, application uninstalls, and even advertisements. For you Desktop Administrators, how many times have you installed an application on your own system to test and NOT have it ask you if and where you want shortcuts – but instead inappropriately assume you want all of the app's shortcuts at the top of the Start Menu, in the Start Menu folders, in the Quick Launch bar, and on your Desktop? Annoying right??!

Whether you like these changes or not, don't let it ever be said Microsoft doesn't listen to their market research… ☺ …as this appears to be the primary reasons behind the Win 7 Start Menu look and feel of today. I say, "Kudos to Microsoft" (and all other software manufacturers too) for listening to customers!

For further reading on this, see the Microsoft Windows 7 Help on pinning an application to the Start Menu or Taskbar (Formally known as the Quick Launch bar) and Using Jump Lists to open Programs and Items

Also check out MSDN's Application User Model IDs .

For additional reading on this with customer "flavors", see Rick Strahl's Web Blog article, Application that won't Pin to Taskbar in Windows 7. MSDN has The Old New Thing blog which has a bunch of postings related to this, such as "Why is there no programmatic access to the Start Menu Pin List?" and "The Star Menu Pin List is just a list of items; there's no magic". Of course, one can search the MSDN blogs as well.

How does all of this play into the Win 7 Start Menu and Quick Launch bar?
One of the key features of the Win 7 "Pinning" with regards to the Start Menu and Taskbar is some additional "security enhancements" (for lack of a better term here). By this I mean, automating the display of an application shortcut within the Start Menu "Pinned Apps" area or within the Quick Launch bar is now limited, as mentioned on MSDN in The Old New Thing Blog article, "Why is there no programmatic access to the Start Menu Pin List?". So no more spamming of shortcuts in the top levels of the Start Menu. ☺

What does all of this have to do with ThinApp?
I'm glad you asked! Essentially the above history is important when it comes time to register your ThinApp packages to your end user systems.

ThinApp Registration Recap:
To quickly recap ThinApp package registration and deployment options, ThinApp Packaged Applications can be registered in one of three ways (four if you count the View Admin Console but in reality this just utilizes a programmatic connection to the ThinApp SDK):

  • Use of the Microsoft Installer: — When using the MSI created by ThinApp, the ThinApp packaged application is placed onto the local C: drive of the user's Windows system either into a subfolder of the "C:\Program Files" folder if the MSI is set to install for all users (and the user executing the MSI has permissions to do so) or into a subfolder of the "%APPDATA%" folder under the user's profile if defined to install for the single user (MSIDefaultInstallAllUsers=0). Among other reasons, this is very useful for systems which are not always attached to the corporate network.
  • Use of the THINREG.EXE utility: — When using the THINREG.EXE utility (usually through a script), the ThinApp Packaged Application is registered where it resides. In other words, if all of your ThinApp Packaged Applications reside on a network share and you use THINREG.EXE in a login script or GPO to register them to users, then they are registered where they reside and are NOT copied to the local Windows C: drive. This is very useful for systems attached to the corporate network whether they be physical, virtual, or remote desktops.
  • Use of the ThinApp SDK: — Using the ThinApp SDK is generally a more programmatic approach as the ThinApp SDK must be loaded and registered on the end user workstation (a single ThinAppSDK.DLL file) and something must call the objects it loads into Windows memory – whether that be a script or program of some kind. Either way, the end result is the same as the aforementioned THINREG.EXE utility. The ThinApp Packaged Application is registered where it resides (usually – but I won't go into this here as it's not relevant to the discussion at hand). Use of the SDK is useful for not only registering and unregistering the ThinApp Packaged Applications, but also many other things such as AppSync on the fly.

This is good information, but why can't I pin some ThinApp packages to my Start Menu or Taskbar?

Knowing how ThinApp Packaged Applications can be registered and how Windows "Pinning" works will help you plan your ThinApp deployments.

Windows "Pinning" Limitations:
Referencing the MSDN article, "Application User Model IDs (AppUserModelIDs)" we see there are certain applications (executables or shortcuts) which cannot be pinned to the Start Menu or Taskbar. By default, these are as follows.

  • Files with the following strings in their names:
    • Documentation
    • Help
    • Install
    • More Info
    • Read me
    • Read First
    • Readme
    • Remove
    • Setup
    • Support
    • What's New
  • The following executables:
    • Applaunch.exe
    • Control.exe
    • Dfsvc.exe
    • Dllhost.exe
    • Guestmodemsg.exe
    • Hh.exe
    • Install.exe
    • Isuninst.exe
    • Lnkstub.exe
    • Mmc.exe
    • Mshta.exe
    • Msiexec.exe
    • Msoobe.exe
    • Rundll32.exe
    • Setup.exe
    • St5unst.exe
    • Unwise.exe
    • Unwise32.exe
    • Werfault.exe
    • Winhlp32.exe
    • Wlrmdr.exe
    • Wuapp.exe

We also know any application which does not reside on the local system drive will not be allowed to be "pinned" to the Start Menu or Taskbar. Not even a SHIFT+Right-Click will get you an override option for these applications (Note the UPDATE section in the linked article).

And, among some of the other limitations, 3rd party software manufacturers can also define their application to not be "pinned" by use of some extensible settings in the registry (see the MSDN article, "Application User Model IDs (AppUserModelIDs)" for additional details here).

What do these Windows limitations mean for ThinApp?
Bottom line, any application not residing on the local system drive cannot be "pinned". This means any ThinApp Packaged Application residing on a network share and registered with THINREG.EXE or the ThinApp SDK will not be allowed to be "pinned" because they do not exist on the local system drive.

However, any ThinApp package residing on the local system drive, whether manually copied and registered (using THINREG.EXE or the ThinApp SDK to register the local ThinApp package executables) or installed and registered using the ThinApp Package's MSI, will be allowed to be "pinned" to the Start Menu and Taskbar.

So I understand all of this and it makes sense. Is there a way to automate the "pinning" of applications?

Keep in mind the previously mentioned article regarding no programmatic access to the Start Menu Pin List, there are some scripted options which may be of assistance.

Here is an example VB script which will both enumerate the application's verbs and pin and unpin the application from the start menu if the "Pin to Start Men&u" and "Unpin from Start Men&u" verbs are available.




AdminScriptEditor Script Conversion


'DECLARE SYSTEM VARIABLES
Set objShell = CreateObject("Shell.Application")
'DECLARE SCRIPT VARIABLES
Dim Folder, Executable
Folder = "C:\Users\ThinApp\AppData\Roaming\Mozilla Firefox 5.0.1 (XP Pro) (VMware ThinApp)"
Executable = "Mozilla Firefox.exe"
Set objFolder = objShell.Namespace(Folder)
Set objFolderItem = objFolder.ParseName(Executable)
'COLLECT APPLICATION VERBS
Set colVerbs = objFolderItem.Verbs
'USE THIS CODE TO SHOW WHAT VERBS ARE AVAILABLE ON THE SELECTED APPLICATION
For Each objVerb In colVerbs
If objVerb <> "" Then
WScript.Echo objVerb
End If
Next
'FIND PIN/UNPIN VERBS AND EXECUTE
'NOTE: If not Pinned, script will Pin. If Pinned, script will Unpin.
For Each objVerb In colVerbs
If Replace(objVerb.name, "&", "") = "Pin to Start Menu" Then
objVerb.DoIt
WScript.Echo "The application '" & Executable & "' was just Pinned to the Start Menu."
Else
If Replace(objVerb.name, "&", "") = "Unpin from Start Menu" Then
objVerb.DoIt
WScript.Echo "The application '" & Executable & "' was just Unpinned from the Start Menu."
End If
End If
Next


Download the Start Menu Pinning VBScript.txt script.

Techibee.com also has a good PowerShell script for accomplishing "pinning". To note though, I've not tested this so use at your own risk. For that matter, all scripts are unwarranted and should be thoroughly tested prior to any production use.

Additional warnings: Your Mileage May Vary when using scripts so please test thoroughly and remember, use at your own risk as you are responsible for your network and system uptimes. ☺

Wrap Up:
Hopefully this will provide you with some answers around "Pinning" and why sometimes you can pin a ThinApp packaged app and sometimes you can't.

This entry was posted in Applications, Integration, MSI, Scripts, Tips, Troubleshooting and tagged , , , on by .
Dean Flaming

About Dean Flaming

Dean is currently an EUC Architect and member of the VMware End User Computing Enablement and Lighthouse Support teams, working to develop communications and IP around VMware End User Computing products and solutions as well as support many various Lighthouse accounts with their own EUC practices. Prior to this, from 2008 through 2012 Dean was one of VMware's End User Computing Specialists. Throughout his time at VMware, Dean has also written and published various articles, videos, and podcasts regarding VMware's EUC Solutions.