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!

Author: Tim Mangan

Tim is a Microsoft MVP, and a Citrix CTP Fellow. He is an expert in App-V and MSIX.

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

  1. Tim,
    I’ve trying to virtualise BBFlashback 3.0 on App-V 4.6 SP1. There is a recorder & a player in this application. The player is virtualised but the recorder doesn’t open up. The previous version of BBFlashback (2.8) was successfully virtualised by me. I can’t understand why it doesn’t open up. Any suggestions appreciated.

    1. Not familiar with it. Camtasia (similar functionality) is tricky but does mostly work. Camtasia includes several codecs (not a problem) and one driver (problem), but that driver only affects minimal functionality. Does the sequencer report in SP1 show any drivers? Also, especially since I see that BBFlashback has three versions that can install side by side, you should be looking at the exclusions to see if stuff is in AppData or the like.

    2. This is the Exclusions list of BBFlashback. What should be taken from here?

      One or more files were excluded from the package because they are located in excluded paths. Missing files can cause unexpected application failures.

      The following files were excluded:
      C:\Program Files\Microsoft Application Virtualization Sequencer\Logs\sftrbt.txt
      C:\Users\App-V Sequencer\AppData\Local\Microsoft\Windows\WER\ReportQueue
      C:\Users\App-V Sequencer\AppData\Local\Microsoft\Windows\WER\ReportQueue\NonCritical_x86_8a40837b345065278d8be2f912dbaec6525d13aa_cab_0cb69a37
      C:\Users\App-V Sequencer\AppData\Local\Microsoft\Windows\WER\ReportQueue\NonCritical_x86_8a40837b345065278d8be2f912dbaec6525d13aa_cab_0cb69a37\DMI94B3.tmp.log.xml
      C:\Users\App-V Sequencer\AppData\Local\Microsoft\Windows\WER\ReportQueue\NonCritical_x86_8a40837b345065278d8be2f912dbaec6525d13aa_cab_0cb69a37\oem3.inf
      C:\Users\App-V Sequencer\AppData\Local\Microsoft\Windows\WER\ReportQueue\NonCritical_x86_8a40837b345065278d8be2f912dbaec6525d13aa_cab_0cb69a37\Report.wer
      C:\Users\App-V Sequencer\AppData\Roaming\Microsoft\Windows\Cookies\[2].txt
      C:\Users\App-V Sequencer\Documents\BB FlashBack Movies
      C:\Users\App-V Sequencer\AppData\Local\Temp\bbcap.dll
      C:\Users\App-V Sequencer\AppData\Local\Temp\bbcap.inf
      C:\Users\App-V Sequencer\AppData\Local\Temp\bbcap.sys
      C:\Users\App-V Sequencer\AppData\Local\Temp\
      C:\Users\App-V Sequencer\AppData\Local\Temp\bbchlp.dll
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackTemp
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackTemp\
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackTemp\Recordings
      C:\Users\App-V Sequencer\AppData\Local\Temp\DMI94B3.tmp
      C:\Users\App-V Sequencer\AppData\Local\Temp\FlashBackDriverInstaller.exe
      C:\Users\App-V Sequencer\AppData\Roaming\Microsoft\Windows\Cookies\[1].txt
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackBackup
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackTemp
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackTemp\Recordings
      C:\Users\App-V Sequencer\AppData\Local\Temp\BBFlashBackBackup\settings.xml

    3. The existence of the WER tells me that a process crashed when you were sequencing. WER is the “Windows Error Reporting” that reports crash data back to Microsoft so that bugs get fixed; originally for Microsoft software only, it now reports on software from any vendor. So the problem hapened while you were sequencing. You might look at the WER report or one of the log files to see what died.

      The file “FlashBackDriverInstaller” might indicate a true driver (it also might be a codec, which would be OK — you can’t tell just by the name). If a driver, pull the file from your failed install. Revert the VM, install the driver manually before starting the sequencer, then sequence. If that works, you would need to natively install that driver on the client systems to virtualize the app.

      Good luck!

  2. Hi

    I had a problem like,when iam trying to sequence Attachmate Reflection X application using App-V 4.6 SP1,it is throwing the error whereas in App-v 4.6 it is working fine.Any suggestions?


    1. There is a known issue with SP1 sequencing on Vista and above, for app installers that involve mapped or unc drives. Sequence on XP or without SP1 until we get a hotfix. Rumour is it is in the testing process and should be out “soon”. If this is your problem keep an eye out for the HotFix.

  3. At least I am not the only one. At first I thought it was the 8.3 issues creeping up again but when i removed the working directory from the OSD I could start the package however it either wouldn’t mount the SFT or the directory would be inaccessible. Going back to 4.6 sp0 for now.

  4. Hi Tim,
    I noticed some typo’s (I think) which makes the context of this article a little bit strange, especially for a non native english speeking person like me.

    > due to a new bug in App-V 4.6 Sp1, it is very important to install to C: if you can.
    But if I read the complete article, it’s best NOT to install on C: because of that bug in SP1.

    also here you say:
    >…to the asset folder on Q: rather than to see:
    you mean to “C:” instead of “see” I think, no ?


Comments are closed.