Monthly Archives: May 2011

XenApp Publishing Extensions 3.0 for XenApp 6

A year ago I released XenApp Publishing Extensions 2.0 for use with XenApp 4.5 and 5.0. This free GUI based tool simplifies App-V virtualized application publishing for XenApp. The tool used the traditional mfcom interface for working with XenApp, and did not work with XenApp 6.

Today, I am releasing version 3.0 for use with XenApp 6. While the front end GUI and functionality remains the same, the back end has been completly replaced to use the newer PowerShell interface to XenApp 6. (Note: although XenApp 5 has both mfcom and powershell, the powershell interface changed significantly enough that this updated tool will not work with XenApp5 so please use version 2.0 of this tool for the older versions of XenApp). This tool will be demonstrated at my session at Synergy on Friday at 9AM (SYN337).

What is the purpose of the tool? Simply put, it uses the information that app-v already knows to help with the application publishing under XenApp – especially in locating the correct icon to use.

You can find the tools at
    XenApp Publishing Extensions 2.0 for XenApp 4.5 and 5.0

    XenApp Publishing Extensions 3.0 for XenApp 6

Both versions are free.

Sequencing Skype on Windows 7

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

App-V & Installing to the (Q:\) Asset Folder or Not: a 4.6 Sp1 Bug Uncovered

App-V: Installing to the (Q:\) Asset Folder or Not

NOTE: The issue with the 4.6 SP1 sequencer that is identified in this article appears to have been fixed when sequencing using the 4.6 SP1 HF3 sequencer.

The “Best Practices” for sequencing applications with App-V, and SoftGrid before it, have always included installing the application to the “asset folder” (sometimes referred to as the “root folder”) on a secondary drive rather than the normal location selected by most programs, a folder under “C:\Program Files”. The default letter for this secondary drive is Q:, so I will refer to it as Q: in this post even though you might be using a different letter in your organization.

I teach sequencing in my classes to follow this best practice; install the app to be virtualized to the Q:\ Asset folder if at all possible. But for quite a while I have been privately sequencing apps for non production use to C:\Program Files to see just how valid this advice is. In this post I’ll discuss what happens when you install to C: rather than Q: in detail, but the short summary is that, due to a new bug in App-V 4.6 Sp1, it is very important to install to Q: if you can.

Traditionally, there have been two reasons given to install applications being sequenced to the asset folder on Q: rather than to see:

  • Hard Coded Paths
  • Performance

It is the job of the sequencer to comb through the installed assets of the package to locate and translate information to make the software as machine, OS, and user independent as possible. This is a difficult task to perform. Applications can store such information in so many ways and in so many locations that it is impossible for the sequencer to find them all, but over the years the end results of sequencing have become much more successful than what we achieved in the early days of SoftGrid. This is because application installers have become more standardized (making it easier to find such data) and the sequencer has gotten better at finding it. The sequencer maintains a list (parse items) of strings to look for. It looks for modified folders and files with file paths that match these strings. It also looks inside certain file types for these strings. And it also looks at registry keys and inside registry values. When it locates such a string, it replaces the string with something like a variable in the saved package. These “variables” are seen in the completed package as strings starting with CSIDL_ (or sometimes other things like SFT_MNT). So for example, if the application installs to “C:\Program Files\Adobe”, this is parsed and stored in the package as a folder “%CSIDL_PROGRAM FILES%\Adobe”. This supports independence because it allows such a package to be run on a client where Windows is installed to the D: partition instead of C:. At such a client, the client will re-map the CSIDL variable to the folder appropriate for that machine, so the folder in the virtual environment on that client would look like “D:\Program Files\Adobe”.

The CSID in CSIDL stands for “Common System Independent” (the “L” either stands for “Link” or “List” depending on what reference you find), and is an older technique that Microsoft came up with for software developers to write system independent code. Microsoft has since deprecated it’s use for developers and replaced it with a similar concept called “BaseNameFolder”.

