Organizations who move towards Microsoft Application Virtualization often wonder what the best delivery infrastructure is for their environment. In the days of SoftGrid there was only one way of delivering your virtual applications to the end-user: you built a dedicated SoftGrid infrastructure. But since the introduction of App-V 4.5, the possibilities have been extended, making the product suitable for almost every environment.
Due to the number of architectural possibilities, it’s hard to decide which is the right one. Each of the currently available scenarios has its pros and cons, and available functionality depends on the scenario that's chosen.
My collegue Ment van der Plas decided to investigate the integration details and describes all these in a new white paper: Choosing the right App-V Delivery Model (App-v integration: possibilities and impossibilities).
Let’s first discuss some architectural basics. Any App-V infrastructure consists of two key elements:
- How the (virtual) app sandbox is configured and how the apps are executed. (This could be thought of as the "virtualization" part.)
- How the (virtual) apps are physically delivered to the end-user workplace
The virtualization part of App-V is a client component only which is established through the App-V Client. All virtual App-V applications run in a sandboxed execution environment where they're unable to change the system or interfere with other applications. Even though the App-V client is available via two separate installers (the App-V Client for Windows Desktops and the App-V Client for Remote Desktop Services), the virtualization aspect is exactly the same in both installers.
The delivery component of App-V can work in a few different ways, including scenarios that have server-side App-V components. (The App-V server-side components enable efficient streaming application technology, delivering only the bits needed to run the application.) The number of different delivery options has grown with the introduction of Microsoft Application Virtualization 4.5, which now includes:
- App-V full infrastructure model
- Configuration Manager 2007 R2 Integrated model
- Standalone Deployment model
App-V full infrastructure model
In the App-V Full Infrastructure model application, delivery is instant. The App-V client uses a mechanism called “publishing refresh” to receive the authorized applications from the Management Server for a particular user. By default, refreshing happens during logon and / or every certain interval, which can be customized to your needs.
After the client refreshes, the authorized applications are displayed directly for the end-user as if they were installed locally by showing shortcuts, file types associations, etc. When the user starts a given application it's streamed to the client and launched.
When a user is deauthorized for an application they can no longer use it, and after a client refresh the shortcuts and file types associations are removed. Applications can also be centrally disabled meaning that no additional applications startups are allowed, even on machines that have the application already available.
Configuration Manager 2007 R2 integrated model
The Configuration Manager 2007 R2 integrated model requires Microsoft System Center Configuration Manager (SCCM) 2007 SP1 R2 or higher as a delivery infrastructure. Configuration Manager 2007 is comprehensive management solution able to deploy, manage and assess Windows client, server and mobile systems.
Functionality of SCCM 2007 includes Operating System deployment, software update management, asset inventory and application management.
SCCM 2007 manages both traditional installations (including MSI) and virtual applications (App-V). All application management is presented and done from a single console, making adoption and use for IT administrators easier. Many of the advanced capabilities available to manage MSIs are also available for virtual applications, like building complex queries in collections to define which devices are targeted.
Unlike the App-V Full Infrastructure delivery method, the SCCM-integrated model can target machines in addition to users.
The third delivery model is referred to as the “Standalone model”. It’s called standalone because the App-V client is not configured to connect to any App-V server delivery infrastructure whatsoever. Instead applications are delivered to the client through a wrapper (which is an MSI package).
The MSI package holds all metadata of the packaged application (OSD files, icons etc.) except for the large binary file that makes up the actual application (SFT file). The SFT file is not inside the MSI because of size limitations of Windows Installer. (Unfortunately this means that OSD files can only be edited via the Sequencer, which is the software that admins use to build their packages.
Using the standalone method of deployment, if you edit an OSD you have to recreate the MSI file and distribute it to the clients since the clients don’t refresh. (Although luckily there is an option in the sequencer that can generate the MSI without saving the project al together.)
Ment's "Choosing the right App-V Delivery Model" white paper addresses these differences in available deployment architectures and their level of functionality. With this information, organizations (you) can make more solid choices when designing and integrating App-V...Highly recommended stuff!