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.
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.
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.
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:
- More Info
- Read me
- Read First
- What's New
- The following executables:
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.
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. ☺
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.