Microsoft’s solution to application compatibility and manageability
|
Executive Summary: Microsoft’s SoftGrid is an application virtualization solution. Microsoft’s SoftGrid provides a sandbox-type environment called SystemGuard that lets virtualized applications run on users’ systems without requiring local operating system (OS) installation. The SystemGuard virtual application environment contains all the elements a virtualized application might need to access. |
I'm always astounded by the sheer volume of technologies that exist just in the Microsoft infrastructure space. Deciding which technologies to make a priority, and determining which ones will make your life easier (including whether a technology might change how you manage and maintain your organization), is a constant process.
As the sidebar "The Benefits of Application Virtualization," explains, recent advances in client and server management and OS virtualization have made software deployment easier than ever, but problems with application compatibility and manageability persist. Application virtualization lets you run applications locally, which prevents server-based computing's resource wastage, single points of failure, and limitation to working online. Microsoft's SoftGrid application virtualization solution provides a sandbox-type environment called SystemGuard that lets applications run on users' systems without requiring local OS installation.
SoftGrid's Virtual Environment
SystemGuard is a virtual application environment that contains all the elements an application might
need to access, such as files, registry information, COM objects, and environment information. Although
SoftGrid-enabled applications don't require installation on the host OS, they do communicate with the
OS in a controlled manner to avoid duplicating too much data in the virtualized space.
As Figure 1, shows, the application communicates with what it sees as normal OS facilities within the SystemGuard environment, with full read and write access. SystemGuard then communicates with the actual OS, using strict controls. Configuration information can be read but never modified. Profile and document data can be changed in the OS, which lets you save data and maintain an application's environmental preferences between sessions.
The virtual environment consists of several virtual elements for OS areas that applications use. For example, the Virtual Registry works as an overlay to the actual OS registry. If an application tries to read from the registry and the registry data isn't in the Virtual Registry overlay, the read request is passed to the OS, as Figure 2, shows. Write requests are always made into the Virtual Registry overlay. The same process works for the Virtual File System. For example, this overlay ensures that dynamic link libraries (DLLs) used by an application are always read from the SystemGuard environment first to avoid any conflicts with local versions. If an application relies on a service, the Virtual Services component lets the service function within SystemGuard, unknown to any other application running on the OS. Virtual subsystems also exist for the COM environment, .ini files, process environment, and fonts.
Overhead
SoftGrid's SystemGuard adds less overhead to
your environment than you might think. Other
than the disk space used to cache the application, which is generally less than for a locally
installed application, a virtualized application uses less than 1 percent more CPU than
a nonvirtualized application. This is because
most of the additional processor usage occurs
when SystemGuard first initializes and an
application opens, not while the application
is running. In addition, memory usage is actually lower for running virtualized applications
versus nonvirtualized applications.
Memory overhead can be broken down into paged pool and nonpaged pool. Most applications operate within paged pool memory. Paged pool content can be paged to disk as necessary, and the memory used for a virtualized application is the same as for a locally installed application. The only additional memory used is 20MB for the SoftGrid client. Nonpaged pool memory is used for important OS information that can't be paged to disk.
Configuration data (e.g., registry data) is typically pulled into the kernel during computer start-up. As applications are installed, the registry grows and takes up more space, leading to longer boot times (for HKEY_LOCAL_ MACHINE and HKEY_CLASSES registry areas) or longer logons (for HKEY_CURRENT_USER areas).
For SoftGrid applications, nothing is written to the machine registry. Information needed by the application is loaded at runtime as necessary. Imagine having 40 applications installed locally but running only 10 of them—the registry would bloat significantly as nonpaged pool memory was used up. Running virtualized applications saves 75 percent of nonpaged pool memory.
Network bandwidth is also saved because SoftGrid pulls virtualized applications and components to the client on demand. Initially, the client has just an application's shortcut icon on the desktop. When an application is used, SoftGrid pulls the application down in a sequenced form, allowing very fast application start-up. Only the parts of the application that are needed are pulled down, which uses less disk space on the client.
Another interesting benefit is that when you use SoftGrid with terminal servers, the "therapeutic reboot" isn't necessary. SoftGrid has a highly contained execution footprint and performs an efficient garbage collection process when an application closes.
SoftGrid Components
The SoftGrid suite has five major components
that let you create SystemGuard applications
and deploy them to clients.
Additional components are available that integrate with Microsoft's System Center Configuration Manager (SCCM) solution to let you use SCCM for distribution. In addition, a separate client is designed for terminal server–type environments (including Citrix). Although I don't have space to discuss these components, you should be aware of them in case you use SCCM or terminal servers in your environment.
Installation and
Configuration
The first step in using SoftGrid is to install
the System Center Virtual Application Server
component, which has reasonable software
and hardware requirements. A data store
is required for storing information such as
application usage, licensing, and server configuration. The data store can be hosted on
SQL Server 2005 or SQL Server 2000, as well
as on Microsoft SQL Server Desktop Engine
(MSDE) in test environments. The data store
doesn't need to be on the same server as the
application, although it should be on the same
local network.
A directory service such as Active Directory (AD) is also required for the SoftGrid suite to function. A Windows NT 4.0 domain is sufficient, but I'd be surprised if someone were forward thinking enough to use application virtualization but were still running NT 4.0. During installation, you must specify an account with read access to the directory service. You also need two global groups to identify SoftGrid administrators and users who can use SoftGrid's services. If all users in the domain need access to SoftGrid, you can add the Domain Users group to this global group.
You can install SoftGrid on Windows Server 2003 or Windows 2000 Server. The SoftGrid Management Console runs on Windows 2003 or Windows XP and requires .NET Framework 1.1 and Microsoft Management Console (MMC) 3.0, which is included in Windows 2003 R2 and can be downloaded from Microsoft for other OS platforms.
The SoftGrid System Center Virtual Application Server component requires a Pentium III 1GHz processor, at least 512MB of memory, and 200MB of disk space. The more applications you virtualize, the more disk space you'll need. You can use the Windows load-balancing functionality or hardware load balancers to install and balance multiple SoftGrid Virtual Application Server machines.
To protect the data store, don't use MSDE in a production environment. MSDE has limited recoverability and replication capabilities, as well as limited management options. If you're running multiple SoftGrid servers in an environment that requires high availability, use SQL Server and Windows clustering services to remove any single points of failure.
SoftGrid's documentation includes detailed installation instructions. Be sure that you've read and met the prerequisites of creating an AD account and groups for SoftGrid to use, as Figure 3 shows. To reduce administrative overhead, you can set the AD account password to never expire. However, doing so might cause security problems. Establish a routine for regularly changing the password. Then, you can use the SoftGrid Management Console's Account Authority property settings to easily update the password, as Figure 4 shows.
During installation, you're prompted for various pieces of information, including the following:
After installation is complete, the SoftGrid Management Console is available in the Administrative Tools program group. On first execution, the Management Console asks for the SoftGrid system to connect to. SoftGrid operates over port 80 and requires the name of the SoftGrid Management Web Service. As I already explained, the Management Console never communicates with the data store directly; all communication occurs through the Management Web Service.
More to Come
Application virtualization is a hot trend. Microsoft's SoftGrid lets you easily virtualize applications without requiring a lot of overhead.
In addition, the SystemGuard environment
lets applications run simultaneously without
encountering any compatibility issues. To test
the product, I experimented with virtualizing
Microsoft Office XP and Office 2003; I found
the process to be very smooth and intuitive.
In a subsequent article, I'll explain how to use
SoftGrid to virtualize applications.
