Kirx' Blog -

Microsoft Application Virtualization 4.6 Read Only Cache for VDI environments #2 | August 20, 2010

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

Article Series Content

#1 Introduction and Key Findings

#2 Setting up the Staging Client and Loading Applications into the Staging Cache (this article)

#3 Assigning the updated Cache to VDI Virtual Machines


This article will focus on preparing the “Staging Client”

In App-V’s “VDI Mode”, the shared cache file potentially will be accessed permanently by different VDI machines. Therefor, any update to that Read Only Cache, including its first filling, has to be applied to a different cache file. This special instance of an App-V Cache file will be called “Staging Cache File” hereby. Because that file uses a proprietary format, the only way to apply any updates is by using a “normal” App-V Client machine. This (virtual) client machine is usually called “Staging Client”.

It is supposed that you already have a “full” App-V Infrastructure including the App-V Management Server. Also it is supposed that this infrastructure has been validated to work propperly (i.e. applications already have been deployed to Test Clients)

Accessing the App-V Cache File

The challenge is to copy the StagingFSD to another location, because it will get locked by the App-V Drivers and Services during System Startup and can’t be unlocked easily afterwards.

Several recommendations about how to “release” the StagingFSD have been made [see References in Articel #1]

  • Restart the StagingClient in SafeMode
  • Deactivate the App-V Client Service and Restart the Machine

Both methods have their up- and downsides:

  • Using SafeMode prevents the “Staging User” from “forgetting” to re-enable the Deactivated Service before the next update, because after a reboot the machine will return to the “Standard Windows” mode
  • Deactivating the Service allows for “smother” and probably faster working compared to WindowsSafeMode: Screen Resolution and Color Depth aren’t reduced, most drivers are loaded (well, except the App-V File System Driver Service) leveraging several acceleration techniques. Also, Network Ressources (like the future central App-V Cache File store) may be accessed.

Both methods require to reboot the StagingComputer between “Updating” and “Copying” the StagingCache, so there is no difference here.

Because it is “smoother” to work with and because it can be semi-automated, I prefer disableing the Service rather then using SafeMode – and this is what I’ll describe afterwards.

Staging Client Preparation

1.    Standard App-V Client installation

The App-V Staging Client is, well, basically a “normal” App-V Client.

1.1 Prepare a Virtual Machine

Because the Staging Client is going to be used for the VDI virtual machines, it is recommended to use a virtual machine for it as well. This virtual machine should be configured basically the same way as the VDI virtual machines. While others (see the “Resources” section of the first article) recommend to build the Staging Client first, configure it and use it as the Golden Image / VM Template (after some modifcations) afterwards, I tend to configure two images independently (one for the VDI VMs, one for the Staging Client).

Of course both images can be syspreped instances of the same VM template. Also it is not necessary to install any application on the Staging Client (apps won’t run here, neither virtualized nor installed ones).

  • The Staging Client machine’s OS and platform (x86/x64) should be the same that is used for the VDI virtual machines
  • The Staging Client machine has to be a member of an Active Directroy, but it should not get its App-V settings by means of a Group Policy
1.2 Install and Configure the App-V Client

On the Staging Client, the App-V Client Software has to be installed and configured. You should use the same App-V Client Version (including Service Packs, Updates and Hotfixes) for the Staging Client and the VDI VMs.

Regardless of the installation and configuration method (GUI, silent, GPO), the following items are important:

  • Define an appropriate Cache File size limit
  • Enable AutoLoad features to always autoload all applications
  • Configure an App-V Publishing Server (=the Management Server)
  • Do not forget to configure “%SFT_SOFTGRIDSERVER%” system variable if used in the App-V Packages
  • Locate and document the App-V (Staging) Cache File location. The actual value can be found at
32bit Systems: 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SoftGrid\4.5\Client\AppFS: FileName

64bit Systems: 
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SoftGrid\4.5\Client\AppFS: FileName
1.3 Test the App-V Client

Before proceeding, you should make sure that your Staging Client is working propperly. After the Staging Client VM has been rebooted and you logged in, you should be able to access App-V Virtual Applications that are published and streamed from an App-V Management Server.

2. Staging Cache File operations

To update the App-V Cache Staging File, some steps should be performed. First, these steps are highlighted and explained. The section afterwards describes some scripts to semi-automate this.

2.1 Update the Staging Cache

Well, this is the easy part:

  • Publish the new application / update on the App-V Management Server
  • Log onto the Staging Client as a user that has access rights to the new/updated application(s)
  • Verify the Application Virtualization Client service is running
  • Refresh the App-V Publishing Server (should be done automatically during log on)
  • “Load” all applications into the Cache (should be done automatically, if AutoLoad triggers are set propperly). If the apps aren’t yet loaded (they should show  “100%” in their status), load them manually

Of course you should fix any errors that occur…

Because the App-V Staging Client is a “normal” client, changes to publishing information or App-V packages should be applied as soon as the Publishing Server has been refreshed and all application packages are fully loaded. Also “Active Upgrade” is supported on the Staging Client.

2.2 Disable the App-V Client Service

In order to be able to copy the current Staging Cache File to another location, the App-V Service must not be running before the App-V Driver gets initialized. In order to do that:

  • Stop and Disable the Application Virtualization Client service using Service Manager (services.msc) or set the follwing Registry Values
    Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\sftlist]
    Value: Start"=dword:00000004
  • Reboot the Staging Client VM

