Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Best Practices for Transitioning to SVS

Created: 23 Jan 2008 • Updated: 29 Jul 2010 | 6 comments
Language Translations
Scott Jones's picture
0 0 Votes
Login to vote

I get a lot of questions about how customers should approach the transition from traditional software installations to virtualized applications. I also spend a lot of time speaking with customers about how they are making the change today and why they chose the approach they are taking. This article is a summary of thoughts on when and how to make the move to SVS, gathered through my conversations with several enterprise IT organizations.


Altiris published a white paper back in July of 2006 called, "Virtualize Your Business Desktop Deployment." It gives excellent guidance on making the transition from traditional installations to virtualized apps. Since SVS was only a few months old at the time, the paper was written primarily based on existing best practices and the experiences that many customers had while standardizing on the MSI format. Much to Danielle and Nelson's credit, after a year and a half of production roll-outs of SVS, we find that they were nonetheless dead-on right. So I recommend that everyone read this:

Several people have said (and I certainly agree) that we should do an updated white paper that incorporates the wisdom of actual SVS experience. Until then, however, please let me share the following thoughts.

The general philosophy is this: 1) Leverage SVS on existing clients immediately where it can alleviate key pain points. 2) As new machines and images are rolled out, virtualize as many apps as possible.

Why do it at all?

To set the stage, here are some of the "key pain points" that customers are addressing with SVS. These are the top four problems that customers cite as the reason they first use SVS in production:

  • A) high cost of delivery and maintenance for poorly-packaged and/or very complex applications
  • B) replacement cost for legacy applications that don't peacefully co-exist with newer apps or that don't work on new base OS builds
  • C) use cases where the productivity gap between a user having a business need for new software and actually having it to use must be minimized
  • D) users (esp. graphics artists, instructors, developers and other technical staff) who need multiple versions of applications readily accessible on the same machine

You'll notice that "A" and "B" are app-specific issues, whereas "C" and "D" are user-specific issues. This means that the initial footprint of SVS in an environment may be a small number of apps on a large number of clients (if your main pain points are "A" and/or "B"), or it may be a large number of apps on a small number of machines (if your main pain points are "C" and/or "D").

A side note: I am purposefully leaving out another common reason why customers are interested in SVS today: to customize the workspace on top of a shared image when using client virtualization solutions such as VMware VDI, HP CCI and Citrix Provisioning Server for Desktops (formerly Ardence). While most of the same value props of SVS apply, the main motivation for using app virtualization in these cases is to maximize manageability and to ensure maximum ROI from implementing these new client models. We have some articles in the pipeline that talk more about why to consider completely rethinking what your client devices might look like in the future. This article, however, is written with the traditional fat client in mind.

Here are some of the reasons to plan on using SVS across the board on new deployments:

  • maintain stability, performance and security of base images (extends life of the images, reduces help desk costs and improves end user satisfaction) (as I say in my presentations, "keep it lean, mean, clean and pristine -- just the way IT wants it!")
  • allow machines to be rapidly updated or even completely re-purposed
  • puts the technology in place to make your next migration extremely rapid

So how you plan your SVS transition strategy is primarily driven by three factors:

  • what problems you are trying to solve by virtualizing applications
  • whether or not you already have a hardware refresh and/or OS migration project in progress/planned
  • your comfort level with the technology

What software can/should go in VSPs?

First, understand what is officially supported in a VSP, and what best practice dictates installing conventionally, in the base. This has been covered in several Juice postings, such as this, and in my SVS Best Practices session from ManageFusion.

SVS 2.x is optimized for desktop productivity applications and much more. Basically, with SVS you should be able to virtualize any software unless we explicitly call it out as unsupported or not recommended.

The following categories of software are not supported in an SVS layer:

  • Windows operating system components - Yes, this includes Internet Explorer.
  • drivers - Some work, some don't, but we can't guarantee the result. Hardware device drivers are less likely to work than software drivers. If you have an app with a driver that you want virtualized, our suggestion is to try it in a lab. If you have success and require an official support statement from Symantec, contact your account team or the SVS product team directly at
  • server-based applications - SVS is not supported on servers (in fact the EULA explicitly dis-allows use on servers, except of course terminal servers when you buy the "SVS for Terminal Servers" SKU). So this has more to do with the use case than the actual application. Apps that might normally be thought of as "server apps," but that get implemented locally on clients, usually work fine and are generally supported.

