App-V 5: On the (now sometimes) Immutable Package Cache Location

When you add/configure and publish a package in App-V, the primary file assets and source registry hives are stored in the package cache location. It defaults to %PROGRAMDATA%\App-V. The package cache will store packages in a <PACKAGE_GUID>\<VERSION_GUID> directory structure for each package added to the machine regardless of targeting. This package cache will exist for the purposes of marking key assets in both stream-to-disk scenarios in stream-to-memory (Shared Content Store) scenarios.

In many cases you may want to redirect the location of the cache without relocating the location of %PROGRAMDATA%. This can be done by changing the location of PackageInstallationRoot through the registry, PowerShell, or through Group Policy. Technically you might be able to get away with not having to restart the client if you do it through PowerShell, but I would advise that you do it anyway.

Registry Location:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Streaming
• Value: PackageInstallationRoot
• Data Type: REG_SZ

PowerShell:

Set-appvclientconfiguration –PackageInstallationRoot <Path>

You may have noticed that with the defaults, nothing shows up (even the default directory) until the first package is created. Once the first package is configured, the directory is created as a hidden directory with administrators, system, and trusted installer having control with the directory ownership going to SYSTEM. Because of the ACL’s, removing this out of band requires taking ownership and resetting permissions prior to deletion if you ever have to manually remove this.
If you change the location to another directory or another drive without pre-creating and setting the proper permissions, you will notice that you encounter add/publish package failures with error 0c-80070005. At the bare minimum, you would need to redirect to a directory where system does have full control. If the package cache is ever moved without being properly reconfigured, the App-V client service will fail to start.

If you redirect the App-V package cache to a persistent disk in non-persistent scenarios and also redirect catalog data, you can create situations where stale catalog data is trying to be sourced upon reversion. Non-persistent scenarios must avoid situations where catalogs from previous installations pre-exist in the redirected package cache locations. If you redirect the entire %ProgramData% directory to a persistent disk, you will likely run into this in non-persistent (or in the case of the use of a persistent disk.)

If you are suspecting that you are getting this issue, you can confirm it by enabling advanced debug logging of the Client-Orchestration, Client-Service, and the Streaming Manager logs. The Client-Orchestration and Client-Service log will throw error 0XA560212C-0x3. The StreamingManager log will give the following error:

Get DACL from directory failed. Error: The system cannot find the path specified. <PATH>

The quickest solution is to remove the old catalog from %ProgramData%\Microsoft\AppV\Client\Catalog and restart the App-V Client service.

How does VFS Write Mode fit in?

With the redevelopment of the virtual file system including a new user-mode VFS and the COW (copy-on-write) filter, new challenges arose and this package cache format preventing applications from functioning correctly in certain scenarios such as:

• Needing to write to Common App Data or a virtualized %PROGRAMDATA%
• Creating Folder and files beneath %ProgramFiles%
• Adjusting permissions on User COW locations (which, in user targeting, mirror the native directories.)

Enter VFS Write Mode. This reverts back to the notion that the user who owns the COW (which for global would mean potentially any user) gets full access to the top-level COW directories it would normally have access to. Additional compliance in line with Windows Resource Protection and UAC do remain in effect however. To differentiate, there will be directories denoted with an “S”. Standard users will read and write from the regular directory (with relaxed ACL’s) while elevated processes will read and write to the “S” version.

 
The VFS attribute is a very simple one that is stored in the manifest and can also be used with sequencing templates. It is not yet available with dynamic configuration. Yeah . . . that might/ought to get changed.

But what happens when you complicate things with Connection Groups?

The expected behavior for Connection Groups is actually pretty simple. If you add a package with VFS Write Mode turned on to a Connection Group, then the net effect of that will be the entire Connection Group has this turned on since the Connection Group shares a common COW. This setting will persist.

COW Restrictions

COW restrictions by extension have not changed. All of the executable extensions and common application binary extensions are still restricted from being modified even with VFS Write Mode turned on. These include: ASP, BAT, CER, CHM, CMD, COM, CPL, CRT, DLL, DRV, EXE, FON, GRP, HLP, HTA, JS, LNK, MSI, MSP, MST, NLS, OCX, PIF, REG, SCR, SYS, URL, VB, VBE, VBS, WSF, and WSH

Comments

• Anonymous
  January 01, 2003
  thanks
• Anonymous
  August 30, 2014
  If you are running any version of the App-V 5 client or Sequencer prior to App-V 5.0 Service Pack 2 Hotfix
• Anonymous
  August 30, 2014
  If you are running any version of the App-V 5 client or Sequencer prior to App-V 5.0 Service Pack 2 Hotfix
• Anonymous
  August 31, 2014
  So with these S directories, there are in effect two versions of the VFS? Does this mean that if for example a user launches an application as administrator, changes some settings that modify a config file under program files, then relaunch as a standard process, they would not see the changes?
  
  Either I've misunderstood, or that sounds like a bad design decision that would make an app behave differently to an App-V 4.6 or a native install.
• Anonymous
  June 30, 2015
  ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like
• Anonymous
  June 30, 2015
  ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like