Update 12/5/2014: The PVAD is now considered optional due to changes in App-V 5Service Pack 3. Read more here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden
When sequencing applications, you often never know how the application was written with regards to what paths are actually referenced via hard-coded paths or through tokenized, or well-known paths or KNOWNFOLDERIDS. In previous versions of App-V and Softgrid, these paths were referenced using %CSIDL% variables. These are well-documented on MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx). If the application was developed to reference CSIDLs, they usually function when virtualized just fine with App-V. CSIDLs are still supported for backward compatibility, but going forward starting with App-V 5, a different tokenization process is used to align better with KNOWNFOLDERIDs. The new App-V Tokens and their default locations upon installations are well documented in the App-V 5 sequencing guide:
Tokenization helps to remove a specific application’s tie-in to specific folder paths and to allow for greater portability especially when these KNOWNFOLDERIDS have been redirected for specific configurations.
It is important to understand that for sequencing applications that will be used for Connection Groups or to better take advantage of the App-V 5.0 SP2 HF4 VFS Write Mode, all files will need to be located in the VFS structures. This will drastically affect the sequencing process.
Sequencing to a PVAD, Installing to the PVAD
If you specify a Primary Virtual Application Directory and then install to that same location, the base directory of installation files will not be tokenized. For many older applications, this may be the best route to take. For example, if the Primary Virtual Application Directory (PVAD) is specified as C:\DIRECTORY1 and the sequencer monitors an install during sequencing to C:\DIRECTORY1 then everything created beneath DIRECTORY1 goes beneath Root and will not be tokenized or located beneath the VFS folder. There may be additional files that do in fact get written to tokenized paths and they will be tokenized but you will now have a mixture of both “rooted” file assets and VFS file assets.
In the example below, Notepad ++ is sequenced to C:\Notepad and installed to C:\Notepad:
As you can see above, the majority of the files appear below the Root structure and are not contained with the VFS tokenized directories. Also notice the folders beneath Root cannot be adjusted for opacity:
When the files are deployed to the App-V immutable package cache, they will be laid out the same way.
In addition, in order to troubleshoot and navigate the file system within the bubble, non-VFS folders do not appear in directory listings.
You will be able to change to virtual directory by using cd Notepad+
Sequencing to the PVAD, Installing to Program Files or a Different Location other than the PVAD (Fake PVAD)
If you specify a PVAD and then install to a different location, all of the files will be written to the VFS location inside the package. For example, if the PVAD is C:\DIRECTORY1 and the sequencer monitors an install to C:\Program Files\DIRECTORY1 during sequencing, then everything gets put beneath Root\VFS and root installation files will get tokenized if they are written to write to a KNOWNFOLDERID or CSIDL during installation.
In the example below, Notepad++ is sequenced using a fake PVAD and installed into C:\Program Files\
As you can see, all of the files are stored beneath the VFS directory structure.
When files are VFS’ed, you can see the directory listings as normal directories converged with the local directories when you launch a command inside the App-V bubble.
What About Using a KNOWNFOLDERID as the PVAD?
This question comes up quite a bit. Many packagers like to match PVAD with the installation directory (especially now that the Q:\ requirement is gone.) This is fine but understand that when you install to a PVAD during sequencing, all installation files beneath that folder that are not otherwise set to install to another explicit KNOWNFOLDERID or CSIDL path will be treated as rooted files.
For example, if you choose C:\Program Files\DIRECTORY as the PVAD and the sequencer monitors an install to C:\Program Files\DIRECTORY1 during sequencing, then most files will still be beneath root and NOT VFS except for tokenization of explicit KNOWNFOLDERID paths.
In the example below, when sequencing Notepad++, a PVAD of C:\Program Files\Notepad++ is specified.
During the monitoring of the installation, notice the specified install directory is also C:\Program Files\Notepad++.
Upon completion of sequencing, you will then notice that the package files are laid out just like any other PVAD-sequenced package.
The base installation files are located beneath Root.
Like the example earlier, when you open up a command prompt inside the bubble, you will not see the root directory in a directory listing.
However, you can still change to it manually inside the bubble.
So What about this VFS Write Mode?
For a lot of applications, especially older applications, they are written to use configuration files beneath the root of the installation directory. Natively installed applications often have to use shims to redirect these modifiable configuration files to safer directories. Combine this with the fact that most packagers are not always sure where to place the installation files in relationship to the PVAD (we cannot always read the minds of developers) and you can run into problems when virtualizing applications. While using shims is possible with virtualized applications, this can drastically increase the sequencing and remediation time for an application.
Enter VFS Write Mode. The App-V team added this “silver bullet” of a feature into HF4 of App-V 5 SP2. Using the advanced configuration options in sequencing, you can now select this option to enable an application to normally open files for modification within the package.
To demonstrate how this can be helpful, once again we will use Notepad++. When you install Notepad++, you have the option to load/write the configuration files from the install directory instead of using the %APPDATA% directory which would be properly tokenized.
Prior to the invention of VFS Write Mode, if you selected “Don’t use %APPDATA%” during sequencing, this is what would happen when you tried to run the program virtualized. First you would get an error message like this:
This would be followed by a crash.
When you troubleshoot the application with Process Monitor, you will notice a series of failures when trying to load the files:
In HF4, you can open up the package in the new sequencer, navigate to the “Advanced” tab, and check the box enabling VFS Write Mode.
As a result, Notepad++ will open and function as expected.
You will also notice in Process Monitor, the file operation to open the XML configuration files in the installation directory (with Read/Write/Delete) is successful.
The great thing about VFS Write Mode is that it can be enabled simply by opening up the package in the App-V 5 SP2 HF4 sequencer. You can now put this into your arsenal of App-V AppCompat secret weapons.
Update 12/5/2014: The PVAD is now considered optional due to changes in App-V 5 Service Pack 3. Read more here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden
Also the client must be hf4 to take advantage of vsf write mode?