Video Screencast Help
Endpoint Virtualization Community Blog
Showing posts tagged with Configuring
Showing posts in English
riva11 | 05 Nov 2007 | 0 comments

Spesso ricevo e-mails da lettori di Juice che mi chiedono come preparare un package per una specifica applicazione o gruppo di applicazioni. In ogni richiesta , semrbra che la maggior parte delle persone conosca solo due dei metodi per la creazione di package in SVS: la cattura di un Singolo Programma (Single Program Capture) e la Cattura Globale (Global Capture).

Vi sono altre (e qualche volta migliori) opzioni. Seguono alcune informazioni e consigli.
Considerazione Generale

Per molte applicazioni la cattura di un singolo programma non è la strada migliore da seguire, per questo motivo chi crea i package sceglie il piano B, esegue una Cattura Globale, e spende molto tempo per la pulizia del package e per mantenere l'applicazione operativa e funzionale.
La strada meno battuta

Anche se è stato menzionato almeno un paio di volte in Juice, coloro che creano package di applicazioni dimenticano il terzo (e molto efficace) metodo per creare...

Admin | 05 Oct 2007 | 1 comment

Hudson & Company is a Calgary-based accounting firm with many of the same technology issues the rest of us face.

With 40 or so laptop-toting accountants, updating applications becomes an exercise in advanced scheduling. To complicate matters, the tax software they use is a bit "unique", which means sometimes multiple versions must be supported on the same machine. And, oh yeah, the IT department is a staff of one.

Read how the Hudson IT "staff" discovered SVS and put it to use to overcome their software management challenges.

Get the full story here.

Scott Jones | 28 Sep 2007 | 4 comments

Rob asked, "Should I include the application's source MSI in the Virtual Software Package?"

We usually recommend it, Rob. Placing the source MSI for an application inside the application's Virtual Software Package is necessary for SVS to properly handle various Windows Installer features such as self-healing, install-on-demand, patch installation and upgrades. When the Windows Installer service performs one of these functions, it will access the MSI source. If the MSI source is in the VSP with the app, that is SVS's heads-up that the resultant actions must be kept within the appropriate virtual layer.

For self-healing, it's recommended just in the interest of the best user experience (so they don't see an error box saying the source can't be found). Since of course a reset would undo both the self-healing and the problem that caused it to kick in, ultimately it doesn't really matter. Customers...

Admin | 21 Sep 2007 | 4 comments

"The AT command is also an important tip for techs working with SVS layers!

Since SVS layers carry the ACLs from the machine where the layer was created, sometimes you may find yourself with stuff in a layer that you can't edit or delete locally on the client you're sitting at... "

SVS Product Manager Scott Jones just posted this cool tip as a comment in the Application Packaging group. We thought it worthy to post a link to it here, as we know that SVS Master Gurus do find the AT command invaluable!

Read the full comment.

tfronza | 04 Sep 2007 | 0 comments

Just another quick tip! We have several users in our environment who have the full boat of Adobe products. We put most of them in a layer and each was built by itself (individually) in a VM.

This was not working well, so we found that if you own Multiple Adobe products like us (Pagemaker, Photoshop, In-Design, etc) it helps to have your other Adobe products already on the PC that you are using to building the new product on.

So, for example, if you are building a layer for In-Design it helps to have Acrobat Pro and Photoshop already on your build machine so the adequate plug-ins are placed in your layer for the appropriate products.

I know it sounds complicated but it is easy to do and will keep you from getting a massive head-ache!

Good Luck
Tom Fronza
State of Ohio
Dept. of Taxation

Scott Jones | 08 Aug 2007 | 9 comments

Since the beginning of SVS, customers have talked about how useful it could be if admins had a way to update an application's read-only sublayer with the data in the writable sublayer.

This would essentially "snapshot" the app at its current state on a given client, making the Reset command even more useful than it already is. Then, when a user has a problem with an application, the help desk could reset it to the "snapshot" point. If that didn't resolve the issue, they would still have the option of deleting the layer and re-importing it from the original archive.

Such functionality could also be used by the repackaging team to easily create a new version of a Virtual Software Package for the master software library.

We took to calling this function "Layer Press". That is, "press" the content of the writable sublayer "down"...

riva11 | 25 Jul 2007 | 9 comments

Here's a list of interesting articles that were recently published on Italian websites. These articles focus on Altiris' Software Virtualization Solution (SVS) and considerations that should be made when using products like Wise Package Studio and SVS together.

Here's the Italian translation:

Voglio segnalarvi alcuni interessanti articoli pubblicati in alcuni siti che riguardano SVS e in genere le soluzioni di virtualizzazione e di gestione con le soluzioni rilasciate da Altiris.

Altiris SVS 2.0: evitare incompatibilità e problemi software con la virtualizzazione :
[quote]I benefici della virtualizzazione: la ricetta di Altiris. | Gestione dei layer con SVS 2.0

La virtualizzazione dei componenti hardware viene oggi utilizzata da...

fbuonvino | 16 Jul 2007 | 5 comments

I'll never forget a needlepoint carefully hung on the wall of a friend. It read, "Our Home: Clean enough to be healthy but dirty enough to be happy."

Juice contributor fbuonvino points out that the same philosophy should hold true when using registry cleaning tools to tidy up a machine that's housing virtualized applications.

Special care should be taken during registry cleaning on a machine using SVS. A program like Registry Booster or similar, normally used to clean a registry of errors, wrong paths, and open links could possibly mistake registry entries belonging to virtual applications as problems to be dealt with -- if the application is not currently activated.

You could easily verify the problem by making two scans, one with your virtual applications activated and another with those same applications not activated.

tfronza | 06 Jul 2007 | 4 comments

How often do you rebuild your "Packages" or Layers? I ask myself that question and I really do not have an answer. But from personal experience I have found that I end up rebuilding packages on a 6 month to 1 year cycle UNLESS the software manufacturer ends up rolling in a patch that is required in the enterprise.

I have found that after about 1 year, packages or layers seem to have a "Born On Dating" and the become "Stale". It also helps to build the packages on a machine that has the current patches for compatibility with you current environment -- NOT one with patches from 6 months to 1 year ago.

Good Luck
Tom Fronza
State of Ohio
Dept. of Taxation

Heath Doerr | 25 Jun 2007 | 4 comments

Here's the scenario: Customer creates a VSA for App X -- it doesn't work. You create a VSA for the same application -- it works great.

Wouldn't it be nice if you could quickly compare the two VSAs to find out what the customer did differently that kept the application working?

Here's how I did it:

I've done this with two tools, the Wise Windows Installer Editor and a 3rd party tool called FileSync. (

Examining the Files

Import both of your VSAs, and find the Read Only directory name associated with each. (e.g. Customer Layer is "C:\fslrdr\1" and your layer is "C:\fslrdr\3")

Use the FileSync utility to identify differences by...