VMware Horizon Community
Rsasjol
Contributor
Contributor
Jump to solution

Multiple AppVolumes with same dependencies

Hi,

I need to produce an App Volume for a very old healthcare application. And one of its prerequisites is a fully functionnal Adobe Reader.
This application makes a complete lookup for the reader, and asks/modifies some entries in the registry related to it.
Without them, or the plain ability to access them, it hangs.
You've understood well : In order to be able to create a partly functional App Volume, I had to set up Adobe Reader in my VM used to create them. It's dirty, but thanks to the magic of snapshots, no damage so far.

I acknowledge that I can totally add Adobe Reader in the App Volume. But as the healthcare industry is famous (or infamous ^^) for this kind of program, It is highly possible that, at some point, I should need to do it again for another one.

And it leads to the good question : How would the system react if we mount both of these app volumes containing both Adobe Reader ?
As one application should make its settings and the other one should add/overwrite them, my opinion is that it may end in a big mess.

On your opinion, how should we manage this particular issue ? 

  • We can isolate Adobe in one dedicated AppVolume. But how can we mount it during the process of creating another one ?
  • We can integrate Adobe in this Appvolume program, but what happens when more than one of them, bundled with Adobe Reader, is attached to the end-user session ?
  • We can integrate Adobe in the production's golden image. But again how can I issue a AppVolume if my program absolutely needs the reader during its setup, and my system used to create them does not have Adobe's software ?

Thanks your for experience already 😉

0 Kudos
1 Solution

Accepted Solutions
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

Also healthcare but RDSH here...  my experience is exclusively appvol  2.18.x so if this changed in the 4.x and newer versions i wouldn't know...

I'd put Adobe the base, it needs monthly updates at least the same time the OS does.   If multiple app stacks update the same file, registry, dir etc...  last attach wins.  AFAIK virtual apps cannot see each other and therefor the first attached app that also needs adobe would not work. 

If you know what is changed in adobe (presumably a plugin registration?)you can import those changes by other means.  To go this route you likely would have to mod your snapvol.cfg.  

If none of that is palpable you can separate the two apps and publish one or both  separately. 

App vol by definition is messy.  We use it alot, but only for the odd applications and where needed and avoid the penalty everywhere else.

View solution in original post

0 Kudos
1 Reply
BenTrojahn
Enthusiast
Enthusiast
Jump to solution

Also healthcare but RDSH here...  my experience is exclusively appvol  2.18.x so if this changed in the 4.x and newer versions i wouldn't know...

I'd put Adobe the base, it needs monthly updates at least the same time the OS does.   If multiple app stacks update the same file, registry, dir etc...  last attach wins.  AFAIK virtual apps cannot see each other and therefor the first attached app that also needs adobe would not work. 

If you know what is changed in adobe (presumably a plugin registration?)you can import those changes by other means.  To go this route you likely would have to mod your snapvol.cfg.  

If none of that is palpable you can separate the two apps and publish one or both  separately. 

App vol by definition is messy.  We use it alot, but only for the odd applications and where needed and avoid the penalty everywhere else.

0 Kudos