Everything you ever wanted to know about the Read-only App-V cache

Application Virtualization is of paramount importance to any large scale for any desktop virtualization project. This article discusses how the read-only cache feature of App-V can help you, how to configure and anything else you would ever want to know about it (and more )

With App-V version 4.6, Microsoft introduced the ability to configure its Client’s Virtual Application Cache (= “Cache”) to be accessed in Read Only Mode (also referred to as “ReadOnlyFSD”).

The App-V Cache is a potentially large file (up to 1 TB max) that contains copies of the application packages (“SFTs”) in order to allow fast (local) access to resources that originally are stored centrally on the network. Due to its purpose, it was designed to reside locally on the App-V Client machine (i.e. a Windows Workstation or a Remote Desktop Server/Terminal Server). Storing the App-V Cache locally on the Client allowed the applications to launch with only a minimum impact to the performance. Because of that “local” design and the requirement to fill (load) new application packages into the Cache, full modification and exclusive access rights had to be given to the Cache File for the App-V core services and drivers in the past.

For VDI environments with hundreds or thousands of Clients, this local and exclusive approach represents a significant cost driver, because in VDI environments usually there aren’t cheap, locally attached Hard Disks installed. Instead, SAN storage has to be bought (or rented) to host the Virtual Machines operating system and applications. Because of the exclusive access approach, each VDI Virtual Machine had to have its own, dedicated App-V Cache, often 4-12 GB in size – although all of these individual cache files potentially contain the same or similar applications.

By introducing the ability to access a shared cache in Read Only Mode, Microsoft allows significant savings related to storage costs compared to old versions of SoftGrid/App-V as well as to other Application Virtualization Solutions. Additionally, it allows to store the App-V Cache file outside the VDI Virtual Hard drive, thus unlinking it from the (virtualized) operating system. This results in an increased flexibility, because changes to the Virtual Application set do not require to modify the VM image any longer.

Because of these potential advantages, the announcement of that Shared Cache approach created certain noise in the App-V community, including some hints of how to create a Shared Cache and fill it with a set of applications.

Source:

#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

 

On another website, this video shows how to implement the feature and how it performs from end-user perspective. There are examples like resetting the cache file before you image the client and how to deploy the Read-only cache configuration.

You can download the video here from Virtuall.eu:

Source: http://www.appvirtguru.com/viewtopic.php?f=14&t=3571&start=0

Similar Posts:

• Free tools for App-V
• A Quick Glance to Server App-V and Sequencing Server Applications
• The benefits and drawbacks of offloading the ESX VM Swap files to local storage
• Microsoft App-V 5.0 Beta overview
• Adding Shell Extensions to App-V Packages