First published on MSDN on Dec 22, 2008
Virtualization is a hot topic in IT circles. When you think of virtualization it is often is in terms of hardware using Virtual PC, Virtual Server or, the latest and best, Hyper-V. But virtualization applies to applications as well and offers several benefits, most of which can be categorized into two very broad classes.
-Reduction in testing time
-Better end user experience
Reduction in testing time
How does App-V help here? In a nutshell it's because when applications are virtualized they are not really running on the target system - they are running in their own virtual 'bubble', complete with a virtualized registry, file system, etc. This virtualized app is able to communicate with the physical environment to access printers, local disks, etc., and with other virtualized apps. The running application does not itself realize it's being run virtually - and there are no unique requirements for an app to be virtualized - pretty much any application can be virtualized. And, unless the end user is particularly savvy, they won't even notice that the application is virtualized either.
The obvious benefit here is in terms of app compatibility! If the app is not being run on the physical hardware - and, as such, doesn't write anything to the local file system, local registry, local com system, etc. -then there should be no chance that it would negatively impact any other app running on the physical system - or any other virtual app. This being the case the testing time to avoid app compatibility issues should reduce to just about zero!
Better end user experience
Any administrator that works with end users knows - end users love to complain! :)
Like most of us, end users get accustomed to their way of doing things. When we throw an application upgrade at them and force them to move to the new system it can be frustrating. I'm sure many an end user have made statements similar to 'If I could just go back to the old system I could make that one change and not have to spend hours figuring out how to do it the new way!" .
Ultimately, the end user does need to move ahead to the latest version of software. But, it could be helpful to allow them to retain the older version as well while they learn. Allowing applications to run in parallel isn't always possible on physical hardware - Office is a good example. Try to install Office 2003 and Office 2007 on the system at the same time - you will run into challenges. But, if you have both software applications virtualized, no problem. Why? Again, both run in their own virtual 'bubble' and have their own virtual registries, etc so, there is no conflict between the apps and they run side by side without issue.
OK, are you ready to dive into the world of application virtualization? You will need a few things depending on how you want to approach this.
System Center Application Virtualization
Formerly known as Softgrid and now known as App-V, the System Center Application Virtualization suite contains all the tools you need to introduce virtualized applications to your environment. The suite is available as part of MDOP 2008 and consists of a few pieces.
App-V Management Server - Hosts and delivers the virtual apps.
App-V Management Console - MMC console for App-V
App-V Sequencer - Engine to create virtualized version of apps.
App-V Streaming Server - Lightweight streaming solution for
branch office scenarios.
App-V Client - Software running on physical systems that knows
how to create the virtual environment and execute virtualized apps
For a detailed discussion of how the above components fit together, take a look at Anthony Kinney's great blog on the topic at http://technet.microsoft.com/en-us/magazine/2008.10.appv.aspx
Integration with SCCM
Introduced as part of R2, SCCM now understands and can deploy virtualized applications. When integrated, SCCM servs the role of App-V Management Server and App-V Management Console so there is no need to install those roles from App-V - but you still need the other pieces listed above.
SCCM treats virtualized apps just like it does any other package. In general you need to import the virtual app into SCCM and then place it on a streaming enabled distribution point. The virtualized app is then advertised to a collection of SCCM clients that have the App-V client component installed along with the SCCM client. Running the virtualized app is a coordinated effort between the SCCM client and the App-V client.
My next blog entry will walk through the process of deploying a virtualized app with SCCM.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.