Kirx' Blog -

Microsoft Application Virtualization 4.6 Read Only Cache for VDI Environments #3 | November 1, 2010

Assigning the updated Cache to VDI Machines

Article Series Content

#1 Introduction and Key Findings

#2 Setting up the Staging Client and Loading Applications into the Staging Cache

#3 Assigning the updated Cache to VDI Virtual Machines (this article)

The right Location for the Shared Cache

The asumption of a VDI scenario was the most important driver for Microsoft to develop App-V’s “Read-Only-Cache” functionalities. As Justin Zarb illustrated in one of his articles, storage space may become a significant cost driver in a VDI environment. Given that situation, there are some possibilities how to achieve storage savings. Please be aware that this blog article can not cover all the advantages, disadvantages and a deep technological assessment, so Iam a little bit short here:


Store the App-V Read-Only-Cache in the VDI VM’s Primary Drive

In a pooled VM scenario with a deduplication technology (Citrix Provisioning Services, VMware Linked Clones or provided by the SAN vendor), placing the Read-Only-Cache into the primary drive is acceptable, if the amount of different “Master Images” is not too high. An important disadvantage is, that modifications to the cached Virtual Applications require maintenance on the core Master Image(s), which may be disappointing because of the size of manipulated data. In a  private Image scnenario, deduplications techniques usually would not work (well), and therefor also the App-V Cache potentially consumes its space multiplied by the amount of VMs.

Store the App-V Read-Only-Cache in a VDI VM’s Secondary Drive

Storing the App-V cache on “another” disk may reduce the amount of space required for the App-C Cache instances, because one and the same VM HD may be attached to VMs of different classes (different pools as well as different private VMs). However, this approach doubles the amount of connections established between the VMs and the SAN, which may decrease the overall performance of the SAN and surely increases the management effort.

Outsourcing the App-V Read-Only-Cache onto a File Share

Setting the App-V Cache to “Read Only” allows to store the cache file on a file server. The main advantage of this approach is that no effort has to be made to find or configure an appropriate Deduplication technology, because all App-V clients access the only one Cache file natively. Also, modifications to the Cache File do not require any configuration change to the VMs (like (un-)/assigning a new Virtual Disk). Furthermore, this approach unloads traffic from the “VDI SAN” (as well as it unloads tasks from the Deduplication Technology).

Of course it has to be considered that the file server has to be of significant performance and that (un-)/assigning of new versions of the Cache File have to be made as well.

Configuring the App-C Client Cache for Read Only Access

Regardless of the location of the App-V Shared Cache, all clients basically have to be configured equally to prevent modification to the shared cache:

1. Configure the Client for “Full Infrastructure” Mode

As in a previous post, a Shared Cache scenario requires a “full” App-V infrastructure. The Client namely has to get its publishing information from an App-V Management Server. Other publishing methods are not supported by Microsoft. While other methods may work, they are prone to failure.

2. Configure Read-Only-Cache functionality

2.1 Relocate the Cache Log File

By default, the cache log is located in the same directory as the App-V cache file itself. Because this is going to be a Read-Only location, the log file has to be relocated. As a good practice, it may be located along with the “normal” App-V log file (its location depends on the Client OS version).

To relocate the Cache Log, create a new Registry Value:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\<Wow6432Node\>Microsoft\SoftGrid\4.5\Client\AppFS
Value: "ErrorLogLocation" [RegSZ] = <Path to location\sftfs.etl>

The created .ETL file can be opened with Windows Event Viewer.

2.2 Enable (Enforce) Read-Only Access

To enable the Read-Only Access, create a new Registry Value:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS
Value: "ReadOnlyFSD" [DWORD] = 1

Remember that this does not only modify the way how the cache file is accessed. It also modifies the App-V Client’s publishing behaviour.

2.3 Point to the (new) App-V Cache File

Modify the Registry Value:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS
Value: FileName [RegSZ] = \\FileserverName\AppVCacheFiles\Pool-01\sftfs.fsd
2.4 Apply the Changes

All changes only are applied after the Client Machine has been rebooted.

It is recommended to manage these settings by using Group Policy Objects (GPOs). You can use Login Consultant’s ADM Template Add-On to control ReadOnlyCache settings. (I reviewed it here).

Cache File Management using File System Pointers

Like with an updated Virtual Machine Disk Image for a Pooled VDI VM, also the App-V Cache file will be modified regularily. In my previous post I described how such updates can be applied to a working copy of the App-V Cache file. But of course the Cache File not only has to be updated – it also has to be assigned to the VDI VMs. The Cache File can’t be replaced easily, because the “old” (or current) file still is accessed by the VMs – potentially permanentely in a 24/7 environment. Therefor, newly booting Clients will be pointed to the new version of the Cache file without any client-side configuration change by using File System Pointers.

Junctions and Symbolic Links

In Windows, there are basiacally two methods to accomplish this. Junctions and Symbolic Links

Junctions are available in Windows XP and Windows 2003 Server (even in Win200) and newer. They do only affect the server and only can be applied to directories. When the Client follows a pointer, only the server leads the request to its actual destination.

Symbolic Links have been introduced with Windows Vista and can be used on Vista and Windows 7 clients and Windows 2008 and 2008 R2 servers. In contrast to Junctions, Symbolic Links DO affect the client, i.e. the client knows that the request is redirected and follwos the redirection itself. SymLinks can be applied to directories and individual files. The client has to be enabled to follow Symbolic Links to remote locations.

Both technologies are generally applicable to our App-V usage scenario. For the App-V Cache, the pointer’s destination is updated only when the client machine gets rebooted. That means that during operation, a client will not run into an “undefined” state, because the destination behind the pointer has changed.

