Old habits die hard - Q: drive discussion resurrected with App-V 5

Note: all the information in this article is based on the publically released App-V 5 Beta 2 bits (available on connect) and may be subject to change in the final product.

In the past I’ve had many discussions with Microsoft, MVP’s, peers, customers and students about the need for installing to the Q: (Asset Folder) and many people, like Falko Graefe and Tim Mangan have written about it on their blogs. Microsoft’s best practice is to install to Q: and there are several reasons to do so. However they are also debated. Like the infamous performance decrease if one would install to C; which was never measured nor proven. Or like the increased success ratio of virtualized applications.

While talking to some of the attendees after a presentation I did last week we had a nice discussion on the topic in relation to the upcoming release of App-V 5. Making Microsoft’s best practice questionable.

Anyone who has been looking at, hearing of or seeing some the goodness of the upcoming App-V 5 release may have noticed that many things are different. One of them being the package format. Where the App-V 4.6 format was proprietary and had application metadata located externally in the package directory, the App-V 5.0 format is open (extended ZIP) and has all the relevant information inside a single file. This primarily makes the App-V 4.6 and 5.0 format incompatible for their clients, meaning that an App-V 5.0 client is unable to read and apply an App-V 4.6 package and vice versa.

Because Microsoft realized that re-sequencing an entire application landscape isn’t a good marketing pitch they have delivered a legacy package converter with the sequencer, which is operated through PowerShell. The converter is available in two flavors:

  • Test-AppvLegacyPackage (which test the legacy package for warning and errors)

  • ConvertFrom-AppvLegacyPackage (which actually convert the package, but also includes the warnings and errors)
clip_image002

Question that automatically raises is: “What will be the success rate of the conversion process?”

Because no application (nor package) is the same and the administrator may have customized it heavily, it is very hard to do an automatic conversion of one format to another. Therefor it won’t come as a surprise that there are some small caveats to the conversion process (which are also reported if applicable). Let me explain some of them.

OS Value

Microsoft App-V 5 is not supported on operating systems older then Windows 7 and Windows 2008 R2. This means that the converter actively checks if the <OS VALUE> is set and if unsupported operating systems are found, the following error is raised:

The package converter detected one or more applications in your package that is targeted for an unsupported operating system. This package cannot be converted unless the target operating system restriction is removed from the .osd file.

Having an OS limitation in the package doesn’t actually mean that the package won’t work on the target OS, but Microsoft wants to make sure that you manually configure this setting and most importantly test the application!

If you feel confident: OSD files can be batch-converted through scripting. An example of a powershell script can be found here: http://blogs.technet.com/b/appv/archive/2012/04/03/a-script-to-allow-easy-testing-of-your-app-v-package-on-any-os.aspx

Dynamic Suiting

If an OSD holds the <DEPENDENCIES> tag (used for Dynamic Suiting Composition) this will not be converted and will display the following warning:

This package has a dependency on the following package(s). To re-link these packages, apply an app connection group: Package: Camtasia.600.sft, Guid: 75AF56CD-62F3-4CB5-9097-8CC8CBB9E12D

Important: warning messages in the conversion process will still result in a converted, but slightly adjusted, package, whereas errors don’t convert the package at all.

To be fair, I can understand why Microsoft left this out. DSC has been replaced by Connection Groups and they are implemented quite differently. DSC was implemented in the package where connection groups are configured in the infrastructure environment or on the client. There’s basically no way to automate this process.

Scripts and Registry

The legacy package converter doesn’t migrate any <SCRIPT> or <REGISTRY> tags that are part of the package and gives the following warning:

The package converter detected the following script(s) in the legacy package. The script was not converted into the package. Please evaluate whether the script applies to the new package. Instructions for how to add scripts into an App-V 5.0 package can be found in documentation.

The package converter detected but did not convert the following registry variable(s) in the legacy package. If the package does not function correctly, consider manually implementing the registry variable override via policy.

As scripts or registry have deliberately been added to the package by the engineer, it’s probably well documented why this script needed to be applied (yeah right). At least hopefully someone can remember and identify if the script needs to be applied to the new package.

Important: these tags now end up in the manifest.xml file inside the package or can be overruled by the Deployment or User configuration xml files outside the package file. This does bring a small functional change to the table: 4.6 scripts and registry tags could differ per application (OSD file) but in App-V 5 they can only be implemented per package. This architectural change might have influence on the application and/or script behavior.

So what’s the link to the Q: drive discussion?

Well, basically Microsoft recommends that all applications are preferably sequenced to Q: and that only exceptions should be installed to C:. And you are probably also aware of the fact that App-V 5 no longer requires (or actually has) a Q: drive. From what I’ve seen from the conversion process I would like to argue that sequences that are NOT sequenced to Q: are more likely to work after conversion to App-V 5.0.

Allow me to explain: the 4.x sequencer would replace common locations with App-V variables (CSIDL_*) as much as possible. However this was limited to values in for example the registry and environment variables.

Environment Variables

If a package would for example extend the PATH variable with [C:\Program Files\Common Files\Application] because it has installed some dll’s at that location, the sequencer would pick that up and replace it with %CSIDL_PROGRAM_FILES_COMMON% variable.

<ENVLIST>

<ENVIRONMENT VARIABLE="PATH">%CSIDL_PROGRAM_FILES_ COMMON%\Application</ENVIRONMENT>

</ENVLIST>

The legacy package converter recognizes this variable and replaces it with {ProgramFilesCommonX86} in the Manifest.xml files.

<Include>

<Variable Name="PATH" Value="[{ProgramFilesCommonX86}]\Application" />

</Include>

And on the client this is resolved to the corresponding (virtual) directory in the VFS:

clip_image004

Note: this does not guarantee that the application will actually work, like in the example below:

clip_image005

Configuration files

Many applications save configuration in designated files and not in the registry. Unfortunately the
sequencer is unable to detect those text-based files and replace them with variables, like in the example below:

clip_image006

Just like the sequencer, these files are also not picked up by the converter and the file is identical after the conversion. Because it holds a location that is not available, the package will probably behave differently or
not function at all.

clip_image008

Now what if these applications were sequenced to the C: drive instead of the Q: drive?

Configuration files that were created during installation would hold a location that is not App-V specific (like on the Q: drive) but generic (like on the C: drive). The conversion process would literally migrate the value to the new App-V 5 format. In both cases the file would end up in the Virtual File System (VFS) of the application package and the configuration entry would point to that location as well. Which is good because that location is identical in both cases and the App-V engine would make sure that it’s redirected to the corresponding folder.

So my conclusion is that, if other aspects of the environment don’t change (like you simultaneously migrate from an x86 to x64 operating system) and it’s an “in-place” upgrade of the App-V environment, applications that are / were sequenced to C: have a much higher chance to be successfully converted then applications that were sequenced to Q:.

So if you are planning to migrate anywhere in the future, this might be a good time to rethink your sequence strategy. It might be beneficial in the future!