Rebooting the Staging Client VM is necessary, because it is not the App-V Client Service that locks the file. Instead, it is the driver that still is active after the Service has been stopped. After the reboot, the driver can’t be initlaizied, because the Service has been disabled. Therefor, the App-V Driver will not lock the fsdfs.fsd file – and then, the App-V Cache File can be copied to a different location.

2.3 Copy the Staging Cache file to a “safe” location

After the Staging Client machine has been rebooted, you can copy the Staging Cache File to a central location, like on a file server

  • Find the “sftfs.fsd” file. The location has been documented in section 1.2 of this article
  • Depending on the “File System Pointer” method you use (see the upcoming article of this series) you may
    • Copy the file to a central location and rename it accordingly
    • Create a new folder on the central location and copy the file into it

In this step, you basically create a copy of the Staging Cache File that afterwards will be used by the VDI Virtual Machines. How and whereto you copy the sftfs.fsd, wether you rename the copy or place it into a dedicated subdirectory depends on the choosen method.

You never shoud directly try to overwrite the Cache File that currently is used by the VDI VMs in Read Only Mode! Always use an intermediate copy.

2.4 Return the Staging Client to a well-defined state: Enable the App-V Client service

In order to be able to update the Staging Cache the next time, you should clean up the Staging Client again:

  • Enable the Application Virtualization Client service again, using the Service Management Console or the Registry
    Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\sftlist]
    Value: Start"=dword:00000002
  • Shutdown or Reboot the Staging Client machine.

If you choose to reboot the Staging Client, you are able to verify that the App-V Client service started propperly again. Open and expand the App-V Client Management Console to see if everything works well.

2.5 Assign the new Cache File

The next step would be to assign the newly updated Cache Files to the VDI VMs. This is going to be explained in a separate article. For now, let’s look at some of the steps described above and try to simplify them:

3. Simplifying and Automate App-V VDI Mode Staging File operations

(Semi)automating operations has two very imortant advantages:

  1. You can not make typing mistakes
  2. Starting Scripts is way faster then typing long commands, opening the Registry for modifications and Copying Files within Explorer.

To give you any idea, I use some CMD commands here. I do perfectly know that CMD is not the most modern scripting language, but I think it provides a quite clear picture about what to do.

Preparation: RegFiles

I will use some .reg files (Registry files) that’ll be imported afterwards


Windows Registry Editor Version 5.00


Windows Registry Editor Version 5.00
 State Modification CMDs

To be able to add new applications/packages into the Cache, the Service has to be enabled and the machine has to be rebooted. To copy the Cahce file to another location, the Service has to be disabled and the machine has to be rebooted:



REG IMPORT EnableService.reg
SHUTDOWN /r /t 0 /f /d p:4:2


REG IMPORT DisableService.reg
SHUTDOWN /r /t 0 /f /d p:4:2
Creating an unique Copy of the StagingCacheFile

The follwing CMD creates unique copies of the sftfs.fsd file. It has to be placed into the same location of the sftfs.file (App-V’s GlobalAppFSStorage). Then, drag&drop the sftfs.fsd file onto that CMD.

It will create two copies:

  • A copy injecting the current date and time into the File Name  (sftfs_<date_time>.fsd)
  • A copy placed into a newly created subfolder based on the current date and time (.\<date_time>\sftfs.fsd)
Important: This CMD requires the US/English time format and has been developed on Windows 7. Other Operating Systems may return different values for %date% or %time% (like Vista does not show the day’s 3-letter-acronym). Other Reginal Settings may have different separators and/or orders of the individual objects.

And, yes, I do know that this script is far from beeing perfect (no Error handling, no flexibility across OS versions or Reginal Settings…)


:: @echo of

:: Expected Time Format:  (" 9:34:03.78")
:: Expected Date Format: Day mm/dd/yyyy ("Fri 08/20/2010")

:: Cut off the MilliSeconds /everything after the "."
For /f "delims=." %%a in ("%Time%") do @Set ShortTime=%%a

:: Remove the Time delimiters (:) and replace them by "-"
For /f "tokens=1-3 delims=:" %%a in ("%ShortTime%") do @Set ShortTime=%%a-%%b-%%c

:: Cut off the Day (Son-Sat, everything before the space)
For /f "Tokens=1-2 delims= " %%a in ("%Date%") do @Set ShortDate=%%b

:: Remove the Day delimiters (/) and replace them by "-"
:: Re arrange the items to the year-month-day order (for better sorting)
For /f "tokens=1-3 delims=/" %%a in ("%ShortDate%") do @Set ShortDate=%%c-%%a-%%b

:: The "FOString" becomes somewhat like 2010-08-20_ 9:34:03
set FOString=%ShortDate%_%ShortTime%

copy %1 ".\sftfs_%FOString%.fsd"
md "%FOString%
copy %1 ".\%FOString%\"
Operations Commands:

To Refresh the application list (let the Staging Client know that there are new/updated applications)


To load all remaining packages completely into the Staging Cache


Read on

The next episode will discuss the concept of a Read Only Cache File that is not part of the VDI Virtual Disk Image. Instead, the file will be located on a File Server that allows being more flexible and agile while deploying new and updated Virtual Applications (I know that I used to promise that for this article already…)

#1 Introduction and Key Findings

#2 Setting up the Staging Client and Loading Applications into the Staging Cache (this article)

#3 Assigning the updated Cache to VDI Virtual Machines

Posted in App-V, Client
Tags: ,


  1. […] #2 Setting up the Staging Client and Loading Applications into the Staging Cache […]

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

  2. […] #2 Setting up the Staging Client and Loading Applications into the Staging Cache […]

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

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: