As of today Service Pack 1 for Application Virtualization 4.6 is available. The most significant changes introduced with SP1 are related to the App-V Sequencer, for example:
- The introduction of Package Accelerators: Pre-defined â€˜macrosâ€™ which could be supplied by for example Microsoft, independent software vendors or the App-V community, to serve as a solid base to automate virtual application package creation, easy, fast and predictable
- Pre-sequencing diagnostics: Reports possible issues that can affect the installation process
- Post-sequencing diagnostics: A report stating possible issues found after the installation process, like COM+ or SxS conflicts
- Dynamic Suite Composition logics: Different wizards for sequencing standard, plug-in or middleware applications
- Feature block one creation with the command line sequencer.
In a basic App-V client deployment, the App-V Cache is a per system file and contains all the virtual applications available to the authorized users of that system. Before an application can be used it must be available in the App-V cache, where it is then mounted under the App-V drive letter (mostly Q:). Normally, loading an application into the cache can be achieved by streaming on demand from a App-V Server or pre-loading it directly from the App-V virtual application package.
With the App-V clientâ€™s Shared Cache feature the App-V cache can be placed centrally and shared by multiple App-V clients, utilizing a pre-populated cache file with virtual applications.
The Shared Cache feature was introduced with App-V 4.6, but was at the time only supported on the Application Virtualization Windows Desktop Client, specifically useful in VDI environments. With SP1 the App-V client for Remote Desktop Services can now also utilize the Shared Cache feature.
Letâ€™s see how the support for Shared Cache helps with Application Virtualization for Remote Desktop Services.
App-V Shared Cache for Remote Desktop Services benefits
With the information currently available and the insight we are getting from benchmarking, from for example ProjectVRC, more and more companies consider changing, or have already changed, from bare metal Remote Desktop Services servers to virtualizing this workload as a virtual machine. The transition to hardware virtualization moves the storage requirements from local storage on a bare metal server to expensive, central storage to support features as high availability to allow the virtual workloads to â€˜roamâ€™ seamless between clustered hypervisors.
The main goal of App-V Shared Cache is to reduce storage costs when using virtual workloads. In the very basic the virtual machine is a set of files on our expensive central storage, representing the Operating System, physically installed applications and in the case of using Microsoft Application Virtualization also the App-V cache. All together a single virtual machine can quickly consume tens of GBâ€™s on the storage. A typical App-V cache file on RDS would at least be 10GB in size. By utilizing a Shared Cache in this scenario, we would save this 10GB on the central storage per virtual Remote Desktop Service server.
Many administrators reboot their RDS servers on a regular interval to provide a consistent end-user experience, freeing system resources and re-load all virtual application into the App-V cache. This last step needs to be finished before users can utilize the system. Providing the applications from a Shared Cache removes the step of reloading virtual applications and the system is available to the users immediately after reboot with the latest versions of the virtual applications. The same scenario applies to RDS servers which are being delivered by means of an operating system provisioning solution, like disk streaming or image cloning. In addition, Shared Cache prevents the central OS image to be updated when new virtual applications are published and allows the OS image to be smaller in size.
If your environment is based on hardware virtualization or on physical RDS servers, if you only have a single server or a large farm, in many scenarios you can greatly benefit from the Shared Cache feature of App-V for Remote Desktop Services.
Implementing Shared Cache
After the release of App-V 4.6, I created a video and a blog post on implementing Shared Cache here on AppVirtGuru.com: viewtopic.php?f=14&t=3571
This video also applies to App-V for Remote Desktop Services 4.6 SP1.
Things to keep in mind:
- The storage where the App-V Shared Cache located should always be available and needs to have the same performance as local storage. A Storage Area Network(SAN) is advisable.
- The App-V Management Server is required to provide authentication and the publishing of the virtual applications.
- The system used to build the Shared Cache has to be the same operating system and architecture as the client systems.
- The App-V Active Upgrade feature is not useable in combination with Shared Cache since the cache is read-only. But the use of symbolic links allows for pre-staging an updated cache file while users continue to work.
In virtual desktop infrastructures and virtualized Remote Desktop Services workloads the App-V Shared Cache feature saves on storage expenses and allows for flexibility when using different Operating System provisioning solutions. Using the following resources the Shared Cache feature is straightforward to implement.
Resources for Shared Cache
Microsoft TechNet. How to Configure a Read-only Cache on the App-V Client:
http://technet.microsoft.com/en-us/libr ... 56915.aspx
Justin Zarb. Getting Started with The App-V Shared Cache in 4.6 RC â€“ Part 1:
http://blogs.technet.com/b/virtualworld ... art-1.aspx
Getting Started with The App-V Shared Cache in 4.6 RC â€“ Part 2 Building the FSD Cache:
http://blogs.technet.com/b/virtualworld ... cache.aspx
An extensive three part blog item on Read Only cache by Falko GrÃ¤fe. Microsoft Application Virtualization 4.6 Read Only Cache for VDI environments:
http://kirxblog.wordpress.com/2010/07/2 ... ronments-1
AppVirtGuru.com: Microsoft App-V 4.6 Read-only cache video: