Video Screencast Help

Chapter 3: Understanding Software Virtualization Solution

Created: 07 Jun 2007 • Updated: 12 Feb 2013 | 2 comments
Language Translations
Admin's picture
+1 1 Vote
Login to vote

This chapter helps you understand Software Virtualization Solution (SVS) and includes the following topics:

  • How Software Virtualization Works
  • Software Virtualization Solution Usage Scenarios
  • Software Virtualization Solution Limitations
  • Software Virtualization Solution Glossary

How Software Virtualization Works

An application or set of data is virtualized by using a capture process that creates a Virtual Software Package (VSP). A VSP contains all the files and registry settings of the application or data. A VSP can be used on a client computer that has the Software Virtualization Agent. The VSP is installed to a special area on the hard drive. After the VSP is activated through the Software Virtualization Agent, the application becomes visible along with its files, folders, and settings. Even though it is a "virtual" application, it looks and behaves like any other application to the end user.

This section describes the following topics:

  • Software Virtualization and Redirection
  • Virtual Software Package Architecture
  • Layer Architecture
  • Layer Actions and States
  • Software Virtualization and Variablization

Software Virtualization and Redirection

Each Virtual Software Package (VSP) is managed by SVS as a distinct entity. When activated, VSPs are like "layers" over the base Windows operating system so the system appears to contain the aggregate contents of the base operating system plus the active VSPs.

When a VSP is imported onto a computer, the contents of the VSP (both files and registry settings) are placed in a folder in a special protected SVS area on the hard dive, referred to as the SVS redirection area.

When a VSP is imported on a client computer, the contents of the VSP are placed in the redirected folder, such as C:\fslrdr\1. When the VSP is activated on a client computer, the contents of the VSP are made available to the user. The files and settings appear to the user in the location they would be in if the application had been installed on the computer.

Example: You have a VSP for Mozilla Firefox. When the Firefox VSP is activated, all the contents of the VSP are "layered" over the base file system and registry to make it visible to the user. The user then sees it's appropriate folders, files, registry settings, and shortcuts. When the contents are made visible, they are not displayed in the hidden area, but they are displayed in the locations that the user would see them had Firefox been installed on the computer. Example: Even though the Firefox application file may physically be located at

C:\fslrdr\1\PROGRAMFILES\Mozilla Firefox\firefox.exe 

to the user, it is visible as

C:\Program Files\Mozilla Firefox\firefox.exe 

Software Virtualization Solution accomplishes this by using a filter that intercepts requests to the file system and registry, and when needed, redirects requests to the active VSPs. Software Virtualization Solution uses the SVS File System Filter Driver to aggregate the real and virtual file systems into one view for the end-user. The SVS File System Filter Driver is the main component of the Software Virtualization Agent. The Software Virtualization Agent must be installed on any computer that you want to use VSPs on.

Example: The Firefox VSP is active. When a user browses to C:\Program Files\, all the subfolders in the actual file system folder appear, but the filter driver also looks at any active VSPs, and in this case, also displays the folder C:\Program Files\Mozilla Firefox.

With redirection, SVS can maintain discrete settings and file versions for different applications on a single system. By working with VSPs, a required version of a file will never be overwritten. This is particularly important when you are working with Dynamic Link Libraries (DLL). Incompatible .DLL files are known to cause application instability. By using applications within VSP, you can ensure that applications use its own set of .DLL files without interfering with the rest of the operating system or other applications running at the same time.

This extends not only to files that relate to applications, but also to registry settings and data files.

Virtual Software Package Architecture

A Virtual Software Package (VSP) is a generic term used for a set of captured data in its complete life-cycle while being managed by SVS. A VSP can be in one of two formats: a "Virtual Software Layer" or a "Virtual Software Archive" file.

Virtual Software Layers

When an application or set of data is captured into a Virtual Software Package, everything that is captured is contained in a "layer." The "layer" represents all the files and registry settings that make up the virtualized application or data.

Typically, one layer is created for one application. However, one layer can contain multiple applications. Each layer is managed as a single entity.

