From the beta from AppV 5.x onwards I always used a dummy folder as Primary Virtual Application Directory (PVAD from now on). By doing this I always ensured that all files ended up in the virtual file system. I want all files to end up in the virtual file system because only virtual file systems and virtual registries are able to “see” each other when two sequences are connected through an AppV 5.x Connection Group. Since the release of Hotfix 4 for AppV 5.0 SP2 the introduced option to have full write access in the virtual file system is an added reason to always install to a dummy folder as PVAD. Even Microsoft (in the person of Steve Thomas) have changed their stance about a best pratice for installing to the PVAD. Microsoft now recommends not to install to the PVAD. You can read about it here.
During one of my AppV 5.x Basic classes we were working with a network share to save our sequences to. One of the students decided to skip some steps and used the folder on the network share as the dummy folder to be used as the PVAD. This results in a sequence that will not start on the computer with the AppV client installed. Below I will show the artifacts on the client and the troubleshooting methods used to detect the cause.
The published shortcut doesn’t have a valid command line:
This either results in the application not starting (no error) or an AppV error depending on the application that is being virtualized. The student saw strange AppV errors that pointed him in questioning if the proper version of the AppV client was installed. Seeing that I had done the classroom setup and knew for sure that both AppV 5.0 SP2 HF4 Client and Sequencer were installed (I even double checked that before starting the course) we quickly ruled that out as a cause. I reproduced the issue with the application XML Notepad 2007 and that application wouldn’t start. So I went from there.
Next I checked the AppxManifest.xml file in the C:\Programdata\[PackageID]\[VersionID] folder to see the properties of the published shortcut.
The path at appv:Target lists the [{PackageDrive}] token twice. This results in an invalid target path for the published short and therefor no path is shown in the shortcut.
Next I went to the sequencer to list the parser items just to see where the [{PackageDrive}] token is pointing to. As expected it is pointing to the Q:\ drive used in AppV 4.x. So the shortcut is basically pointing to C:\Program Files (x86)Q:\XML Notepad 2007Q:\XmlNotepad.exe. That doesn’t look right.
By now I already suspected a faulty PVAD or something similar. So I went back to the client and checked the FilesystemMetadata.xml file in the C:\Programdata\[PackageID]\[VersionID] folder.
As you can see the Filesystem Root entry (other notation for PVAD) lists an UNC path instead of a local path. This causes all kinds of paths to be populated by several [{PackageDrive}] tokens and in the process creating invalid paths.
I did one more check on the sequencer to see more artifacts. I didn’t clean the sequence so all Windows Installer related files and registry keys were still in the sequence. I browsed to REGISTRY\MACHINE\SOFTWARE\Windows\CurrentVersion\Installer\Folders.
Even the Windows Installer registry keys are mangled because they contain multiple [{PackageDrive}] tokens. In my opinion the best way to fix this is to re-sequence the application and to use a folder on the local disk as a dummy PVAD
So my advice is: Don’t use a folder on an UNC path as a dummy PVAD, use a folder on local disk instead.
