Still on the path of researching application compatibility issues for App-V and associated virtualization technologies.
As part of the side-tracking, interesting bits of reading that I have picked on my way past IE6 and .NET installation issues, I have found that Microsoft's Dynamic Suite Composition (DSC) can cause a few issues as well.
The DSC issues in question are very well documented in the TechNet blog on DSC circular dependencies (see references below) and so, I will attempt to distil the three primary issues with DSC and application dependencies.
First, a brief introduction to App-V DSC and how to use it can be found here:
Briefly, Dynamic Suite Composition is described as;
"Dynamic Suite Composition (DSC) provides a method for administrators to control which virtual applications will be combined to create a unified, virtual working environment for a single application set. To do this, DSC provides a way for the admin to specify mandatory or optional dependencies between separate virtual applications that allows each app to run within the same virtual space, or "bubble" as we call it. When this is used, when the primary virtual application is run on the client it will also launch the dependent virtual application within the same bubble, allowing the combination to run together in the same virtual environment."
The idea of Dynamic Suite Composition is great, as it allows applications to "talk" to each other across their respective virtualization/isolation bubbles. This solves a number of inter-dependency issues with applications like Microsoft Office and Adobe Reader.
Reading from the TechNet blog, the following scenario is illustrated;
"When package A depends on package B, a virtual environment (VE) is created at runtime that contains all the virtual resources from A and B’s packages, and changes to the VE are associated with A’s package when they are saved. When B depends on A, a second VE is created that also contains all the resources from A and B’s packages, but changes to the VE are associated with B’s package.
Now the problems.
- With the above scenario you have two Virtual Environments. Which means twice the disk space and associated deployment and management over-heads.
- "Bubble" load ordering is important as dependencies need to be loaded in the correct order.
- Each will isolated bubble will save it's state individually. Meaning, that you may have shared application access, but user settings and application settings may differ on how you load, and the order you load your application virtualization bubbles.
Maybe its easier just to install the application locally?? If you have to worry about inter-dependencies, load ordering, undetermined application and user settings states, then are we any better of with App-V?
Thankfully, there is a solution to some of these issues with the Microsoft App-V LOCAL_INTERACTION_ALLOWED Tag.
Referencing from another TechNet blog;
"When local interaction is enabled via an OSD policy, named objects and COM objects are created in the global namespace rather than isolated inside a particular virtual environment. "
This allows the application to fully interact with the local Operating System and allows other App-V virtualization bubbles to fully interact with that bubble. This neatly solves the some of the conundrum's with isolation, integration and dependency management with App-V.
But be warned, Chris Lord finishes his great blog entry with the following caveat.
"enabling LOCAL_INTERACTION_ALLOWED can introduce application conflicts it is best that you only implement this if absolutely necessary "
So many issues with App-V , ... so many solutions with App-V, so many issues, so many solutions... And the cycle continues...
References:
How to dynamically suite two packages using App-V 4.5 and DSC
Circular dependencies with Dynamic Suite Composition and App-V 4.5
A Look Under the Covers - The LOCAL_INTERACTION_ALLOWED Tag
No comments:
Post a Comment