The files and settings captured in a layer are stored in the SVS redirection area on the computer's hard drive. However, when a layer is active, all files and settings appear in the system just as they would if the application or data was installed on the computer. This is accomplished through redirection using the SVS File System Filter Driver.

Virtual Software Archive (VSA) files

If you want to make a layer portable so that it can be used on another computer, the contents of the layer are exported to a single Virtual Software Archive (VSA) file. These archive files have a .VSA extension.

VSA files can then be copied or deployed to other computers. To make the contents of the VSA usable on a computer, the VSA must be imported using the Software Virtualization Agent. When a VSA is imported on a computer, the layer (the files and registry settings in the VSA) are installed to the SVS redirection area on the client computer's hard drive.

Virtual Runtime Archive (VRA) files

Software vendors can create a Virtual Software Package (VSP) that includes their product in a Virtual Runtime Archive (VRA) file. This package includes the vendor's product plus the basic components of SVS that are needed to use the vendor's product. This lets developers distribute their software as a VSP, even when a customer does not own SVS.

Note You can only create .VRA files with Wise Installation Studio 7.0 SP1 or later. For details, see the Wise Virtual Package Editor Reference in Wise Installation Studio 7.0 SP1 or later.

For information see Using Software Virtualization Solution in Runtime Mode.

Layer Architecture

There are two components or sublayers in a layer:

Read-only sublayer Contains all captured files and settings.
Writeable sublayer Contains any files or settings that are added or changed by a user of a layer.

Example: You create a layer for Firefox. As a person uses Firefox, they may make some changes to the program. They may select a unique home page, add bookmarks, or change the original security settings. They may also install a browser plug-in. Those user changes are stored in the Writeable sublayer. The original files and settings are maintained in the Read-only sublayer.

Having these distinct sublayers is useful in being able to reset a layer. When a layer is reset, any data added by a user is deleted, and the layer is returned to its original configuration.

Example: If a user's Firefox application ever becomes damaged, you can simply reset the layer to restore it to the way it was first deployed. The application does not have to be uninstalled/reinstalled.

Resetting layers also maintains specific versions and configurations of applications across your network. You can control how the applications are installed and configured on client computers.

Note The two sublayers currently apply only to virtualized application layers, not data layers.
Caution When you reset a layer, any data that is written to the Writeable sublayer will be lost. For information, see Resetting Layers.

Layer Actions and States

You can perform the following actions on layers:

Name Description
Layer Actions  
Import The layer files in a VSA file are installed in the hidden SVS redirection area on the client computer. However, imported files are not visible until the layer is activated.
Activate The layer files that have been imported on a client computer are made visible to the user. Activation and deactivation occur almost instantaneously.
Deactivate The imported layer files are hidden from the user but are kept on the computer.

Note You cannot deactivate a layer while a process is running from that layer. For information, see Deactivating Layers with Services Running.
Deactivate (Force) The layer is forcefully deactivated by killing all the running applications from that layer. This might cause undesired results.
Delete The imported layer files are removed from the computer.
Delete (Force) The layer is forcefully removed by killing all the running applications from that layer. This might cause undesired results.
Reset Deletes all of the user's profiles in a layer that were added or changed. The data in the Writeable sublayer is deleted, leaving only the files in the Read-only sublayer. See Resetting Layers. Note Data layers cannot be reset. Hence, "Reset", "Reset and Activate" and "Reset and Deactivate" are not available for data layers.
Reset (Force) Deletes all of the user's profiles in a layer that were added or changed, killing all the running applications from that layer. This might cause undesired results.
Layer States  
Activated The imported layer files are made visible to the user.
Deactivated The imported layer files are hidden from the user.
Combination of Actions and States  
Import and Activate The layer files are placed in the SVS redirection area on the client computer and are made visible to the user.
Reset and Activate The layer files are reset to their original imported state by deleting all user data and changes (Writeable sublayer), and the layer is visible to the user.
Reset and Deactivate The layer files are reset to their original imported state by deleting all user data and changes (Writeable sublayer), and the layer is not visible to the user.

Software Virtualization Workflow

