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

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!