AppV 5.0 SP3 and the “hidden” PVAD

I just downloaded the bits and bytes for the AppV 5.0 SP3 and started to play around with the PVAD that is now “hidden”. This is because a Merged roots principle was introduced.

First let me take you back to version 4.x of AppV. One thing I didn’t like about AppV 4.6 and using a long file name for the asset folder is the fact that a random short file name was created for the sequence

Example would be:

A sequence with the long file name Adobe_Reader_XI_NL_B01 could have a generated short name of F3WJDL8N.X1W (or any other randomly chosen name that contains alpha-numerical characters).

The chance of two randomly generated short names being identical were almost non-existant but there was a small chance. That last part is what I didn’t like about it. If you used a name within the 8.3 format for the long file name the result would be that the short file name would automatically be the same as the long file name. So that meant more control over possible conflicts or even removing the chance of conflicts.

In AppV 5.0 SP3 the same principle is re-introduced. The option to declare a PVAD is not available any more. It can be brought back by changing a registry key or starting the sequencer with the -EnablePVADControl parameter. More on this can be found in the write-up of Tim Mangan of AppV 5.0 SP3 which you can find here.

The screen that you see just before you start monitoring now looks like this (I hope you don’t mind the dutch GUI):


In AppV 5.0 SP3 you can only name the sequence and the description now reads that on the AppV Management Server this is the displayed name of the sequence. As you can see by default there is no PVAD option availbale. Also in the bottom part of the screen you get the recommendation to install the application to %ProgramFiles%.

What the sequencer does next is create a folder with a random GUID as name in the root of C:\. You can see that in the picture below:


When installing the application to the default location (usually %ProgramFiles%) all files will be placed in the virtual file system. Now you automatically install to a dummy PVAD by default. It is however still possible to install to the AppVPackageRoot by selecting the automatically created folder as the installation folder. You might need this for a few application that can’t handle being installed to the virtual file system (WinZip is one of those application). Some other examples of these application can also be found in the write-up of TimMangan that I mentioned earlier.

See below for installing an application (Putty still remains a good test application) to the folder with the randomly generated GUID:


And the result in the sequencer:


As you can see you the files still end up in the AppVPackageRoot.

So AppV 5.0 SP3 uses a “hidden” PVAD which you can still bypass rather easily. It also removes the option to set an UNC path as dummy PVAD which I wrote about here. At least if you don’t use the -EnablePVADControl parameter or the registry change.

Leave a Reply




This site uses Akismet to reduce spam. Learn how your comment data is processed.