Microsoft Application Virtualization 4.6 Read Only Cache for VDI environments #1

Introduction and Key Findings

This is the first article of a series discussing Microsoft App-V’s Read Only Cache

Article Series Content

#1 Introduction and Key Findings (this article)

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

#3 Assigning the updated Cache to VDI Virtual Machines

Introduction

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.

Resources

In this article we will leverage the instructions and experience outlined here:

MS Technet (feature description)

http://technet.microsoft.com/en-us/library/ee956915.aspx

Justib Zarb’s posts:

http://blogs.technet.com/b/virtualworld/archive/2010/01/20/getting-started-with-the-app-v-shared-cache-in-4-6-rc-part-1.aspx

http://blogs.technet.com/b/virtualworld/archive/2010/02/22/getting-started-with-the-app-v-shared-cache-in-4-6-rc-part-2-building-the-fsd-cache.aspx

Jurjen van Leeuwen’s video and post:

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

Tim Mangan’s post, describing how to use his tools to fill the Shared Cache on the Staging Client:

http://www.tmurgent.com/AppV_DeployNPublishApp/With_VDI/Introduction.aspx

Together, these publications provide an insight onto how the App-V Read Only Cache can be created and how it can be deployed initially.

These resources mainly describe, how to use one “Staging VDI machine” to create and fill an App-V Cache File and to convert that Staging Client into a VDI Virtual Machine Image with a Read Only Cache File.

For my test, I used a different approach. My design intention was to store the Read Only Cache File outside of any Virtual Disk images in order to keep the disk images as thin as possible. I am going to post another article about that within the next days.

Motivation

Thinking about the concept of a Shared Cached, some questions and considerations may arise.

The once that came into my mind are:

• How can a Shared Cached be updated while hundreds of VDI Virtual Machines access it?
• How do common App-V Operations work in a Shared Cache environment, like
  • How does Publishing of new Applications work?
  • How does Removal of outdated Application work?
  • How does “Active Upgrade” affect Shared Cache Client operations?
• How fast can Updates and New Applications be deployed in 24/7 environments with a potentially permanent access to the Shared Cache?
• What other considerations have to be taken into account?

Supported Deployment scenarios

Referring to http://technet.microsoft.com/en-us/library/ee956915.aspx, using a Shared Cache / Read Only Cache is only supported in “Native Mode”/”Full Infrastructure” deployments.

Clients have to refresh their application list from an App-V Management Server

Other Publishing Methods, like System Center Configuration Manager, 3^rd Party Software Distribution Systems (using MSI or SFTMIME based Publishing), HTTP Publishing and Stand Alone Mode Deployments are not supported.

Some of them may be working with several workarounds, but any of the unsupported methods has to be planned very carefully and lots of care has to be taken in order to deploy new applications and application updates. To make it sort: Don’t try them!

Key Findings

Based on that questionnaire, some tests have been made with App-V in Read Only Cache configuration. The key findings of these tests are the following:

1.   Modifying the “ReadOnlyFSD” Registry Value controls several aspects of the App-V Client.

By modifying the Cache File’s access method (done by changing a single Registry Value), several Client functions are modified that are not directly related to the technical access to the cache file. These other modified functions have a strong relationship to the Read Only Cache behavior and are generally useful. The main modifications are:

1.1   Loading and unloading of applications into/from the Cache does not work any longer on Shared Cache Clients.

Because the Cache is accessed in Read Only Mode, individual App-V client machines cannot perform any modifications to the Cache. This means, they can’t load, import or unload applications.

If such activities are required, they have to be done centrally using the Staging Client.

1.2   Publishing of new applications is limited to applications that are already loaded into the Shared Cache.

The App-V Client will suppress creation of newly published applications if they aren’t already available in the Cache. Freshly published applications not yet being in the Cache won’t be visible in the User’s workspace or the Client Management Console.

Therefore, when a new application has been made available on the App-V Management Server, it will only be available to the users after it has been integrated into the Shared Cache. On the Server, no special considerations have to been taken: New Applications can be published (to Test Clients, “normal” Clients or the VDI Staging Client) without the need to build a separate infrastructure.

One current limitation is that failed application creations cause a Client Error in the client log because of this active suppression.

Sftlog.txt:

[05/25/2010 03:47:57:411 JGSW ERR] {tid=BE0:usr=Administrator} The Application Virtualization Client could not find 
a package object for GUID {9D954831-AE84-45E3-867E-FF2AE1DFE4BA} (rc 16D0B10A-0000E02D).
.
[05/25/2010 03:47:57:427 AMGR ERR] {tid=BE0:usr=Administrator} The app manager could not create an application
 from 'http://AppV-MS/content/DSC/Microsoft_InternetExplorer_DSC/Internet%20Explorer%208.0.7600.16385.osd' (rc 16D0B10A-0000E02D).

2.   Active Upgrade of Published Applications does not work any longer.

Because the Shared Cache is Read Only to the VDI VMs, so called “Active Upgrades” (i.e. deploying a new version of an already published application) can’t be loaded into the Cache. It is the App-V Client that actively suppresses Active Upgrades after the ReadOnlyFSD setting has been set. Each application update has to be injected into the Shared Cache using the “Staging Client”. Of course you can apply “Active Upgrades” to the Staging Client.

3.   For smart update processes, Symbolic Links or NTFS Junction Points or similar concepts should be used.

In order to allow fast deployments of updated Read Only Cache files, the App-V clients should be configured to access the Cache file using a pointer (as opposed to a hard-coded connection). In Windows, technologies like Symbolic Links or NTFS Junction points are representations of such “pointers”. I will go into details about these “File System Pointers” in the upcoming article I mentioned above. The concept of “Pointers” allows to deploy an updated Cache file without modifying the VDI VM Images nor requiring excessive down times.

4.   Processes have to be set up and performed to ensure a consistent App-V Cache File lifecycle Management

Administrators will be required to perform Cache File Updates on a separated Staging Client first, before the updated file can be attached to the Production Clients. This requires to follow a well-defined procedure that depends on the Client’s Operating System, capabilities of the Storage Solution, the App-V infrastructure and some more aspects.

5.   Relocate the App-V File System Log File

The App-V Client sores some logging information related to the Cache in a log file that usually is located along with the Read Only Cache file. Because the Cache File is relocated to a Network Share, the Log file  has to be placed elsewhere.

Read on

The second article explains how to create a Staging Cache file, how to load App-V Packages into it and how the Staging Cache file can be copied away.

#1 Introduction and Key Findings (this article)

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

#3 Assigning the updated Cache to VDI Virtual Machines

---

Posted in App-V, Client
Tags: App-V, VDI