The following diagram illustrates a typical Software Virtualization workflow:

 

  1. Using Software Virtualization Solution tools (SVS Admin), capture an application into a layer.
  2. To make the layer portable, export the layer to a Virtual Software Archive (VSA) file.
  3. Deploy the VSA to a client computer.
  4. Import the VSA into a layer on the client computer.
  5. Activate the layer to access the application.

Software Virtualization and Variablization

Many applications have specific environment settings for file paths, paths in registry values, MSI paths, and so forth. To make VSPs portable across computers, many application settings and data layer properties are variablized by Software Virtualization Solution.

Example: SVS uses common system variables to substitute for well-known locations on a Microsoft Windows based installation, such as WINDIR as a substitute for the "Windows" folder. This provides seamless compatibility with systems that may not be using the standard folder structure, such as systems that have moved their "My Documents" folder or that have renamed OS folders.

Example: If you have a VSP for My Documents, it may be on C drive on one computer but on D drive on another computer. Variablization allows the data layer to work correctly on both computers. For information, see View Variables used in a Layer.

Software Virtualization Solution Usage Scenarios

This section describes the different ways you can use Software Virtualization Solution.

  • What Can be Virtualized?
  • What Cannot be Virtualized?
  • How are Applications and Data Virtualized?
  • How Can Virtual Software Packages be Used?
  • How does Software Virtualization Solution Affect my Network?
  • How does Software Virtualization Solution Affect Client Computers?

What Can be Virtualized?

You can virtualize applications and collections of data.

Application Layers

Most every application can be virtualized, including office applications, databases, Internet browsers, media, and spyware utilities. Applications function normally when virtualized by SVS. All functionality and configuration options are available to the user.

Data Layers

You can also redirect user data to be stored within a layer. (Example: All files created with a .DOC extension can be stored within a layer, letting users easily group their documents together. Users can also define folders in the same way.) (Example: The "My Documents" folder can be redirected to a data layer.) By giving multiple paths and directing that content to a data layer, you can manage all user content invisibly. Coupled with the layer import/export function, this lets a user copy not only an application from one machine to another, but also all of their customizations and files. By having data files in their own layers, those files are protected when application layers are reset and writeable data in those layers are lost. For information, see Creating and Using Virtual Data Layers.

What Cannot be Virtualized?

Some applications and file types do not work well virtualized at this time. For information, see Software Virtualization Solution Limitations.

How are Applications and Data Virtualized?

Virtualized applications and data are captured into Virtual Software Packages using the capture tools Software Virtualization Solution Admin (SVS Admin), an SVS Control Panel Applet, or through SVSCMD command line functionality that is installed with SVS Admin. Virtual Software Packages contain all the files and registry settings required for an application to run.

How Can Virtual Software Packages be Used?

Virtual Software Packages are highly portable and can be easily used between different computers and Windows operating system versions. The virtualization technology is invisible to the user, the applications, and operation system, yet virtualized applications and data are visible system-wide and execute normally.

You can use Virtual Software Packages in the following environments:

  • Using Software Virtualization Solution Stand-alone
  • Using Software Virtualization Solution in an Altiris® Notification Server Environment
  • Using Software Virtualization Solution in an Altiris® Deployment Solution™ Environment

Using Software Virtualization Solution Stand-alone

You can use Virtual Software Packages in a stand-alone environment on Windows-based computers. To use Virtual Software Packages, install the Software Virtualization Solution Admin tool on a computer and then create or import existing Virtual Software Packages. For information, see Getting Started with Virtual Software Layers and Archive Files.

You can use the Software Virtualization Solution for Personal Use version to create and use your own virtual layers in a single-computer environment.

You can also make VSA files available to network users by using network shares, login scripts, SMS, and so forth.

For information, visit the Juice at http://www.altiris.com/juice.

Using Software Virtualization Solution in an Altiris® Notification Server Environment

