Jordan Sanderson (Test Team) and Jonathan Green (Doc Team) logged more hours than they care to remember pulling this guide together. (But we're glad they did!) If you ever had a question about updating your SVS Virtual Software Packages, you can bet the answer is contained herein.

• VSP Layer Architecture
  • Readable and Writable Sublayers
• Considerations when Updating VSPs
• Create a New VSP or Update an Existing VSP
  • Deciding which Sublayer to Update
  • Deciding where to Update
    • Updating from a Software Library
    • Updating Locally
• Creating a New VSP
• Updating an Existing VSP's Read-only Sublayer
  • Step 1: Updating the Read-Only Sublayer of an Existing VSP
  • Step 2: Assigning a New Layer Name and Layer GUID
  • Step 3: Exporting the VSP
• Using WiseScript Package Editor for Read-only Updates
• Using the SVS SDK for Updates
• Updating the Writeable Sublayer of Existing VSPs on Local Computers
• Deploying VSP Updates
  • Using SVS and AppStream Integration with Updates
    
    • Upgrading VSPs with AppStream
  • Using SVS in a Notification Server Environment

This article describes how you can update applications that have been deployed in the Altiris® Virtual Software Package™ (VSP™) format.

The method you choose for managing and deploying your VSP updates depends on:

• The importance of the data that is contained in the VSP.
• The amount of change that is contained in the update.
• The frequency of change that the application is subject to encounter.
• How critical the application is.

For these reasons, there is no single "best practice" for updating VSPs but rather many approaches. Each approach has its advantages and disadvantages. Individual environment and administrative requirements will directly influence your decision making when selecting which approach is best for your situation. This document assumes a familiarity with VSP layer data flow.

VSP Layer Architecture

Updating VSPs requires an understanding of how data is managed within VSP layers.

When an application or data set is captured into a VSP, all of the application's data and registry settings are contained in a virtual software layer. When activated, the layer is placed over the base Windows operating system through the SVS Filter Driver. The system appears to contain the aggregate contents of the base operating system as well as the active VSP. When the layer is deactivated, its contents are hidden.

Layering Data through the SVS Filter Driver

Click to view.

Readable and Writable Sublayers

VSP virtual layers are divided into two subsections: a Read-only sublayer and a Writeable sublayer.

• The Read-only sublayer contains all of the original application files and settings that are captured. It is the application's initial instance in the VSP capture. If you need to reset the layer, the application returns to containing only the files and settings contained in the Read-only sublayer.
• The Writeable sublayer contains any files or settings that are added or changed during the use of the application. It is the current state of the VSP, containing all subsequent patches, updates, and user-specific customizations and preferences not originally stored in the initial capture of the VSP's Read-only sublayer.

For a more in-depth discussion of SVS Layer Architecture theory, see Understanding Software Virtualization Solution in the Software Virtualization Solution Reference Guide at http://www.altiris.com/Support/Documentation.aspx#....

Considerations when Updating VSPs

Consider the following when you prepare to update your VSPs:

• Do want to update an existing VSP, or does this update warrant creating an entirely new VSP?
• Which sublayer do you want to contain the update data?
• Do you intend to deploy the update from a software library or do you want to update the computers locally?
• Do you have applications that have special requirements that the SVS SDK can address?
• If you intend to deploy the update, are you using application streaming in your environment? Are you using an Altiris® Notification Server™ environment or an Altiris® Deployment Server™ environment?

Considerations

Click to view.

Create a New VSP or Update an Existing VSP

If you decide to update the Read-only sublayer, then you should update the VSPs in your software library (see Deciding where to Update) unless you have special requirements that you intend to address with the Altiris SVS SDK (see Using the SVS SDK for Updates).

When planning a VSP update, you must decide whether the update warrants re-creating a new VSP from scratch and replacing a user's previous VSP with a new one.

Creating New Replacement VSPs

See Creating New Replacement VSPs

Updating Existing VSPs

See Updating an Existing VSP's Read-only Sublayer

Deciding which Sublayer to Update

You must decide whether the VSP requires an update of the Read-only sublayer or the Writeable sublayer.

Updating the Read-only Sublayer

See Deciding where to Update

Updating the Writeable Sublayer

Deciding where to Update

You must decide whether the update should be done from the central IS team's software library or whether the update should be done on the local computer. If you intend to update the Read-only sublayer, in most instances, this will be done from the software library. If you intend to update a VSP's Writeable sublayer, in most instances, this will be done on the user's local computer.

For example, Adobe Acrobat* Reader provides an automatic update feature. Because of this feature, you may decide to allow the local applications to update themselves. If the VSP is reset, the update can be reapplied. On the other hand, you may decide that you do not want users making any updates at all, or that a particular update is critical and that you need to first update the VSP in your library and then redeploy it to your client computers.

VSP Workflow

Click to view.

Updating from a Software Library

When updating from a software library you should update the Read-only sublayer. Do not push out a VSP containing any data stored in the Writeable sublayer because if the VSP requires a reset, all of the data will be lost. If an update to an application is important enough to have an IT administrator perform it, update the library, and push it out to the client computers, then the adjustment should be stored in the Read-only sublayer of the VSP to protect it.

See Create a New VSP or Update an Existing VSP

Updating Locally

If the update is frequent, small, and not crucial, consider simply updating the Writeable sublayer on a client computer locally. However, if the VSP ever requires a reset, the update will be lost and must be reapplied. A local Writeable sublayer update is performed either by deploying an .MSI or .EXE and launching it on the client computers, or when an application's "automatically download and install updates" feature is run.

When you deciding whether or not to update the Writeable sublayer, consider how much data you can afford to store in the Writeable sublayer that is subject to loss through reset. If keeping the update permanent is essential, you have to update the Read-only sublayer and redeploy the VSP from your software library.

See Updating the Writeable Sublayer of Existing VSPs on Local Computers
See also Using the SVS SDK for Updates

Creating New VSPs

1. On a base computer, make sure you have access to the setup files for the application you will be creating a layer for.
2. Select File > Create New Layer.
3. Select Install application and click Next.
4. Name the layer.
5. Click Next.
6. Select Single program capture
7. Click Browse.
8. Navigate to the setup file.
9. Click Next.
10. Click Finish.
    The animated capture icon (yellow lightning) appears in the system tray. The icon is animated (top to bottom) signifying that you are capturing.
11. Follow any dialogs to install the application.
    When the application's installation is complete, the capture is automatically ended and the layer is listed in SVS Admin.

For steps on exporting layers, see Step 3: Exporting the VSP.

For details about creating VSPs, see Performing Virtual Software Layer Tasks in the Software Virtualization Solution Reference Guide at http://www.altiris.com/Support/Documentation.aspx#....

Updating an Existing VSP's Read-only Sublayer

This method helps ensure that all end users across a network have a uniform, functional version of the VSP. This method works well when a large or crucial update is required and a VSP has already been created that contains configuration stored in the Read-only sublayer. Maintaining rollback ability requires special steps and planning. Changes that are stored in the Writeable sublayer and user-specific settings are lost.

Example: On a dedicated computer, an existing VSP's Read-only sublayer is updated, placed into an archive software library, and distributed through a deployment system.

Applies to:
IT departments with the infrastructure available to perform hot fixes, major patches, and service pack updates on an existing VSP.

You update the Read-only sublayer of an existing VSP by using the SVS Admin tool on a dedicated "clean" virtual machine. Once the updated VSP is captured, you place it into your .VSA library, test, and then distributed it to your end user computers using a deployment method.

Updating Existing VSPs keeps all users' computers as uniform and updated as possible.

Two items should be acknowledged when choosing this method.

• As with any major update, you must test the VSP to ensure that it works correctly before deploying it to your users.
• To maintain rollback ability, special steps are required. See Step 2: Assigning a New Layer Name and Layer GUID

Multiple Versions of the Same VSP on the Same Computer

Rollback is possible and relatively simple using this method, but you must prepare ahead of time. Because you are overwriting the Read-only sublayer, you cannot reset the VSP back to an earlier version. You can solve this problem by keeping an earlier version in an inactive layer stored temporarily on the client computers. If the active version becomes damaged or unusable, you can simply deactivate and remove it, and then revert to and activate the previous VSP. To make this possible, when you update the existing layer assign the layer a new name and a new layer GUID. By doing this you can ensure that both layers can co-exist on the same computer without overwriting each other. While there isn't a native way to rename layer GUIDs in SVS Admin, you can easily accomplish this task using the Layer ReGUID tool on the Altiris® Juice™ Web site. See Assigning a New Layer Name and Layer GUID.

Delta Push Not Available

SVS does not currently allow for a delta push, meaning that there's no option to send only the updated portions of a program-you send either the whole layer or nothing at all. This means that every time you update the Read-only sublayer and distribute it, your users lose their custom settings for the updated program. This also means that distributing the newly updated layer uses more network resources. For this reason, use this method outside of peak network traffic hours. Decide which updates warrant rolling out updates in this manner.

Step 1: Updating the Read-Only Sublayer of an Existing VSP

To update a VSP using the SVS Admin Single Program Capture tool, you must have access to the application's installation executable.

1. On the base computer, open the SVS Admin tool by clicking the SVS Admin icon on the desktop.
2. Select File > Update Existing Layer.
3. Select the layer you want to update.
4. Click Next.
5. Select Single program capture.
6. Browse to the installation executable.
7. Click Next.
8. Click Finish.
9. Make changes.
10. Exit the application.

The capture process terminates.

Step 2: Assigning a New Layer Name and Layer GUID

1. Download GUIDer.exe from the Juice Web site at http://juice.altiris.com/node/160
2. Before importing the VSP, run GUIDer <layer name> from the command line. When successful you'll see "GUIDs changed successfully."

Step 3: Exporting the VSP

To export a layer to an archive .VSA file

1. In SVS Admin, right-click the layer and click Deactivate Layer.
2. Right-click the layer and select Export Layer.
3. Save the file.Example: C:\archives\Firefox5.vsa.
4. Click OK.

Using WiseScript Package Editor for Read-only Updates

Wise Package Studio® software supports virtual software packaging using SVS. Administrators can create, edit, and manage VSPs as well as conventional software packages.

With both SVS and Wise Package Studio, you either capture packages into a layer or create SVS-enabled packages to install into virtual layers on the destination computer.

Using SVS and Wise Package Studio together provides administrators with certain additional advantages, such as the ability to package existing stored .MSI files and setup .EXE files for use as virtual layers. In addition, you can use WiseScript, to edit SVS-enabled packages in their "wrapper" .EXE files to meet computer-specific requirements. You can use Virtual Package Editor to edit .VSA (virtual software archive file) packages.

Because any Altiris tool that creates a VSP uses the same core technology, the WiseScript actions can manage and update any SVS VSP. Script actions make changes to the Read-only sublayer so they are not lost when the layer is reset. The exception is the action Delete File from SVS Layer. The changes it makes are made to the Writeable sublayer. If you reset the layer after you use this action to delete a file, the deleted file is restored.

For details about packaging and scripting with VSPs, see the Wise Virtual Package Editor Reference Guide, and the WiseScript Editor Reference Guide at http://www.altiris.com/Support/Documentation.aspx#....

Using the SVS SDK for Updates

You can use the Altiris SVS Software Developer Kit (SDK) to create tools that customize SVS to work for your custom-built infrastructure and special needs. It is ideal for updating custom, internally developed applications that have been captured as VSPs. By using the SVS SDK, you can create scripts and tools that update an existing VSP's Read-only sublayer locally on the end user's computer. You can also use the SVS SDK to update the VSP in your software library.

Example:
An internally developed application uses an event driven action to perform an automated self update. Whenever the shortcut for the application is launched, the application checks the server for updates and, if they are available, it installs them. You can use the SVS SDK to create a program that forces these updates to be stored into the Read-only sublayer of the VSP without ever requiring any end user input.

You can use the SVS SDK to create a program that inserts updates directly into the Read-only sublayer of an internally developed application that is captured into a VSP. You can insert very specific updates, such as a single registry key adjustment. This can be done silently without affecting the end user. If the layer requires a reset in the future, the update will be preserved. However, there is no native way of rolling back updates performed in this manner.

The SVS SDK exposes the following common functions and abilities:

• Open Key
• Create Key
• Change Key
• Copy Key
• Delete Key
• Close Key
• Open Value
• Copy Value
• Set Value
• Query Value
• Delete Value

Using the SVS SDK requires a certain level of developer ability, understanding of C++, familiarity with the Microsoft Windows registry, and knowledge of your infrastructure and the design elements of your internally developed applications. As there is no native method of rolling back updates applied in this manner, diligent planning and testing of an update before rollout is very important.

The Altiris SVS Software Developer Kit (SDK) is available at http://juice.altiris.com/node/527.

Updating the Writeable Sublayer of Existing VSPs on Local Computers

This allows you and your users to update software in a more traditional manner, while maintaining user-specific settings and keeping the ability to rollback updates easily. The VSP is updated in the same manner as a conventional program. The Writeable sublayer of an activated VSP is updated through an event driven action, and all changes are automatically captured and stored by SVS in the Writeable sublayer. However, this method introduces the risk that if the VSP is ever reset, the update will be lost.

Example:
An application's "automatically download and install updates" feature downloads and installs a patch. This action is captured and changes to the file system and registry are placed into the Writeable sublayer by SVS.

As the update is captured into the Writeable sublayer, the benefits of application rollback are preserved and the rollback process is kept relatively simple through the action of resetting a layer. The user's update experience is kept normal and familiar, and user-specific settings and customizations are preserved through the update. However, if the layer is reset, then all of the updates captured are lost and the updates must be reapplied. If the software has been updated several times since the initial capture of the VSP, then updating the application could be time consuming and difficult.

This practice is most suited for home use or small businesses without an IT department or the infrastructure necessary to deliver updates through a network. Users can update their own software and, if an update causes problems, you can easily reset the layer to a "known good" state. Keeping SVS working in the background keeps users content because they are not required to learn a new technology to update applications. Your service desk is not required to spend much time diagnosing and fixing a problem because all that is required to roll back is resetting the problematic software's layer.

You can use this method with updates that bypass the end user. This is ideal for a company with few computers or for computers that are public (example: a public library). Updating in this manner can be done using a silent .MSI installer through a network. It can be done remotely as well, as long as SVS is on the computer and the software layer that needs patched is active.

Although this method works well in a small business environment or in a situation where an update is minimal or nonessential, it is not ideal for all situations. It is difficult to ensure that every computer on a network is updated to the same level, and simply trusting users to update their own computers can have unwanted risks, such as users simply ignoring important or critical updates. This can be especially problematic if the ignored patch happens to be a critical security update. For these reasons, major and essential updates should be captured into the Read-only sublayer and redeployed.

Deploying VSP Updates

Using SVS and AppStream Integration with Updates

AppStream* provides OnDemand* application availability and delivery through the use of application streaming technology. AppStream also provides user-based management and automated licensing, license harvesting, and license recovery.

SVS and AppStream integrate seamlessly. SVS functions are accessible through the AppStream interface. This integration provides the ability to stream SVS virtualized applications to your users. From a central location, the IT department can define the application's availability, provision, version, and provide virtualization for each user and group. With SVS, you can activate and deactivate VSPs instantly without dramatically altering the base operating system. With AppStream you can quickly deliver the VSPs on demand.

You prepare VSPs for streaming, provision them according to users and groups, and place them on a streaming server. When a user logs on to a computer, application icons are placed on the Windows* Desktop and Start menu. The icons appear the same as if they had been installed traditionally. When the user first launches the application icon, bits of the application are then streamed to the client computer as needed, depending on the areas of application functionality required. For a typical application, only 10%-15% of the application is first required to start running.

To stream updated VSPs, you simply update the VSP, place it on the streaming library, and then, using the AppStream web-based Control and Management Console (C&M), configure the streaming server so that users and groups will point to the version desired. Rather than "pushing" out VSP updates to your network computers, updates are "pulled" from the server to the client computer. When the client computer sends the event of launching an application, the client computer checks in with the server and receives the correct version.

Upgrading, downgrading, rolling back and switching between versions of VSPs is a one-click operation. All you need to do is mark the desired version of the VSP on the AppStream administrator console, as the default. "As soon as this is done, the users and groups that are associated with the VSP use the default VSP." This happens silently and seamlessly when the user launches the application. You can move to and from any version of the VSP.

Upgrading VSPs with AppStream

1. Use the AppStream Packaging Tool to prepare the new version/patch of the VSP for streaming. This can also be automated in a batch file using the command-line interface.
2. Upload the new package to the AppStream administrative console. Both versions of the VSP appear on the C&M.
3. To upgrade a user or a user group, mark the new version as the default.

Refer to the two versions of Adobe Photoshop* in the following image.

Click to view.

The process is complete. Now, when your users attempt to launch the application, the new version is streamed and instantly available for use.

See also:

• Instant Application Delivery and Activation with AppStream and SVS at http://juice.altiris.com/node/706
• Virtual Strategy Magazine Podcast: AppStream and SVS at http://juice.altiris.com/node/718
• AppStream and Altiris Optimize Technologies for Software Control and Cost Reduction here.
• AppStream enables application virtualization here.

Using SVS in a Notification Server Environment

SVS lets you remotely deploy and manage virtual applications and data using Notification Server-based packages and policies. SVS in the Notification Server environment works similarly to Altiris® Software Delivery Solution™ software and shares many features. For details, see Using Software Virtualization Solution in a Notification Server Environment in the Software Virtualization Solution Reference Guide at http://www.altiris.com/Support/Documentation.aspx#....