Getting Started with The App-V Shared Cache in 4.6 RC – Part 2 Building the FSD Cache

I have been sitting on this one for a while so thought i would get this out :o) I will update this with screenshots later .

So lets take a look at the infrastructure that we will be working with.

I have a several components running in an App-V Full Infrastructure;

  • A Sequencer
  • Several XP VDI Clients Pooled and Personal
  • Several Windows 7 VDI Clients Pooled and Personal
  • Management Server

At this point in our App-V Lifecycle we would have created a number of App-V Packages located in our content share. The Sequencer would have generated a number of packages which I will look to consume into one client. This client operating system essentially will be my staging computer. A computer that will be purely used to bake my App-V FSD file for use for the shared cache.

My goal will be to pre-load all applications that my Virtual Machines will want to use. Once I have successfully loaded the FSD file I will shut my machine down and either mount the VHD file on another machine/or boot my staging machine into safe mode to prevent the App-V client from initiating and extract the FSD file out to the DAS/SAN location where my VDI platforms will be located.

1. Firstly we need to create a client computer that has the App-V Client installed onto the machine. I am than going to Publish all my applications to the computer or user that will be required for all users. I can do this in a couple of ways;

a) Use SFTMIME command to load the applications in to cache

b) Create a user who has access to all the applications in the estate that my VDI users will require. Once the applications are published I want to load all of these into the app-v cache file which i can stream from my Management or Streaming Server.

2. Once all the applications are loaded (this may take a while depending on how many apps you require), Either;

2a) VHD Mout

  • Shut Down the Virtual Machine (if your staging computer is a Virtual Machine) and than mout the VHD file.
    • To Mout a VHD file in windows 7 go to computer manager
    • Go To Storage > DiskManager and Right click Disk Manager and Select Attach VHD

A new dialogue box will appear , browse for the VHD file that has your FSD file located inside it (I also tend to check the Read Only option also, just incase i accidently delete something)

Now locate the FSD file. This will be ;

Windows 7 / Windows Server 2008 R2 with 4.6

Now copy and paste the file to your VDI servers SAN/DAS into a share where all VDI guests can access it.

2b) Safe Mode

  • Restart the staging computer in Safe Mode to ensure the drivers are not started, which would lock the cache file.

3. Copy the SFTFS.FSD cache file to the VDI server’s SAN/DAS where all the VMs can access it, such as in a shared folder.

4. We now need to set up the app-v clients used on the VDI guests to use the App-V management Server for user auth and publication. This is similar to our normal install however we also need to set a number of registry keys.

Install the App-V Desktop client on the VDI Master/VM Image, and then configure it to use the read-only cache.

To enable read-only mode, create a DWORD value that is named ReadOnlyFSD under the AppFS key, and then set it to 1.


Next, set the AppFS key FILENAME value equal to the path of the shared cache file, for example \\vdiservername\sharefolder\SFTFS.FSD.

You should also set the AppFS key ErrorLogLocation value to the location for the error log (.etl) file on the local drive. The AppFS key is located at HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\SoftGrid\4.5\Client\AppFS.

Now you can set this up on your master image or you can use Group Policy Preference to configure these registry keys on the client operating systems. For example here is my Group Policy Preference

6. Configure the Master VM Image client to use the publishing server and to use publishing refresh at logon. As users log on to the VDI system and their VM is built from the Master VM Image, a publishing refresh cycle occurs and publishes all the applications for which their account is authorized. These applications are run from the shared cache.

Comments (5)

  1. JJ Zettle says:

    Hey Justin,

    How does this handle active updates?

    And what happens if the cache somehow becomes corrupt?

  2. Matthias Wessner says:


    active updates do not work. The cache is sealed. Well, because the cache is seal a chance of corruption is quiet low

  3. Active Update is not supported like Matthias says. But you can upgrade the cache file when it is not in use(maybe difficult in 24×7 organizations). Nicest option is to use symbolic links. See the Technet Read-Only cache article:

  4. Phil Forrest says:

    Is the shared cache feature of App-V 4.6 "all or nothing" ??

    What happens if a user with rights to 10 App-V programs on the publishing server logs on to a machine with a shared cache file populated by only 4 of the 10 App-V programs?



  5. mark roles says:

    Are symbolic links only supported when using Hyper-V as a host?

    Any idea how we can get around this for 2003 Terminal services (or 2008) connecting to a fast CIFS share.

    Would like to use this feature but if upgrades are going to be a pita then it’s not going to be viable.