Yesterday Microsoft released a new version of their application virtualization solution: App-V 4.6. In this article, Ruben Spruijt explains why application virtualization is the way to GO and what the new features of App-V 4.6 are (including the functionality of the new shared cache feature).
Application Virtualization, the way to GO!
Making applications available to end users is probably the most important functionality of an IT infrastructure, and in today's world, the dynamic delivery of applications is essential. In conversations with customers I regularly receive the question, “What is the difference between app deployment and app delivery?”
With application deployment, the applications are installed on the execution platform. The execution platform could be a local desktop. laptop, a central virtual desktop, a blade PC, or a Remote Desktop Server. When speaking of application delivery in the context of application virtualization, the applications are no longer installed. Instead, they're made almost instantly available and executed on the execution platform. The execution platform does not undergo any alterations.
Microsoft Application Virtualization (App-V) enables fast application delivery in both central and local environments whereby mutual application conflicts are excluded. This considerably reduces the throughput times of application packaging and delivery compared to the traditional deployment methods. The primary reasons for applying application virtualization are:
- Applications are no longer installed on the (Virtual) desktops, laptops, or Terminal Servers
- No more conflicts between applications
- Eliminates the need for regression testing
- Multiple versions of applications can be used simultaneously
- Consolidation of Terminal Servers
- Fast application delivery, roll-out, and upgrades
- Stabilizes Windows profiles
- Creates a dynamic application delivery infrastructure which allows applications to be used online, offline, on-site, off-site
- Package once run 'everywhere'
- Creates dynamic in a stateless VDI and Terminal Server environment
“Application Virtualization is the way to go!
What's new in App-V 4.6?
The new features in App-V 4.6 are:
Virtualizing Office 2010: If there was any doubt about virtualizing Office in the past it good to know that Office 2010 integrates much better with App-V 4.6. With the release of the Office Deployment Kit for App-V the following functionality is available:
- Sharepoint integration; Open, Save, Edit files;
- Use Outlook fast search to send and find emails quickly;
- Print documents directly to OneNote
- Send files directly from inside of the Office products;
- Document Indexing is used to find content
- RSS feeds and Open web based calendar
- Virtual Mail applet in control panel
64-bit OS and Application support: App-V now supports x86 and x64 bits applications on x86 and x64 operating systems. The support of x64 operating systems is valuable for local desktop and laptops running Windows 7, and for Terminal Server environments running Windows Server 2008R2
Support for Windows 7 Applocker and Bitlocker: App-V integrates with Applocker, branchCache, Applocker ToGo and Bitlocker ToGo.
Improved Sequencer experience: The App-V sequencer is able to package/sequence both x86 and x64 applications with the same tool. The process of sequencing applications is easier than before.
Reduce disk storage in VDI/RDS scenario: The new App-V shared cache features reduce the amount of storage in a Virtual Desktop Infrastructure (VDI) environment. The pros and cons about this will be explained in the next chapter.
The App-V shared cache
App-V 4.6 now supports the ability to configure the App-V client to use the package cache as a read-only file. This capability was added to support multiple App-V client machines access to a single package cache this functionality is very useful in Server Hosted Virtual Desktops (VDI) and Remote Desktop Services (Terminal Services) scenarios. With VDI there is a big impact on (central) storage. The IO and capacity increases while using vDesktops. Storage needs much attention while designing and maintaining a VDI environment. Microsoft App-V shared cache functionality will decrease the storage capacity impact. The App-V package cache normally exists inside of a file with .FSD filename extension.
The FSD file must be placed in a location that can be accessed by the vDesktops; the location of the package cache should have read-only access and should perform well. Direct Attached Storage (DAS)) or central (SAN) storage will meet the storage criteria.
Publishing and Streaming
The package cache should be configured prior the publishing step. Any method of publishing a virtual application to the App-V client can be used. When a package is published to the App-V client it will immediately show as 100% loaded in the package cache. Despite the fact that it will not be streamed, the SFT file must still be made available to the App-V client via a streaming server. The client needs to read metadata stored inside the file. The type of streaming server must be an RTSP(S) server. IIS or SMB streaming servers are not supported. It should be clear that network traffic will be minimal since the SFT file itself will not be streamed because the storage infrastructure is being used.
Sharing the cache and store the SFT files
There are two ways to share the FSD file.
- Inside a mounted VHD mapped as a drive. If the FSD file is shared inside its own VHD, that VHD will be mounted as a drive e.g. E: in the master VDI VM image.
- As a UNC on a “share” that is accessible by all vDesktops.
The SFT file that is used to populate the shared package cache must be placed on an RTSP(S) streaming server. All client configuration options can be used including such options as the Application Source Root (ASR). The SFT file(s) will not be streamed since it will already be fully cached inside the FSD; the App-V client will only access the SFT in order to retrieve the required metadata. The streaming functionality of the App-V Management Server can be used for this purpose.
Populating the App-V cache
In order to populate the shared package cache, the use of an authoring client machine is recommended. This is (virtual) machine that has the App-V client installed normally. An administrator uses any streaming method they choose to import an SFT file into the FSD file. Once the FSD file on the authoring client has been populated it must be copied off in order to be shared by the vDesktop VMs. To do this, the Application Virtualization Client service must be disabled on the authoring client, the authoring client machine rebooted, and the FSD file copied off.
Managing Package Upgrades
As virtual application packages are upgraded the FSD file will require updates as well. If the master VDI VM uses a UNC to specify the filename, the FSD file update can be made with no change to the VDI VM master by specifying a symbolic link in the master VDI VM image Filename. When the FSD file is updated, only the filename that the symbolic link references must be updated i.e. the symbolic link will need to be updated to reference the new FSD file. The clients will continue to use the same-named symbolic link and thus require no update.
Bottom line; the shared cache feature will save in (central) storage capacity costs. The impact on disk-IO and the real-life experiences while updating applications in a shared cache will prove the value of App-V 4.6 shared cache!
Questions or comments please let me know: firstname.lastname@example.org
Understanding how storage design has a big impact on your VDI! https://www.brianmadden.com/opinion/Understanding-how-storage-design-has-a-big-impact-on-your-VDI-updated-September-2011
Desktop virtualization and the power of App-V and Windows 7 https://www.brianmadden.com/opinion/Desktop-virtualization-and-the-power-of-App-V-and-Windows-7
Application Virtualization Solutions Overview and Feature Compare matrix https://www.brianmadden.com/opinion/Application-Virtualization-Solutions-Overview-and-Feature-Compare-matrix-UPDATED