In our App-V Masters Level Training Classes we invite students to bring in some of their own “interesting” applications to sequence. While the class includes labs that use standard apps highlight certain aspects of sequencing, we try to leave time for students to sequence without a script in front of themselves – we find that students learn the lessons the best when they try it on their own after being “trained” and making mistakes.
In our most recent class, one of the students brought in Skype. Skype is a reasonably behaved application, but he was having an issue with sequencing on Windows 7 back at his office and brought it in because it uses out an unusual form of shell extension that he couldn’t figure out and it required a creative work-around.
Windows 7 is different than prior operating systems in that it has what Microsoft refers to as the “jump list”. This is a collection of new features that you can notice in the task bar of the Windows Desktop. The most obvious of these features are pinning, and the mini app display if you hover the task bar item of an app that supports it (the miniture display of minimized apps that appears for some apps). Jump list also supports new context sensitive menus on the task bar that apps can take advantage of. The student was sequencing Skype version 5.3.32.108, which includes a custom context sensitive menu for the task bar.
If you launch this version of Skype on Windows 7 and right click on the Skype icon on the task bar, the menu looks like this:
The “Quit” item on this menu appears whether or not you sequence the application. Natively installed, this Quit works as expected, but when sequenced and running in the client, the student found that he received an error from the Skype application:
Note that the error happens from Skype and not the App-V client. The App-V client log and Windows Event log do not record the error, even with App-V client logging set to verbose.
The error looks like something outside the virtual environment attempting to access the skype executable inside the bubble — something it cannot do. And indeed that is what is happening.
If you are thinking that enabling the “LOCAL_INTERACTION_ALLOWED” policy for the app might help, you would be wrong. We tested this and still had the error.
Searching the application (both GUI options and registry) to try to configure the app to not show the Quit menu was unsuccessful; there does not seem to be a way to configure it off.
Another student listening to the problem had a great suggestion. Since the app behaves differently on older OS’s, he suggested trying the standard application compatibility shim to trick the app into thinking it was running on an older OS.
App-V supports the ability to set file properties on executables that are stored in the file “alternate stream”. This includes setting the standard shims for application compatibility mode. So in the sequencer, the Skype.exe properties were changed as shown below:
This was saved into the package and tested at the client. The Quit menu no longer appeared on the start bar, and in simple testing the app appeared to work OK (additional testing will be needed).
As a note, I’ll mention that App-V also has limited support for custom shims generated using the Microsoft Compatibility Toolkit. The difference with custom shims is that you must not only apply them to the sequence, but you must deploy the shim natively to the client machine to get them to work with App-V. Microsoft’s Chris Jackson has some blogs that discuss and show this technique.
Thanks to Tim Glickman for working through this app, and Chris Patton for the awesome suggestion on app compat!
Hi,
That really is a creative way for solving it. Though it has some disadvantages. If wanting the App Compat to apply you would have to start the App-V bubble as an admin. Which in most environments is not suggested or even allowed. Also UAC will ask you to elevate everytime you start the app.
Any extra workarounds for this? 🙂
Greets,
Stijn