Using the Notification Server-based Software Virtualization Solution, you can remotely deploy Virtual Software Packages to client computers on managed computers on your network. You can also remotely control the state of the Virtual Software Packages on client computers and view reports about Virtual Software Packages deployment and usage. Software Virtualization Solution is also integrated with Altiris® Inventory Solution™ and the Altiris® Software Delivery Solution™ Software Portal. For information, see Using Software Virtualization Solution in a Notification Server Environment).

Using Software Virtualization Solution in an Altiris® Deployment Solution™ Environment

Using Software Virtualization Solution and Deployment Solution, you can remotely deploy Virtual Software Packages to client computers on your network. For information, see Using Software Virtualization with Altiris® Deployment Solution™.

Using Software Virtualization Solution in Runtime Mode

Runtime Mode lets application developers distribute their software in an Altiris VSP, even when a customer does not own SVS.

Software vendors using Wise Installation Studio (7.0 SP1 or later) can create a special type of VSP that includes their application as a Virtual Runtime Archive (VRA) file.

These VSPs include an automated installation of the SVS Agent that runs in runtime mode.

A .VRA's package can do the following:

Install the SVS Agent (if needed) in Runtime Mode. Import the .VRA file. Activate the layer.

When the SVS Agent is licensed it is in Standard Mode and all SVS functions are available on all layers. When the SVS Agent is configured in runtime mode it can perform limited SVS actions.

Runtime Mode Actions

SVS Action Runtime Layers Standard Layer
Create New Layer - -
Export to Archive - -
Import from Archive X -
Activate Layer X -
Reset Layer X -
Update Existing Layer X -
Exclude Entries X -
Activate On Start X -
Deactivate Layer X X
Delete Layer X X
Rename X X
View Layer Properties X X
Note When the SVS Agent is in Runtime mode, it will not allow any Data Layer functions.

If you inadvertently have a client computer running the SVS Agent in Runtime Mode, you can add a valid license that will put the SVS Agent into standard mode.

A license can be added or removed from the SVS Agent and the data will not be affected, so the SVS Agent can change its status back and forth between Standard Mode and Runtime Mode without risk of data loss. Layers are not deleted when the SVS Agent's mode changes.

Note You can only create .VRA files with Wise Installation Studio 7.0 SP1 or later. For details, see the Wise Virtual Package Editor Reference in Wise Installation Studio 7.0 SP1 or later.

How does Software Virtualization Solution Affect my Network?

  • What Demands does SVS place on the Physical Network?
  • Are there Minimum Bandwidths Requirements for Deploying Virtualized Applications to Off-site Users?
  • Are there Requirements for Microsoft Active Directory to Support SVS?
  • Does SVS Use any of the Native Microsoft MSI Methods for "Application distribution"?
  • How does SVS Work with Recovery Solution and other Backup Products?

What Demands does SVS place on the Physical Network?

SVS does not add any unique demands on a network. When used in a Notification Server environment, the only demand is during the initial package delivery, the same as with Software Delivery Solution. All of the same tools available in Software Delivery Solution (multicasting, bandwidth throttling, automatic resume of failed transfer, and so on) are available to you to maximize bandwidth usage. However, Software Delivery Solution is not required (both products use the same back-end architecture for management).

Are there Minimum Bandwidths Requirements for Deploying Virtualized Applications to Off-site Users?

There is no "recommended" minimum bandwidth, although the Altiris framework provides tools to help make distributions to remote users easier (see What Demands does SVS place on the Physical Network?), including the ability to require a minimum bandwidth before attempting a download. VSPs can be deployed on Package Servers and Deployment Servers.

Are there Requirements for Microsoft Active Directory to Support SVS?

There are no additional configuration requirements for SVS to work with Microsoft Active Directory. At this time, there is no specific interaction between Active Directory and SVS.

Does SVS Use any of the Native Microsoft MSI Methods for "Application distribution"?

You can use "Live Capture" to deploy an .MSI using Software Delivery Solution. When doing this, a capture is started on the client before the install runs and ended after the install ends. The result is a virtualized application. This allows customers to leverage their existing .MSI libraries but results in dissimilar instances of the VSP on every workstation.

However, for greater manageability, we recommend performing a single installation in a controlled environment, then optimizing and testing a standardized VSP to deploy to every client computer.

How does SVS Work with Recovery Solution and other Backup Products?

If a client computer is protected using Recovery Solution or a similar backup application, the SVS redirection area shows in the Recovery Solution name space, and can be part of snapshots. Layers can be successfully restored through a Full System Recovery or full Rollback. Using these methods, the entire redirection area with accompanying registry settings are restored and will function correctly.

However, full functionality is not possible if only files from the redirection are restored. For this reason, a simple restore of files from the redirected folder (Example: C:\fslrdr, C:\fslrdr\1) should not be done through Recovery Solution. Instead, the whole system needs to be restored together.

How does Software Virtualization Solution Affect Client Computers?

  • Are there Special Requirements for Running Virtualized Applications?
  • How SVS Affects Local Drive Space Usage in Windows
  • How SVS Affects Local Drive Space Usage in Windows

Are there Special Requirements for Running Virtualized Applications?

SVS requires no additional hardware requirements. You only need to install the Software Virtualization Agent. The SVS File System Filter Driver is around 160 KB and consumes less than 1 MB of working memory under heavy load.

How SVS Affects Local Drive Space Usage in Windows

SVS affects drive space utilization in a way that may not be obvious. Layer files and directories are stored in a redirection area. The drive where this area is located will show space being utilized. In the case where the redirection area is located on the same drive as the applications, space utilization will appear as normal. When the redirection area is located on a different drive from where the applications are installed, the application drive will appear to have more free space than expected while the redirection-area drive will show more used space.

When the hidden redirection area that layers are stored on is on the client computer's C drive, and the default redirect area is left unchanged, the C drive must have enough free space to accommodate all desired layers, and the drive space usage statistics for the C drive will reflect these files.

However, if the layer is pointing to the D drive, the files are still physically on the C drive, not the D drive. Example: Suppose you have a layer for an application like MS Office that is pointing to a D drive (used as an "apps drive"). Drive space usage statistics for the D drive will not reflect the files, but statistics for the C drive will.

Note The redirect area is not confined to only the C drive. It can also be moved to a NTFS or FAT drive. However, for security reasons, we recommend that the redirect area reside in an NTFS file system.

Software Virtualization Solution Limitations

The following are current limitations of Software Virtualization Solution:

What Things Cannot or Should not be Virtualized?

  • SVS File System Filter Driver and Running Windows in Safe Mode
  • What Things Cannot or Should not be Virtualized?

Some applications do not work well virtualized at this time. These include drivers, virus checkers, file encryption products, OS patches, computer management agents, and applications that have dedicated drivers (Example: client firewalls).

You cannot encrypt files that are stored in a data layer. If you encrypt a folder that is in the layer, the folder is moved to the base. When files are moved to that folder, you get an error that the files cannot be encrypted and you can move them into the layer only as unencrypted files.

SVS File System Filter Driver and Running Windows in Safe Mode

The SVS File System Filter Driver is not loaded when a computer is booted into Windows Safe Mode. Any diagnostic or recovery utilities that could be usable in safe mode to diagnose and recover a system should not be included in a layer. These utilities will not be available if they have been added to the system through a layer, thus possibly making it too late to recover after they become necessary.

Software Virtualization Solution Glossary

File Delete Entries and Registry Delete Entries

When an application that is running from a layer deletes a file or registry setting outside of the layer, the file or setting is not actually deleted, but hidden while the layer is active. These hidden files and registry settings are called file delete entries and registry delete entries.

Global Exclude Entry

You can configure a system to exclude file types or folder locations on a global level. This is done so that a file will not be redirected by the SVS File System Filter Driver to the layer. Instead, the file is saved to the core file system. These entries can be file type extensions or directory locations.

Layer Exclude Entry

You can configure a layer to exclude file types or folder locations from capture. This is done so that a file will not be redirected by the SVS File System Filter Driver to the layer. Instead, the file is saved to the core file system.

Runtime Mode

Runtime Mode lets application developers distribute their software in an Altiris VSP, even when a customer does not own SVS.