Of course there are some differences between both technologies.

If your VDI VMs run on Windows XP or your File Server runs on Windows 2003, Junctions are the only choice you have – but you can use Junctions on the newer Operating Systems as well.

However, Symbolic Links are “smarter”. The Client OS does not get fooled about the destination. This is important for troubleshooting: In a Symbolic Link’s properties you can see the “real” destination of that Link. Therefor, your helpdesk can figure out if a user is working with the current or an older version of the Cache File. This “connection visibility” also applies to the file server. You can easily determine what VDI VMs still are accessing the old (or even very old) Cache File and which clients already us the new one – simply by using Win 2008 Server Manager’s “Shares / Open Files” feature.

Configuration Outline

For the upcoming examples, let’s suppose:

The App-V Client is configured to have its cache file at


Locally on the File Server, an older and a newer version of the App-V Cache File exist:


Also, these actual files are accessible via the file server

Note: If you have a mixed environment (WinXP and Win7 clients), do NOT MIX SymLinks and Junctions to point to the same directory. To avoid confusion, you should split up the folders in one for the XP clients and the other for the Win7 Clients (or use Junctions for both kind of clients).

Junction Configuration

To perform the operation, you could use the Sysinternals tool “Junction” that you can get here. (There are other tools like the Resource Kit tool “linkd”, but I usually have faster access to the internet then to older Resource Kits…)

@echo of
:: Delete the old Junction:
:: After that, there is no folder "Pool-01" located in the "AppVCacheFileShare" folder:
junction /d D:\FileShares\AppVCacheFilesShare\Pool-01
:: Now we set the pointer to the new directory:
junction /s D:\FileShares\AppVCacheFilesShare\Pool-01 D:\FileShares\AppVCacheFilesShare\ProductionFiles\Version_002

And that’s it for a Junction. Basically, we tell the Server that folder “Version_001” has to be mapped to the different name “Pool-01” into the AppVCacheFilesShare directory. Thus, any instance that accesses AppVCacheFilesShare remotley or locally, will see the “Pool-01” directroy including its content.

Symbolic Link configuration

Symbolic Links are enabled and often used locally on Vista, Win7 and W2008 server machines.

Client Preparation

For remote access, SymLinks have to be enabled on the client device. Theferor, the following command has to be executed with administrator priviliegs on each client (well, once on the VDI Master):

fsutil behavior set SymLinkEvaluation R2R:1

This allows to remotely follow Remote Links.

Directory Symbolic Links

To create a SymLink for a directory, use the following commands:

:: Delete the old link:
del \\FileServerName\AppVCacheFilesShare\Pool-01
:: Create the "new" SymLink:
mklink /D \\FileServerName\AppVCacheFilesShare\Pool-01 \\FileserverName\AppVCacheFilesShare\ProductionFiles\Version_002

This tells the client’s request for “Pool-01” to be redirecte to “ProductionFiles\Version_001”. Please be aware that the client itself accesses the last mentioned share, so there have to be sufficient rights on it.

File Symbolic Links

SymLinks’ default behaviour is to redirect file instead of directories. If you’d have all you sftfs.fsd file versions in one and the same directory (with different names), the command could look like this:

:: Delete the old link:
del \\FileServerName\AppVCacheFilesShare\Pool-01\sftfs.fsd
:: Create the "new" SymLink:
mklink \\FileServerName\AppVCacheFilesShare\Pool-01\sftfs.fsd \\FileserverName\AppVCacheFilesShare\ProductionFiles\sftfs_version02.fsd


To assign a new App-V Cache file to VDI VMs, Symbolic Links appear like the most attractive solution. They do not require any modification to the VDI Master Image(s), can be used with Private and Pooled VMs and do not require any “new” additional technology like Storage Deduplication, Linked Clones or Disk Provisioning. Also, Symbolic Links offer certain visibility for troubleshooting purposes. If SymLinks can’t be used (mainly because the VMs run Windows XP or the File Server runs on Windows 2003), Junctions can do the trick.


Posted in App-V, Client
Tags: ,


  1. […] by Microsoft Application Virtualization 4.6 Read Only Cache for VDI Environments #3 « Kirx' … — November 1, 2010 @ 20:00 […]

    Pingback by Microsoft Application Virtualization 4.6 Read Only Cache for VDI environments #2 « Kirx' Blog — November 1, 2010 @ 20:03

  2. […] by Microsoft Application Virtualization 4.6 Read Only Cache for VDI Environments #3 « Kirx' … — November 1, 2010 @ 20:00 […]

    Pingback by Microsoft Application Virtualization 4.6 Read Only Cache for VDI environments #1 « Kirx' Blog — November 1, 2010 @ 20:04

  3. […] #3 Assigning the updated Cache to VDI Virtual Machines […]

    Pingback by Everything you ever wanted to know about the Read-only App-V cache « — February 22, 2011 @ 10:19

  4. Hi, I want to use shared cache as a share. I have 2 x Mgmt and 2 x streaming servers. Would I even need streaming servers if I’m uisng shared cache?

    Comment by acid — August 3, 2011 @ 00:44

    • Hi,

      probably not. From an Management Sever / Streaming Server perspective, the only “load” occurs when a Client refreshes the application list. Depending on the amount of users/application usage you might need a powerfull File Server (that hosts the shared cache on a file share).

      Comment by kirxblog — August 7, 2011 @ 18:21

  5. My main concern about the shared cache scenario would be performance; what share has san-like performance? Does anyone have performance impact information on this subject?


    Comment by Roland van der Kruk — September 7, 2011 @ 12:23

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: