Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Virtualization Community Blog
Showing posts tagged with Workspace Virtualization
Showing posts in English
Admin | 22 Mar 2006 | 0 comments

"Altiris' segment manager Christine Ewing was just here and she told us that tomorrow, when the enterprise product ships, Altiris will make available a free, downloadable client version that you'll be able to get at sites such as and Tucows."

Read the Article.

Admin | 21 Mar 2006 | 0 comments

Richard Bentley, product segment manager at software services firm Altiris, said, "There is also the ability to fix an application very quickly so that if I have a problem, it is a case of flicking a switch so that it's back to its original state."

Read the Article.

Jared Payne | 20 Mar 2006 | 0 comments

SVS keeps track of process IDs and uses that information to determine where file and registry changes should be stored -- (in a layer or in the base). Jared Payne explains the rules SVS uses to make these decisions.

SVS keeps track of process IDs and uses that information to determine where file and registry changes should go. When a process starts, SVS looks to see where the exe file exists. If the exe file is coming from a layer, that layer is said to be the "owner layer" for the process. When that process makes a file or registry request, preference is given to the data in that layer.

Here are the rules SVS uses to determine if a process has an owner layer and which layer that is:

  1. If the exe file that is being used to create the process is in a layer, that layer is the "owner layer".
  2. If rule 1 does not apply and the parent process has an "owner layer", the new process has the same "owner layer".

This can be complicated some...

Admin | 20 Mar 2006 | 0 comments

Rhett asked, "What if I use Wordpad (which exists in the base) to create a .DOC file? Does SVS layer-ize files based on whether a layered program created them?"

Hi Rhett. If you create a file with an app that's running from the base, by default it gets written to the base. If the app running from the base modifies a file from an application layer, the new version goes to the base and the old version stays in the layer (this prevents an app in the base from potentially breaking a virtualized app -- we're assuming people are using data layers correctly and that this sort of a mod would be to a program or config file, which you don't want).

Best practice is to have everything in one or more data layer(s), so that it doesn't matter what app is doing the create/modify; data always stays isolated and out of the base (and not duplicated).

Jared Payne | 13 Mar 2006 | 0 comments

Jared Payne provides the step-by-step details on how to implement user-specific variables to protect data on multi-user machines.

In pre-release versions of SVS, only one set of user variables existed for an SVS-enabled computer. Now, each user gets their own set of user variables. User variables are associated with the currently logged on user and include things like DESKTOP, STARTMENU and USERPROFILE. Allowing each user to have their own set of user variables lets multiple non-concurrent users log onto a machine without being able to see the other user's virtualized user-specific data.

Adding user-specific variables changed the way SVSAdmin looks; there are some new areas when modifying layers. In the file system area in the layer editor, each sub layer now has 2 sections: System and User-specific.


Admin | 13 Mar 2006 | 0 comments

Richard asked, "What are the entry barriers to using Software Virtualization Solution in my environment?"

The main ones we hear about are concerns over supportability of commercial apps that are virtualized; and customers who require features we don't have yet in the initial release (support for terminal servers, for instance). On the other hand, Richard, the up-front learning curve is minimal and every customer we've spoken to has one or several pain points that SVS can help them alleviate (or eliminate) right now.

Admin | 13 Mar 2006 | 0 comments

Software virtualization -- I understand it helps with capacity, systems stability, and security -- but won't it add to a system's complexity?

How does SVS stack up to effectively model the simplicity criterion? Let me count the ways.

  1. The purpose of virtualization is to simplify the view into your systems by regrouping IT assets into more logical units, thereby simplifying management of those assets. So, no, it won't add to a system's complexity—simplification is the goal.
  2. Previously, all software deployed to a box got thrown into one big, chaotic bucket. Businesses expend massive dollars and man hours every day reactively dealing with the result of that chaos – failed installations and uninstallations, apps breaking each other, users and malware breaking apps too easily because the legacy model is too complex and fragile. SVS is proactive simplification – it...
Admin | 10 Mar 2006 | 0 comments

"Altiris is set to roll out its Software Virtualization Solution and Security Management Suite during 2006, along with enhancements to its Client Management product line. The upgrades figure to vault the Lindon, Utah-based company into a stronger competitive position against the likes of BMC Software and CA, Inc."

Read the Article.

Jeremy_Hurren | 10 Mar 2006 | 0 comments

For security reasons, layers don't store passwords. So, how do you create a layer that starts a service on activation that requires a password? Jeremy Hurren takes us under the hood for this workaround.

Because of the way that SVS virtualizes services, it does not store the password information necessary to log on as a service. So if you are installing software that has such a service into a layer, it will work the first time you run it, but after deactivating it and activating it again the service won't be able to start. The underlying technical reason is that SVS has to delete and create the service repsectively during the deactivation and activation. Because SVS doesn't want to expose any password information, it doesn't store that information in the layer, and therefore cannot use it to recreate the service during activation.

There are two different solutions that can work here. First would be to change the service you are installing to log on as one of the built-...

Wm Jesse Foster | 09 Mar 2006 | 0 comments

If you've been faced with the task of capturing several programs into a single layer, this tip, from support guru Jesse Foster, should get you going in the right direction.

There is at least one way way to capture multiple programs into a single layer using Single Program Capture. Here's the method I use.

  • In SVS Admin select File > Create New Layer
  • Select Install application. Click Next.
  • Give the Layer a name. Click Next
  • Select Single program capture. Under Program name, type (or browse to) the path for cmd.exe (C:\Windows\system32\cmd.exe on my computer). Click Next.
  • Click Finish.

Capture mode will start and a command window will open. Anything done from this command window will be captured in to the layer. So, start your installers from this window and the program will be captured in to the layer. Capture mode will end only when the command window and any child processes from your installers have exited...