There are a few other specific scenarios that are known to be problematic and are currently unsupported:

  • If you want to run multiple versions of the same application, all of them should be virtualized. Especially with MS Office (but with other products also), we have found unpredictable behavior when one version is in the base and another version is in a layer.
  • Recent releases of Java from Sun programatically prevent older versions of Java from loading into memory, even when one or both are virtualized with SVS.

N.B. In addition to these unsupported things, best practice dictates that all management agents should be in the base, not virtualized, in production use. This includes anti-virus software and security scanners of all kinds, plus any of the Altiris agents, or delivery, inventory, recovery, encryption agents, etc. from any vendor. This guidance is not a question of whether the software will work in a layer, as in most cases it will (tho you may get odd results with your system). It's a question of best practice for production. Virtualizing a management product may be useful for evaluation or testing, but in production, management agents need a "real," non-virtual view of the system. They need to see everything and "really" make changes to the system.

Another aside: Sometimes I am asked why Altiris products aren't delivered in the VSP format. A couple pieces are, like SVS User Admin, and you may see some more in the Altiris 7 era. But generally, we are a management company, so almost everything we ship is, by it's nature, intended to be part of the base operating environment.

Hybrid Approach

Symantec's vision for SVS is "virtualize everything that's supported," but as the white paper says, retrofitting existing Windows clients with an all- or mostly-VSP software library can be a lot of work. If you are rolling out new images already for some other reason (new hardware/OS migration), that is the perfect time to make the conversion to app virtualization (and/or streaming) and reap the benefits across the board. We have several customers like BJC, for example, who roll all new PC's with all supported apps virtualized. So they will have a hybrid environment for a while, where older machines have just problematic apps virtualized but newer machines have everything virtualized. The Altiris Business Unit has taken a similar approach -- legacy machines only have Office virtualized; new PCs have almost everything virtualized (this methodology will soon be expanded to all of Symantec).

OS Migration

Then there's customers like "Large US Bank" and "Large Hardware Manufacturer," which both plan to roll their Vista images with all supported apps virtualized. "Large US Bank" has actually done the repackaging and testing and has their app library queued up, ready to roll as soon as Vista itself passes their acceptance. They say that 98% of their apps will be deployed on Vista as VSPs.

Repackaging Time Impacts Your Approach

There's also the time to repackage into the VSP format to take into account. Those of you who have tried other app virtualization products tell us that we have clearly provided the simplest repackaging experience with SVS. Still, there is some effort involved. The bigger your software library, the more of a factor this will be on how you transition your complete environment to SVS.

I spoke with a customer at ManageFusion Orlando who said they have repackaged 100 apps so far as certified VSP's. They have a goal of completing 300/month until they are done with their 2,500-title library. So it will take eight more months, best case. (They didn't say, but I assume that all newly acquired apps are packaged as VSP's only.) Generally their approach is this: As an app becomes available as a certified VSP, all new provisions for that app (for whatever reason -- new employee, new job need, new PC) are fulfilled with the VSP.

So they are proceeding forward with the transition to SVS as a priority of its own, independent of any hardware refresh or OS migration projects. With certain problematic apps, they are replacing existing conventional installations with the VSP either immediately (pro-actively), or whenever a user opens a help desk ticket on that app. They feel that the normal course of operations with make the conversion complete w/i three years.

When I'm not re-imaging, what about the old install of the apps?

One of the benefits of SVS is that when it comes time to remove an application, you can do it "quickly, cleanly, 100%." But to replace conventionally installed apps with virtualized apps, you have to deal with the problems of legacy application uninstall.

A quick down-and-dirty way to avoid the headache (or at least to delay it) is to simply rename the app's main executable in the pre-existing, base installation. Once the new implementation of the app is made available in a virtual layer, the system will see and use the main executable that's in the layer and virtualization will work as expected from there.

