AppVolumes 4.4 Can I use the same Package in different Applications?

[rcscott44]

We recently upgraded out environment from 2.18.6 to AppVol 4.4.  We are still running all of our Horizon (2103) desktop pools with AppVol 2.18 agents.  AppStacks and Writables are still all 2.18 vesion.

I am in the process of creating all new v.4 Applications.  We have some common programs that different department's use, but enough that are different so we need an individual Application with different Packages in each.  However, where there are common Packages, it looks to me like I still need to capture a Package of the program for each Application.

Am I missing something?  Is there really no way to assign the same Package to multiple Applications? 

-Bob

[Micheal_A]

You will want to create a new Application for each LOB for you packages.

Example:

Application Name: OpenSource NotePad++ HR

          Package Name: OpenSource_NotePadPlusPlusHR_7.8.8x64_B1

                                     OpenSource_NotePadPlusPlusHR_7.8.7x64_B1

                                      OpenSource_NotePadPlusPlusHR_7.8.6x64_B1

The question I have, is the application just changing XML/INI config files and/or the users profile data?

If so, you could create one package and leverage DEM or vbs to make the changes on login of the user.

[rcscott44]

I found the cause of my confusion.  I misunderstood the nature of the Package itself.  I thought that if you had an Application with multiple packages that EACH package that was listed as Current would be attached to the user (i.e multiple packages applied by one Application assignment)  I have since learned that only ONE package can be listed as current per application.  If I have multiple programs that need to be applied by one Application, they all need to be captured on the same Package.

Essentially the only change I see happening with 4.0 is you have separated the iterative updating of AppStacks from their assignment.  Basically I can have 4 versions of the same package never have to change user assignment to apply the newest version.

Each Application will still only ever apply 1 VMDK to a user at logon, making the sharing of Packages between Applications irrelevant.

-Bob

[Micheal_A]

Also, you can can assign a user directly to one of the versions that are not set to current. this way, the user will get the version directly assigned and not the current version assigned to the security group.

This way you don't have to take a user out of the current group and allow them to use a prevision version until the issue with the new version is resolved.

AppVolumes 4.x is setup for application life cycle management.