In regard to performance, it is claimed that by installing to C: and having a VFS’d file reference, the performance of the virtual application is affected due to an additional redirection that occurs. I have always found such claims as questionable and have never detected such a performance difference in the applications where I have tried to verify this claim. Some people have claimed to have seen a difference in a particular application, but it is not clear to me that additional factors were not also in play to affect performance, so I remain very skeptical about such claims.

Because installers and the sequencer have improved so much over the years, I began an experiment to try every application I test as a C: installation to determine if the Q: install is really needed as the best practice any more. These tests were not going into production use, but just to test out whether they would actually work. In almost two years of sequencing, I did not find a single application that experienced a problem with a C: install. Most of these applications were small, and were common and popular applications. Large, complex, applications, those involving many integrations between applications, and custom built (“in house”) applications might have different results. But it was surprising to me that I did not run into a single application with an issue. While I have been including information about my experience in seminars and my App-V classes, I have always been clear that the best practice remains to install to Q: (unless you have an app that exhibits a problem with the Q: install).

The 4.6 SP1 Sequencer (and possibly Client) Problem

In the most recent training class, we had a student install a package being sequenced to the more natural C:\Program Folders location. We were using 4.6 SP1, and the package ran fine at the client as expected.

But later on in the class, the student tried to perform a package upgrade to this package. The student was attempting to make a “branch” update, however I later determined the same issue applies to an “active upgrade” scenario. As I will describe, although we didn’t follow “best practices” in the original installation, clearly the behavior for upgrade is broken. And certainly, there are applications which must be installed to C: and given the issue uncovered it is quite clear that it will be impossible to upgrade these applications.

If you open a C: installed package on the 4.6 SP1 sequencer for upgrade, when the virtual environment is opened up (you are in monitoring mode), you will not see the folder for it under Program files. Further more, if you save the “upgraded” package without making any changes, as an active upgrade or as a branch update (assigning a new package name and asset folder), and try it on a client the app will fail, because the client also does not see the file through the C:\Program Files reference. In fact, the package is even more broken. Open up a command prompt inside the virtual environment on the client and perform a directory listing of C:\Program Files, and the list will terminate when it runs into the place where the redirected directory should be located (so in our case this command prompt listed only two folders as existing under C:\Program Files when there were a dozen on the client, plus our extra virtual one).

This behavior does not occur with a package sequenced and upgraded with 4.6, or older versions of App-V. And while we were doing something outside of best practices, there are applications that must be installed to C:, so this clearly is a bug that now prevents such applications from being upgraded. Until the problem is addressed, the only thing to do is to re-sequence the app with the upgrade from scratch.

What is particularly aggravating is that you won’t find this problem until months or years down the road when you try to upgrade such a problem package. Hopefully, Microsoft will provide a hotfix, but I am really concerned that it is the original package with the problem. As a test I tried a very unsupported method of opening the 4.6 SP1 generated package of the virtual app installed to C: in a 4.6 sequencer for upgrade and found the same behavior. So the problem appears to be how the 4.6 Sp1 sequencer stored the information. Because of this, I hope that Microsoft fixes this sooner (before too many packages get generated that have a hidden bomb in them) rather than later.

So I guess that I now need to add a third reason to my list of reasons to install the sequenced application to the asset folder:

  • Hard Coded Paths (in a few very rare apps)
  • Performance (unsubstantiated claims)
  • Microsoft Testing apparently covers only “best practice” methods

Thanks to Mark Carson for helping us uncover this issue!

White Paper: Perceived Performance Reloaded

Today I posted a new whitepaper associated with the Perceived Performance presentation I made at BriForum London yesterday.  We had a great session with a diverse eupoean crowd in attendance.I wish I had another name for this than a “white paper”, because most of what we see in white papers today are just blatant product pitches with a technical description.  This is more of the traditional white paper (although with a few color illustrations) that just talks about technology.

Perceived Performance is the term I use for a different way of looking at performance of computing systems, looking at it from the end user perspective.  In this paper, I update the original concepts for Perceived Performance that I described in the 2003 and 2005 versions of the whitepaper to look at performance in VDI scenarios today, with some thoghts to how cloud computing affects thsi again in the future.