This error seems to appear because VFS either isn't fully loaded by the time Views.exe is loaded so the program/dlls actually traverse down a non-virtual path, or they somehow break the AppV bubble and don't find whatever it is they are looking for. To correct this issue, you need to create a symbolic link to the VFS'd program directory from where the actual directory is supposed to reside. For instance, I sequenced FolioView to:

C:\Program Files (x86)\CIHI

To produce the error, I launch my command like so (this is what AppV5 automatically puts into the shortcut):

There are several calls that appear to look for files (nfomgr4, fcctrl4, mpr, davInt) that maybe generating the error message, but, I am not skilled enough at WinDBG at this time to be able to dig deeper. Either way, there appears to be a limitation within AppV5 that prevents this program from operating correctly. The same program works in AppV 4.6 without issue though, so it appears AppV5 sill has some work to go to get full compatibility with PITA applications.

Here's the application working fine in AppV 4.6. The application was installed identically for both AppV versions.

Friday, March 20, 2015

This is the AppV5 Data Precache script we use to load our AppV5 packages on our Citrix XenApp servers. Because we use PVS and store the AppV package installation root folder on a persistent disk, we sometimes encounter issues that require us to 'clean up' the package installation root folder before the AppV5 packages will load. What this script attempts to do is setup AppV5 as if it's a new install, grab any packages from the publishing server, then, if sharedcontentstore is disabled, fully mount/load the packages.

Our PVS servers are multi-homed with the Provisioning NIC on a seperate VLAN. Because of how our network is structured, our Provision NIC could register its DNS, but client computers would not be able to connect to it as it is a segregated network. This script sets the Provision NIC to NOT register to DNS.

These are two scripts we use to remove nonpresent hardware from device manager. These devices are generated when we update the Target Device Hardware and VMWare Tools and sit unused so are removed. If there is ever modifications to the vDisk that generate additional hardware this script ensures the vDisk is as clean as possible. You'll need devcon.exe as well.

Saman and I have created a Citrix PVS update script we use and run each time we update a PVS target device. This script has been generated after finding numerous issues that needed to be fixed after updating a PVS image. It includes fixes to issues with AppV5, PVS, XenApp 6.5, etc.

We also made the script to be able to be run automatically by accepting command-line parameters so that we can use it to do Windows Updates with PVS's automatic vDisk update feature.

I've removed email addresses and some specific application fixes that would only be relevant to our environment. So I've tried to generalize this the best I can. We tried to make this script dynamic so if you have a vDisk without AppV it will skip the features that require AppV, skip 64bit only features, etc.