System Center
Take Your Apps Virtual with Microsoft SoftGrid
Ahmer Sabri and Kedar Shah
At a Glance:
- Benefits of application virtualization
- Overview of the SoftGrid architecture
- Streaming software packages
The concept of software virtualization, in some form or another, has been around since the 1960s. However, it has taken the IT industry decades to begin to realize the potential of application
virtualization. People are now catching on, and major developments are being made.
Microsoft threw some weight behind application virtualization when it acquired Softricity back in July 2006. From this acquisition comes Microsoft® SoftGrid, a solution for application virtualization. With SoftGrid, applications are served from a datacenter or another network location and run locally on remote clients in a virtual environment. The virtualized applications run in silos and operate independent of the operating system and other applications on the local desktop.
There are many benefits to implementing application virtualization with SoftGrid—too many to discuss here. However, the following are some of the most notable and immediately recognized benefits:
Simplified Regression and Compatibility Testing By running multiple versions of the same application in parallel on a single machine without conflicts, you can dramatically reduce the complexity, time, and costs associated with testing and deploying new applications (see Figure 1).
.gif)
Figure 1 Streamlining application deployment with SoftGrid (Click the image for a larger view)
Easier Systems Management IT has great control over the environment in which these applications run, making it easier to maintain the ideal desktop environment.
Fewer Help Desk Calls With better managed desktop environments and fewer conflicts (thanks to virtualized apps running in a controlled silo), users require fewer calls to the help desk.
Enhanced Desktop Security Applications are never installed on the OS, improving overall OS security. Apps are only provisioned to authorized users, thus preventing unauthorized access. And most apps are rendered under standard security context.
Free Seating Experience User preferences (profile and other settings) are stored on the network, thus allowing users to access their applications, preferences, and controls from any PC.
Improved Fault Tolerance and Disaster Recovery Applications are turned into data files that can be stored and replicated like any enterprise data. Applications and their updates can be synchronized automatically between live and Bulk Copy Program (BCP) sites using third-party tools, enabling instant access to applications in case of a disaster.
Ultimately, these characteristics ease the burden of system administration, reduce costs, and allow your organization to adopt new technologies more quickly and reliably. Now let's look more closely at just how SoftGrid works.
How Virtualized Applications Are Served
The SoftGrid architecture is composed of a number of components that work together in symphony. It involves SoftGrid components such as the data store, virtual application server, sequencer, management consoles, the management Web service, and client app, working in conjunction with standard infrastructure components, such as Active Directory® (see Figure 2). We'll give you an overview of the SoftGrid architecture and explain how the various components work together.
.gif)
Figure 2 Overall SoftGrid architecture (Click the image for a larger view)
The SoftGrid data store acts as a central repository for the entire virtualization environment. Installed on either SQL Server™ (version 2000 or 2005) or the Microsoft SQL Server Desktop Engine (MSDE), the data store holds records, applications, configuration, licensing data, reporting information, and logging information.
Virtualized applications are served to the user's machine and rendered in a client. SoftGrid offers two types—Microsoft SoftGrid Application Virtualization for Universal Desktops and Microsoft SoftGrid Application Virtualization for Terminal Servers. Each approach has advantages but also has certain performance trade-offs, which we'll cover in the section Setting Up the Client.
One of the most critical components in the SoftGrid environment is the SoftGrid Virtual Application Server (SVAS). This is used to handle user requests for applications and to stream the application data to the users on demand.
SVAS runs as a Windows® service called Microsoft System Center Virtual Application Server and has very modest hardware requirements. By default, all the application data itself (which we'll discuss in a moment) is located in the \Program Files\Softricity\SoftGrid Server\content directory.
The typical SoftGrid experience is initiated when a user logs on to a workstation. SoftGrid Client captures the user's security token and domain group membership and passes this information via a secure channel to SVAS. SVAS assigns the user access to applications, provided the user's Security Identifier (SID) exists in the application's group membership directory, and a shortcut for each application is placed on the user's desktop (or in whatever other location the administrator may define, such as the start menu, quick launch toolbar, and so on).
Actual delivery of an application is generally started when a user clicks the shortcut icon, which is associated with an Open Software Description (.osd) file. This is an XML-based file that contains information about the application package. The client retrieves the virtual application server name from the .osd file and initiates a connection. At this time, SVAS authenticates the client and contacts the data store to determine license compliance. Once the user is authenticated, SVAS streams the application data to the client in data blocks—by default, the data blocks are 32KB each but can be configured at the time of sequencing.
Note that the entire application is not streamed to the client. Instead, SoftGrid streams only the portion of the application that is immediately required to launch the app on the client. This is typically about 20 to 40 percent of the total code, though this can certainly vary by application. For example, Microsoft Word 2003 only requires 15MB of data to be streamed to the client before it can be launched, compared to the 800MB total size of the package. If the user accesses a portion of the application that is not already in the client's cache, the necessary code is then streamed to the client. To avoid the Monday morning effect, in which too many simultaneous requests clog the network, organizations can choose to pre-cache common applications on user desktops.
Active Directory
SoftGrid relies on Active Directory (or Windows NT® 4.0) domain users and groups for provisioning applications to authorized users. In a multi-domain environment, users can be provisioned using the appropriate group memberships (SoftGrid supports local, global, and universal group memberships) and trust relationships with the domain where SVAS is installed.
When installing SVAS, you are prompted for different service accounts and groups, which help with the integration with Active Directory and are subsequently used for administrative purposes. Thus, there are three groups and accounts that you should create prior to installation: a SoftGrid Browser Account, a SoftGrid Administrators Group, and a SoftGrid Users Group.
The SoftGrid Browser Account is responsible for browsing Active Directory and, therefore, requires read-only rights to all the Active Directory domains in a multi-domain environment. The SoftGrid Administrators Group is used to grant administrative access to SoftGrid Management Console and SoftGrid Management Web Service. And the SoftGrid Users Group is used to assign default provider policy, which is used to give all users in the domain access to applications published through the management console.
The Virtual Environment
SystemGuard is at the core of SoftGrid Client, which runs on the local desktop. SystemGuard is responsible for providing a fully functional virtual environment for applications to run in isolation. Contained in this siloed environment are the virtualized OS components—registry, files, fonts, INI, COM, embedded services, and environment variables—that are required for the application to run properly (see Figure 3).
.gif)
Figure 3 Virtualized environment for application to run in isolation
SystemGuard creates virtualized registry keys for every application it runs. These keys are not accessible to other applications running on the local OS, nor are they visible to registry editing tools such as regedit. Registry reads and writes are redirected to the virtual keys as needed. Note, though, that virtualized applications are allowed to pass through to the local registry for information not contained in the virtualized registry keys.
Similarly, SystemGuard creates a virtualized file system and redirects the majority of the application's reads and writes to this file system. This virtualized file system is isolated and provides the environment you need if you want to run multiple versions of the same application on a single client.
We should point out, however, that while the applications are isolated from the local OS, the user still has access to all the local services, such as print, cut and paste, and network drives.
Packaging Applications
Now you might be wondering how you create a fully functional independent environment for your virtualized application to run in. For this task, you use SoftGrid Sequencer. This wizard-based tool allows you to package applications in a virtual environment that can be delivered and executed on the client.
The sequencing process involves three steps: Installation, Configuration and Test, and Execution. In the first step, Installation, the SoftGrid Sequencer uses an active watch process to monitor the installation of the application and assess application dependencies. Once complete, the Configuration and Test phase is used to make any necessary changes to the default configuration in order to ensure the desired first-run experience. Finally, in the Execution phase, the SoftGrid Sequencer compiles and orders the code block necessary to launch the application. Feature Block 1 (FB1) is the essential code required to launch the application, allowing the user to run the application without downloading the entire package.
Once an application has been sequenced, four files are created: a virtualization-enabled application file (.sft), an Open Software Description file (.osd), an Icon file (.ico), and a project file (.sprj). These are then copied to the content directory of SVAS. Alternatively, an administrator can publish .ico and .osd files to the clients using an HTTP server.
While SoftGrid typically provisions applications to run independently of each other in isolated environments, SystemGuard does permit some application interaction. You should carefully examine any dependencies applications may have on one another and sequence applications together if they rely on interacting with each other. This process is commonly referred to as suiting. Note that not all applications that require interaction with one another can be sequenced together. Suiting is a very intricate process and should be done only after careful examination of the dependencies, as sometimes sequencing two or more applications defeats the purpose of virtualization.
Simplifying Administration
The SoftGrid management console provides a single tool for performing all the administrative tasks. The management console is installed on the SVAS by default and can be installed on any other server or workstation. It is an MMC 3.0 snap-in and uses the SoftGrid Management Web Service to connect to the SoftGrid DataStore (see Figure 4), giving authorized administrators full access to data stored in the database for management purposes. The connection between the management console and the SoftGrid Management Web Service uses Microsoft .NET Framework remoting, making it possible to install the management console and the Web service on the same or different servers. Figure 2 illustrates how these various pieces fit together and provide access to the entire SoftGrid implementation. Note that larger organizations should run more than one instance of the SoftGrid Management Web Service.
.gif)
Figure 4 SoftGrid Management Web Service provides the connection to the data store (Click the image for a larger view)
The SoftGrid Management Web Service runs on Windows 2000 or later with IIS 5.0 or later. The .NET Framework 2.0 or later is required, as well as Microsoft Data Access Components (MDAC) 2.7 or later for data store connectivity.
The management console provides a single administrative tool from which applications can be published, terminated, and so on. Tasks are organized into nine main categories or containers, as shown on the menu in Figure 5.
.gif)
Figure 5 Managing SoftGrid from a single management console (Click the image for a larger view)
Here's a quick rundown of the types of management tasks found in each container. The Applications container is where the administrator can do things such as import .sprj files to publish newer applications, specify .osd location, remove applications, and so on. By default, this container includes a published package you can use to test client connectivity to the application server.
A file type association is created when the applications are sequenced. Once the package is imported, the file type associations become available in the management console. The File Type Association container provides a single place for administrators to modify all file type associations.
The Packages container controls versions of packages for active upgrades; these are application upgrades that can be done without the user disconnecting or the server being shut down. The administrator can also delete a package from the management console using this container. Note that deleting a package from the Packages container will remove the .sft file from the management console and the data store but will not delete it from the content directory on the application server.
As we mentioned earlier, when a user launches an application, SoftGrid Client checks for license availability and launches the application only if a license is available in a data store. The Application Licenses container is where administrators can associate licenses with applications—unlimited licenses, concurrent licenses, and named licenses are all supported.
Server Groups contains a logical grouping of application virtualization servers and logging information. Administrators can add new server groups or modify properties (such as ports used for communication or allocated memory and processes) of an existing group.
In the Provider Policies container, the administrator can create a set of rules called policies. The custom provider policies are used to give users access to numerous applications under different sets of conditions. You can use the Account Authorities container to specify a domain and credentials that will be used when SoftGrid needs access to read the domain's directory information. SoftGrid Administrators contains the user groups responsible for administering the SoftGrid environment. In this container, administrators can add or remove groups to control access permissions.
Lastly, the Reports container, as its name implies, allows administrators to generate reports to check the overall health of the SoftGrid environment. The following reports are available: Application Utilization, Software Audit, System Utilization, User/Group Activity, and System Error.
Setting Up the Client
The SoftGrid Client is installed on the operating system of the computer the user will use to access the virtualized application. As we mentioned earlier, two client types are supported: Microsoft SoftGrid for Desktops or Microsoft SoftGrid for Terminal Servers. Each approach has advantages but also certain performance tradeoffs, in terms of network latency, server farm consolidation, and ease of management.
In a desktop implementation, applications are available locally and there is little dependency on network availability and throughput. This approach is recommended, for instance, for organizations that have branch offices with limited IT infrastructure. Terminal Services is a good option for an organization that has already rolled out terminal servers. This scenario makes efficient use of hardware and software, drastically reducing the number of necessary servers. And,
of course, it enables a true free seating environment. Large organizations will typically have a combination of desktop and terminal server infrastructure. Installing and configuring the various components is similar
for both approaches when you set up a SoftGrid deployment.
The client can be deployed using any standard method, such as manual installation or automated deployment using a tool such as Systems Management Server 2003. Figure 6 lists the minimum hardware and software requirements needed to install these clients.
Figure 6 System requirements for the SoftGrid clients
| Client |
Processor |
Memory |
Disk Space |
Operating System |
| Microsoft SoftGrid for Terminal Servers |
PIII 850MHz |
1GB RAM (minimum 256MB, actual dependant on number of users and applications |
12MB for installation and 4096MB for cache |
• Windows 2000 Server or Advanced Server with Terminal Services enabled
• Windows Server 2003 with Terminal Services
enabled |
| Microsoft SoftGrid for Desktop |
PIII 600MHz |
128MB |
12MB for installation and 2048MB for cache |
• Windows 2000 Professional or Windows XP
• Windows 2000 Server or Windows Server 2003 |
Although the installation of the client is straightforward, there are some properties you must provide at the time of installation—such things as the location of the installation, the cache size, the drive letter to be used for the virtual drive, the location of application data files, and so on. Once the client has been installed, some additional settings can be specified or changed using the client management console.
To launch the client management console, go to the control panel and launch SoftGrid Client Management from Administrative tools. You can choose to connect to the local machine or to a remote machine.
Figure 7 shows how the client management console consists of a root container and three child containers. The SoftGrid on localhost root tab is where you can specify most of the functional parameters, including logging directory, application data directory, client run and display settings, error and informational message pop-up frequency, maximum cache size, virtualized drive, network and connectivity options when disconnected from SoftGrid server, and permissions.
.gif)
Figure 7 Client management console
You can view and change applications in the Applications container. The Applications container provides status information about the local application, such as whether the application is running, if the application is locked in cache, and what percentage of the application (.sft file) has been streamed into the local cache.
The File Type Association container allows you to view, change, and remove a file type association. For more details, see our discussion of the File Type Association in the previous section.
The Desktop Configuration container allows you to specify, change, and manually refresh the application server settings you specified during installation. Here, you can also select whether the client refresh should happen at the time of user logon (this is the default selection) and the length of the auto refresh interval.
Wrapping Up
Application virtualization with Microsoft SoftGrid offers a compelling way to improve system reliability and simplify management. While it involves a number of parts working together, the architecture actually fits seamlessly into the IT infrastructure.
Microsoft SoftGrid for Desktops is available to Software Assurance customers as part of the Microsoft Desktop Optimization Pack. For more information, see
windowsvista.com/optimizeddesktop. Microsoft SoftGrid for Terminal Services is available as a standalone client access license to enterprise customers under Microsoft Volume Licensing agreements. To download a trial version, log in to your Volume Licensing account at
https://licensing.microsoft.com and select Desktop Optimization Pack for SA under Product Downloads.
Ahmer Sabri is a Technical Specialist in the Financial Services Group at Microsoft. Ahmer can be reached at ahmers@microsoft.com.
Kedar Shah is a Technical Specialist in the Financial Services Group at Microsoft. Kedar can be reached at kedars@microsoft.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.