Software vendors using Wise Installation Studio (7.0 SP1 or later) can create a special type of VSP that includes their application as a Virtual Runtime Archive (VRA) file.

These VSPs include an automated installation of the SVS Agent that runs in runtime mode.

The SVS Agent can move between Standard Mode and Runtime Mode without risk of data loss; layers are not deleted when the license mode changes.

When the SVS Agent is in Runtime Mode, it can perform limited SVS actions.

Note You can only create .VRA files with Wise Installation Studio 7.0 SP1 or later. For details, see the Wise Virtual Package Editor Reference in Wise Installation Studio 7.0 SP1 or later.

Standard Mode

Standard Mode is a term used when it is necessary to distinguish the Agent's status as being either in Standard Mode or Runtime Mode. In Standard Mode all SVS functions are available on all layers.

The SVS Agent can move between Standard Mode and Runtime Mode without risk of data loss; layers are not deleted when the license mode changes.

SVS File System Filter Driver

The SVS File System Filter Driver is a Windows NT technology that manages the data flow between applications and the operating system.

Software Virtualization Agent

The agent software on a client computer containing the SVS File System Filter Driver that manages Virtual Software Packages.

Software Virtualization Solution Admin (SVS Admin)

The Software Virtualization Solution Windows-based tool used to create, edit, and export Virtual Software Layers. You can also use SVSAdmin to manually manage layers on a client computer.

SVS Applet

The SVS applet is installed when you install the Software Virtualization Agent. It is available from the Control Panel and lets you create, import, export, and manage SVS layers.

SVS redirection area

When a VSP is imported onto a computer, the contents of the VSP (both files and registry settings) are placed in a folder in a special protected SVS area on the hard dive, referred to as the SVS redirection area. The SVS redirection area is a folder named C:\fslrdr.

SVS Task Server Plug-in

SVS Task Server Plug-in adds functionality to the Altiris® Task Server that lets you manage SVS layers on client computers. The Task Server is an infrastructure component that provides task sequencing and automation for Altiris solutions.

Virtual Runtime Archive (VRA)

Software vendors can create a package that includes their product in a Virtual Runtime Archive (VRA) file, plus the basic components of SVS that are needed to use the vendor's product. This lets developers distribute their software in an Altiris Virtual Software Package (VSP) even when a customer does not own SVS.

Note You can only create .VRA files with Wise Installation Studio 7.0 SP1 or later. For details, see the Wise Virtual Package Editor Reference in Wise Installation Studio 7.0 SP1 or later.

Virtual Software Package (VSP)

The generic term for all the files that makes an application work, including applications and data, files and registry settings. A Virtual Software Package can be in one of two formats: a "Virtual Software Layer" or a "Virtual Software Archive" file.

Virtual Software Layer

A Virtual Software Layer is the base collection of files and registry definitions and data for a Virtual Software Package.

When a layer is imported to a client computer, the data from the layer is placed in a hidden SVS redirection area. When a layer is activated, the contents of the layer are overlaid over the base file system and registry and the contents of the layer appear as if it had been installed.

There are two kinds of layers: Application layers and Data layers.

Layers contain two sublayers: the Read-only sublayer and the Writeable sublayer.

Virtual Software Archive (VSA)

The portable version of a Virtual Software Package. A Virtual Software Archive contains the compressed data from a layer in a single portable file that can be deployed and imported on client computers.

Virtual Software Package resource object

The deployed payload when deploying VSA files in a Notification Server environment. These are similar to Software Delivery Packages used with Software Delivery Solution.

Chapter 2: What's New in SVS 2.1

Chapter 4: Getting Started with Virtual Software Layers and Archive Files
 

Comments 2 CommentsJump to latest comment

Olga Shmukerova's picture

FYI - both links in the end of the chapter are out of date and do not lead where they are supposed to.

0
Login to vote
ohzone - CherylPeterson's picture

Thanks Olga, these links have been fixed now.

Cheryl

Endpoint Management,
Endpoint Virtualization
Managing Mobility
Community Manager
www.twitter.com/EMnV_symc
Need Altiris help? IRC chat #Altiris

0
Login to vote