Some customers (including our own IT guys, at least for the initial pilot group that converted from conventional Office 2003 to virtualized Office 2003) do this as a transition step, so that there's a rollback opportunity if things don't work out (rollback = delete the layer and restore the original file name of the main executable in the base). Altiris IT eventually decided this is an unnecessary extra step in the migration process and stopped doing this after the first fifty or so machines. But it's an option if it makes you feel more comfortable.

If you are going to take this approach, however, we do not recommend leaving the system this way permanently! When all of an app's files are duplicated in both a layer and in the base, it can be confusing for support techs (both yours and ours) who are trying to troubleshoot. Best practice is to remove the old installation of the app, no matter how clunky the vendor-provided uninstall routine is, and take comfort in the fact that you will never have to do that again!

When whacking legacy installations, the main issue for most customers is carrying forward user settings. No problem. Altiris' venerable PC Transplant product has been migrating user settings between machines for years. When migrating to SVS, the same principle applies. Use PCT to extract the user settings from the conventionally-installed apps before they are removed. Then use it in conjunction with the SVS command line (svscmd.exe) to inject the user settings into the virtual application layers. To put the user settings for an app into the writable sublayer (which makes them go away with a reset), use this syntax:

svscmd (layer name) exec -p (path to personality package.exe)

Best practice is usually to migrate user settings to the writable sublayers, as that approach maintains true "known good" baselines of the apps that can be reverted to with Reset (and if you retain the personality packages, they can always be restored after a reset if desired). Injecting user settings from an old installation of the app into the read-only sublayer (which makes them part of the virtualized app's baseline and persistent across resets) breaks standardization of your VSP's and may carry over problems from the old install. But if you have use cases where that's really what you want to do, just use SVS Admin's Update Existing Layer option to re-enter capture mode and run the personality package .exe.


This article is not intended to be a well-organized guide, but more a collection of tips that address common questions I receive about how to make the move to SVS. An updated, more detailed white paper is definitely still in order. In the mean time, we hope you find this information valuable. Excelsior!

Comments 6 CommentsJump to latest comment

Jordan's picture

SVScmd should let you update an existing layer just by passing in an existing GUID into it with the capture command, so SVScmd myGUID C –P ”My path to update EXE/Patch”.

If a forum post solves your problem please flag is as the solution

Login to vote
FrankB's picture

Nice to compare your experience against ours :)
Valuable tips here, thank you Scott!

Frank Bastiaens
Senior Technical Consultant

Login to vote
riva11's picture

Great article Scott, an interesting document where find many tips and comments helpful for anyone interested in transitioning with this virtualization approach.

Login to vote
rpfenninger's picture

Scott, thank you for this great article and the handy tips.
For us it's just the right time as we're in the middle of considering the transition to SVS.

Login to vote
Richard Jeffrey's picture

I's great to find all this information and experience in one place. I just have a few questions I hoped you may answer, with an edit! What is the advise for using Software Manager (SWM) or not for VSA's? Are people importing VSA into SWM or not bothering to? Are people patching VSA's directly under the C:\FLSRDR folder?

Login to vote
Scott Jones's picture

I assume you mean Software Manager in the Wise Package Studio sense? Absolutely use it; it's the key to identifying and minimizing duplicate objects across your Virtual Software Packages, identifying dependencies when creating Vista-compatible VSPs for legacy apps, and leveraging Wise Risk Assessment to be aware of duplicate objects that may need to be updated when applying an OS patch. Btw, I took that verbatim from by Best Practices deck from ManageFusion. ;)

As for patching virtualized apps, if I understand your question correctly -- no, you would not want a patch process writing directly to the redirection area. Esp. give that best practice is to obscure the redirection area so nothing can see it except SVS's filter driver (see this). No, generally "just patch" and let SVS handle putting things in the right place. If you do want to edit the layer locally during a custom patching process (an in-house developed app, for instance), use the layer editing API in the SVS SDK to ensure that everything gets handled correctly. A good overview of patching SVS Virtual Software Packages is located here.

Scott Jones
Product Manager
Altiris, Inc.
Now Part of Symantec

Scott Jones
Business Critical Engineer, Endpoint Virtualization
Symantec Corporation

Login to vote