I wrote this article a few months back before Microsoft’s App-V 4.5 product shipped…while the technology discussed focuses on SoftGrid 4.2, most of the content and concepts are still relevant today…I’ll follow this up with an article on Microsoft Application Virtualization (App-V) 4.5 at some point in the next month or two. -Adam
Microsoft Application Virtualization is one of the coolest technologies available today, enabling businesses to drive down the cost and complexity of deploying applications in the enterprise while enabling some new and exciting scenarios around how we provision applications for our end users. In this post, we’ll take a look at the end to end process for managing and deploying applications in Microsoft’s virtual world
First things first...What is Microsoft Application Virtualization?
Microsoft Application Virtualization is one of Microsoft’s virtualization based technologies that include server, desktop, presentation and application virtualization. Microsoft Application Virtualization is an ongoing evolution of the acquisition of a company called Softricity and their application virtualization product, SoftGrid.
Microsoft Application Virtualization gives us the ability to deliver a configured application to a machine running the Microsoft Application Virtualization client and run each of these applications inside of its own isolated virtual environment (called the SystemGuard environment, see Figure 1) with its own virtual file system and virtual registry hives. This allows us to run applications in complete isolation from one another and has dramatic benefits for the traditional application lifecycle. For example, we no longer have to ensure that when we install a new application, that it will not conflict or adversely impact every other application within our environment that it may coexist with, instead we only have to test that the application works against our core desktop or terminal server image (i.e. the operating system and any applications that are physically installed).
Figure 1: The SystemGuard Environment
In many ways, the virtualized applications run in the same way as physical applications; all files are stored locally on the hard drive but stored inside of the Microsoft Application Virtualization client’s single cache file (which is mounted as a virtual drive). When an application is launched, it runs from the virtual drive, has access to and can consume local programs and resources and still runs using the local processor and memory.
The Microsoft Application Virtualization client can be installed on a Windows 2000 or later client operating systems, or a Windows or Citrix based Terminal Services server. In the current versions, the Microsoft Application Virtualization client cannot run on 64-bit platforms. When reading this article keep in mind that application virtualization is different from presentation virtualization: With presentation virtualization the application runs on a server and only the application window, mouse and keyboard traffic traverses the network. This requires a constant network connection while the application is in use. With Microsoft Application Virtualization the application files are delivered over the network to a cache on the local hard disk and then run locally. Once the cache is populated the application works great for both online and offline scenarios.
A very common question at this point is: this technology sounds great, it sounds like it can solve all of my application compatibility challenges...can I virtualize ALL of my applications this way? There’s two parts to this question and it’s important to really understand what Microsoft Application Virtualization can and can’t deliver. Firstly, Microsoft Application Virtualization is not the silver bullet to end all of your application compatibility problems, it delivers application to application isolation; it does not deliver application to operating system isolation. If your application won’t run on the Windows Operating System natively, you can make a good assumption it won’t work in the virtualised world. Of course, the answer isn’t as black and white as that, but it’s a good general rule of thumb. Secondly, no, not all applications can be brought into Microsoft’s Virtual World: there’s some good information available on what can and can’t be virtualized but at a high level some examples of applications that can’t be virtualized include applications with boot time drivers or services such as Antivirus Software, applications that install hardware based drivers or that rely on COM+.
One common area of confusion is around whether or not you should be looking at using Microsoft Application Virtualization...most people look for some clearly defined rules that tell them in what scenarios they should and shouldn’t use application virtualization. Bad news: there are no clearly defined rules. Both Microsoft Application Virtualization and traditional approaches work just fine, as does a mixture of these approaches.
The choice of whether or not to look at a move to Microsoft Application Virtualization is usually a strategy decision, there’s a lot of sense in looking at application virtualization as it enables new user scenarios and has numerous benefits both for the business and the users: We’ve already mentioned application to application isolation, this can have great impact when you’re migrating to a new application or a new version of Microsoft Office and you need that comfort blanket of being able to still have the old version available to run side by side in case of urgent issues or for training purposes. For Windows and Citrix based Terminal Services servers, application isolation can have a huge benefit: many enterprises today silo terminal services server farms for different applications due to application co-existence issues. By running Terminal Services in conjunction with Microsoft Application Virtualization co-existence issues are a thing of the past, each application can run in its own virtual environment without impacting other applications on the server, allowing administrators to consolidate their terminal services farms and ultimately reduce their infrastructure costs.
The application itself being virtualized also means that it doesn’t install program files, registry keys, DLLs or other files inside of the client operating system; as far as the operating system is concerned the application doesn’t really exist on that platform until such time as the user launches it. Not only does this mean that the platform has a better chance of remaining stable (because it has to undertake less change), but uninstalling an application is a very simple process of removing the application from the client cache.
Microsoft Application Virtualization also has benefits for the helpdesk. When you deliver a virtualized application, it is delivered in a pre-configured state for your environment and ready for use. During its lifecycle, the application will save changes by writing configuration files or making registry changes that are result of user operation and configuration; any changes that are written by the application are written to separate package files that maintains the delta of any changes made in the virtual environment. These delta changes are stored in different packages depending on whether the changes are specific to a single user or to the application globally. In maintaining these delta changes Microsoft Application Virtualization provides the ability for the application to quickly and easily be reset to a default state by deleting the packages that store the delta changes.
On the flip side, not all applications can be virtualized, so for the foreseeable future you’re unlikely to ever fully move to Microsoft Application Virtualization without having some traditional application deployment.
Another great feature of Microsoft Application Virtualization is how those virtualized applications get delivered, the coolest of which is a technology known as application streaming. As you’ll find out later in this article, application streaming enables some really exciting new user scenarios for application deployment in the enterprise today. Before we get into application delivery let’s look a little closer into how applications are transformed into virtual applications.
Making Applications Virtual
The process or turning an application into a Microsoft Application Virtualization enabled application involves a process called ‘sequencing’. An application is sequenced using the Microsoft Application Virtualization Sequencer and follows a three stage wizard driven process:
Stage 1: Package Configuration Wizard – the administrator enters details that define key details about the package including the path from which the Microsoft Application Virtualization client will access the package, and the operating systems that the application is allowed to run on. The information is stored and later placed in the XML based OSD file that is used by the Microsoft Application Virtualization client when accessing the application.
Stage 2: Installation Wizard – the monitoring process begins. During this phase the administrator installs, launches and configures the application. While this process is taking place, the Sequencer monitors and captures all files and registry keys that are being written to the computer.
Stage 3: Application Wizard – the administrator configures icons, shortcuts and file type associations for the application; the Sequencer allows the administrator to launch the application and simulate user activity so that the sequencer can split the sequenced application up into two logical parts called Feature Block 1 and Feature Block 2. The key reason for doing so will become more apparent later in the article.
When all of the wizards have been completed, the Microsoft Application Virtualization sequencer will sequence the application and allow the administrator to save the package ready for deployment. For some best practice guidance on sequencing applications, view the following support article: Best practices to use for sequencing in Microsoft SoftGrid (http://support.microsoft.com/kb/932137)
What do Sequenced Applications consist of?
When an application has been sequenced, the resulting package directory will contain multiple files including an .SFT file, one or more .OSD files, one or more .ICO files and an .SPRJ file. It’s important to understand the relevance of each file to fully understand Microsoft Application Virtualization:
The .SFT file contains all of the files and registry keys that were installed during the application installation and configuration on the sequencer workstation, split up into Feature Block 1 and Feature Block 2. These files have been captured and sequenced into blocks of data, by default the sequencer uses 32KB blocks of data, but this can be configured during the sequencing process.
The .OSD files are XML format based files that store key information about a sequenced application; there is always one .OSD file per application shortcut. When an sequenced application is launched, the Microsoft Application Virtualization client reads the OSD file for that application and retrieves key information including where the .SFT package is located and what protocol to use to access it.
The .ICO files are used to present familiar application shortcuts for each sequenced application to ensure the user perception remains unchanged. When the .ICO is opened by a user double clicking a shortcut, it points to the .OSD file to allow the sequenced application to launch.
The .SPRJ file is the Sequencer Project file and is used to save the details of the sequenced package for later use if you want to re-open the package to make any changes.
At the end of 2007, Microsoft released the MSI Utility for Microsoft Application Virtualization. This MSI Utility brought additional capabilities that allow some elements of the virtualized application package to be wrapped up into a Microsoft Installer (MSI) file so that it can then be plugged into a traditional Software Delivery system such Microsoft System Center Configuration Manager (ConfigMgr) 2007. When the MSI is delivered, the MSI in conjunction with an application manifest XML file is used to load the applications into the Microsoft Application Virtualization client cache.
How do Sequenced Applications get delivered to the desktop?
Once you have sequenced your applications, you need to decide how they will be delivered. There are some important considerations when it comes to application delivery which we’ll discuss later in this section, but first let’s take a look at the options.
Our first option is application streaming. Application Streaming is a really great feature; it’s the concept that instead of using the traditional application delivery methodology of downloading, installing and then running an application, you instead move to a model where the application is streamed down to the desktop on demand, much like how you might stream a TV show or a movie across the internet.
How would this look to an end user? As an end user, you can log on to any Microsoft Application Virtualization enabled client (that is, a desktop or terminal server machine running the Microsoft Application Virtualization client) and within a few seconds, all of the shortcuts for your applications appear on the desktop in a process called desktop configuration refresh. Once those shortcuts appear, you are able to double click any application and the application will launch with the required components being streamed to the desktop immediately.
For those of you who are thinking: hang on, does that mean I need to wait for my entire application to download before I can use the application? Luckily no! Earlier in this article, the concept of Feature Block 1 and Feature Block 2 were introduced. When an application is sequenced, the sequencing administrator launches the application and simulates the most common user actions, in doing so, the Microsoft Application Virtualization Sequencer can understand which files are required to perform the initial application launch and handle the common user actions. All of these files are placed into Feature Block 1 of the SFT package (this usually comprises of around 10%-30% of an application).
When a user launches an application, only Feature Block 1 is initially downloaded...all other files are left on the server in Feature Block 2 until such time as the user tries to perform actions requiring additional files. These files are delivered on demand as and when they are requested and as each file is streamed, it is loaded into the Microsoft Application Virtualization client cache which stores all sequenced applications. Once these files are in the client cache, they remain there until such time as an administrator removes them and therefore do not need to be re-streamed the next time the application is launched.
Application Streaming gets even better when you combine the streaming functionality with an environment that uses roaming profiles. Earlier in the article we discussed how changes to a virtual application are stored in user or application specific delta packages; the user specific delta packages are stored inside of the user’s profile and will therefore roam as part of a user’s roaming profile. This means that if a user personalises a virtualized application (for example changing the application layout), they can log onto any Microsoft Application Virtualization enabled client and not only receive all of their applications, but also still have the configurations that they made to that application on the previous computer!
The second option is MSI or offline delivery, which requires that the application has been sequenced into a virtualized application, but has then been packaged as an MSI using the Microsoft Application Virtualization MSI Utility. Using MSI based delivery is then a very similar process to traditional application delivery: the application is taken and imported into an Electronic Software Delivery system and delivered in the same way as a traditional application.
The MSI delivery method is often referred to as the offline delivery method because in using the MSI delivery method, applications are loaded into the Microsoft Application Virtualization client in a slightly different way than when an application is streamed and in doing so, the Microsoft Application Virtualization client is put into ‘offline’ mode meaning it ceases to have any communication with the Microsoft Application Virtualization infrastructure. There’s a very important design and supportability consideration here: It is not supported to mix different delivery approaches when delivering virtualized applications to a client, the virtualized applications must either be streamed or delivered using the MSI approach, a Microsoft Application Virtualization client cannot use a mixture of the two approaches. This does not mean you cannot use both approaches inside your environment, you can, and it’s fully supported, you just cannot deliver an MSI based virtualized application to clients that receive virtualized applications through streaming and vice versa.
Managing Application Access Control
We discussed in the previous section how Microsoft Application Virtualization application streaming provides us a way to enable our users to log on to any Microsoft Application Virtualization enabled client machine and receive their applications. For this to happen, there needs to be a way for the Microsoft Application Virtualization infrastructure to understand what applications the user should receive.
After an application is sequenced, for it to be available for application streaming it must be imported into the Microsoft Application Virtualization infrastructure (we’ll discuss the infrastructure components later in this article). During the import process, the administrator is asked to associate the application with one or more Active Directory security groups. During the desktop configuration refresh process, the user’s security groups are analysed and compared to the security groups associated with each application to determine which applications the user is entitled to. For each application the user is entitled to, the shortcuts for those applications are downloaded to the users machine. When an application is launched the Microsoft Application Virtualization client performs further validation using a similar process to ensure that the user is still entitled to run the application.
The process can be taken one step further to add licensing based access control which comes into play when an administrator defines in the Microsoft Application Virtualization administrators console the number of licenses available for any given application and associates the license count with an application. By doing this, the Microsoft Application Virtualization infrastructure validates that the number of instances of the application running at any one time does not exceed the total number of licenses available. If a user launches an application that has 10 licenses defined for it, and 10 people are already using that application, the user will be notified that they cannot use the application until an application license becomes available.
What are the Microsoft Application Virtualization Infrastructure components?
With Microsoft Application Virtualization, the application delivery approach defines what infrastructure is required: If the MSI delivery approach is being used, then only the Microsoft Application Virtualization sequencing infrastructure is required; if application streaming is required, then a Microsoft Application Virtualization infrastructure will be required to support it.
The sequencing infrastructure is actually very simple and consists of a client or terminal server based operating system with the Microsoft Application Virtualization sequencer installed. The machine must have two partitions or two disks, an operating system partition and a partition with drive letter Q. This is used during the sequencing process as the installation location for the application and translates to a virtual Q: drive created by default on the client machine when the Microsoft Application Virtualization client is installed and from which the virtual applications are run. We usually recommend that the operating system is actually the corporate standard image because when you’re sequencing, it’s important to let the application run in an environment with the same base components (core applications, service packs, etc) that the application will be able to see when running in a virtual environment. Microsoft Application Virtualization applications can read through to the operating system so if the application does not contain files or components that it needs in the Microsoft Application Virtualization virtual environment then it will look for those components on the physical client.
The sequencing workstation should ideally also run on a virtualized platform using a virtualization technology such as Microsoft Virtual PC. The reason for doing this is because every time you sequence an application you will need to reset back to the clean state before sequencing another application, it’s easier to do this using a technology such as Virtual PC where you can use ‘undo disks’ or ‘snapshot’ technologies to revert back to a clean state when required.
If you’re planning on enabling applications streaming in your environment using Microsoft Application Virtualization then a back end infrastructure will be required. There are three core components in the Microsoft Application Virtualization back end infrastructure including a database server, a web service and management console, and a virtual application streaming server:
The Microsoft Application Virtualization Database server stores configuration data on the Microsoft Application Virtualization infrastructure and application configuration (including application to security group mapping) and application usage data. The Microsoft Application Virtualization database server does not support replication but does allow the SQL database to be clustered. This has some very important architectural considerations because every time a client performs a desktop configuration refresh, or every time a client launches an application using application streaming, there is communication (either by the client or by proxy through the streaming server) back to the database.
The Microsoft Application Virtualization Web Service and Management Console server is used to configure and administer the Microsoft Application Virtualization environment. The web service is used by the management console to talk to the database server to read and write configuration data.
The Microsoft Application Virtualization Virtual Application Streaming (VAS) server is used to provide application streaming capabilities over the Real Time Streaming Protocol (RTSP) (although it can be over RTSPS for enhanced security).
Infrastructure Architecture for Microsoft Application Virtualization
Infrastructure is a very important consideration when it comes to any new technology, and now you understand the key components that are required, you need to understand how these can be put together to build a Microsoft Application Virtualization infrastructure. Scaling Microsoft Application Virtualization out within an enterprise is where a lot of challenges arise, most enterprise environments consist of large hub sites connected to multiple branch office or satellite locations, some with little or no server infrastructure; while Microsoft Application Virtualization scales well inside of a well connected hub locations, the branch office model requires careful consideration.
For hub sites, there are two key considerations: Firstly, each Microsoft Application Virtualization database server can only sit at one location (remember earlier in this article we discussed that it does not support replication). Because all Microsoft Application Virtualization clients communicate with the database via the Microsoft Application Virtualization VAS server, place the database server on a hub site that benefits from the best network links and for increased resilience and availability employ SQL Server clustering to host the database. You do have an option to host separate Microsoft Application Virtualization database servers at different locations, but they have to be administered separately which leads to increased administration, so where possible deploy a single database server.
Secondly, the VAS server infrastructure must be scaled appropriately to be able to adequately handle application streaming demands for the number of clients at each hub site. VAS servers can be scaled using traditional load balancing techniques including Windows Network Load Balancing (NLB), hardware based load balancers or using a Domain Name System (DNS) Round Robin. A key consideration of implementing load balancing technologies with Microsoft Application Virtualization is that software based load balancers (such as Windows NLB) and some hardware load balancers (that do not understand RTSP) do not understand application level failures and cannot tell whether or not the Microsoft Application Virtualization components are still running, meaning you could have a server node appearing healthy as it is responding to heartbeat requests, but could in reality be having application level issues.
Microsoft Application Virtualization does not currently have built in content replication capabilities, so to replicate virtual applications to multiple VAS servers, use either shared network based storage (such as a SAN) or use a file replication technology; common choices include Windows Server 2003 R2’s Distributed File System-Replication (DFS-R) or Robocopy.
For branch and satellite offices, you need to make a choice: do you want to provide application streaming capabilities at the branch office locations and is it feasible to do so? The current recommended practice is that you only enable application streaming in well connected environments, i.e. those environments that have at least a 100mbps connection between your Microsoft Application Virtualization clients and the Microsoft Application Virtualization VAS servers to ensure a good user experience. For all other locations, use electronic software distribution to deliver your MSI based virtual applications. A sample application streaming branch office architecture is shown in Figure 2
Figure 2: Sample Branch Office Streaming Architecture
For further architectural guidance, view the Microsoft SoftGrid Application Virtualization Infrastructure Planning and Design Guide (http://technet.microsoft.com/en-us/library/bb897450(TechNet.10).aspx)
Microsoft Application Virtualization (App-V) 4.5 and System Center Configuration Manager (ConfigMgr) 2007 R2
In Q3 of this calendar year, Microsoft released Microsoft Application Virtualization (App-V) 4.5 which brings some really great enhancements to the product; in the same time frame Microsoft released the R2 version of ConfigMgr 2007. One feature of ConfigMgr 2007 R2 that has everyone talking is the App-V integration that lets you manage and deploy your App-V virtual applications completely through ConfigMgr without requiring any App-V back end infrastructure. Leveraging ConfigMgr 2007 R2 for application virtualization will also significantly address and simplify the challenges involved in scaling a Microsoft Application Virtualization infrastructure within the enterprise. I’ll follow up this post with a later blog post in the next few months!
This post was contributed by Adam Shepherd, a Consultant for Microsoft Consulting Services in the UK.
