App-V Package Branching and Issues

I was working with an Application Service Provider client this week that was having issues with deploying QuickBooks Professional to their Citrix XenApp Servers using App-V. Quick Books is a bit of a pain to sequence, as you need to work around their licensing strategy which is tied to the CPU. We have had a recipe for years that works around this nicely, while honoring the integrety of Intuit’s licensing. We need to tweak that recipe a bit as versions change, but the basic idea is the same. This customer’s main issue wasn’t the licensing but the need to have two different versions of the same package.

They had issues with the App-V Management system due to conflicting names and needed someone to help them sort out what to do. I thought it might be good to share the technique that I used with the community, and also make folks aware of an App-V sequencer bug I uncovered in the process.

App-V has a variety of things that must be unique. The App-V Management system dictates some of these, due to the database design, and the App-V client dictates others. But to summarize:

• The Package Name must be unique for each package, both for Management Server import (due to the database design), and at the Client.
• The Package GUID must be unique for each package, both for Management Server import, and at the Client.
• The Package Root Directory, also known as the Asset Folder, must be unique for each package at the Client (The Management Server doesn’t care).
• The Application Name field must be unique for each application in all packages, both for the Management Server and the Client.
• The OSD FileName field must be unique for each application in all packages, for the Management Server. (The Client actually renames the OSD using the OSD GUID when the OSD is imported.)

To make life simple, we strive that all of these items be kept unique across the board, no matter how we are deploying the App-V packages. When we sequence new packages, good practices take care of the first three items, and the last two tend to be an issue only when we have shortcuts to executable files that are natively deployed, like notepad.exe or iexplore.exe

When we want to have the same application packaged twice (with different configurations or versions) and deployed in parallel, we must be careful to ensure these uniqueness’s. In our case, we wanted to open the existing package up for update, modify some things and perform a branch save to help with the uniqueness. This process was performed (using 4.6 SP1) as follows:

• Starting with a clean sequencer, copy the existing package to the desktop.
• Start the sequencer to update this package, selecting “Add A New Application”. Even though we are not actually adding a new application, this provides access to all steps in the wizard.
• We select custom install, and once in monitoring mode we make the customizations (rather than install anything).
• After Installation mode and Configuration mode are completed, we select the customize option so that we can edit the applications.
• Each Application must be edited. In each case we:
  • Edit the Application Name field to be unique. Not only does this solve the server and client uniqueness issue, it also changes the name of the shortcut when the virtual application is published. Thus the shortcuts will appear side-by-side in the user start-menu if a single user gets both packages published to them. Choosing a different name that is clear is important!
  • Edit the OSD Filename field to be unique.
• After the streaming page, we select to continue modifying the package. In the “package editor” (the un-named multi-tab interface), we do the following:
  • On the Properties Tab page, change the Package Name.
  • On the Deployment page, change the Path field to match the Package Name. The Path field is the name of the folder we will save the branched package to. Technically it need not change but it is best to do so.
  • We select “File->Save As” from the menu. In that dialog:
    • We create the folder we named in the Path Field previously, and change to that folder.
    • Being paranoid, we check that filename has changed to the new package filename. It will be if we changed the Package Name field on the Properties Tab page.
    • We check the “Save as New Package” checkbox. This gets us a unique Package Guid and new OSD guids in each of the OSD files.
    • We change the Package Root Directory field. Although I allow long names for the Package Root Directory for initial sequences, I like to keep branch package names to the 8.3 compliant format (only because I haven’t verified that Microsoft makes the “short name” version of this folder properly when branching).
    • Being really paranoid, we check that the Package Name field also changed. Again, it will be already changed.
• After all of this, the branch package should be good to go, but thanks to the bug we uncovered, maybe not! Manually check the OSD files (using notepad or a better editor) and look at the WORKINGDIR element in each. We are finding that if the working directory was set using the old Package Root Directory name, it will not have been changed when we changed it during branching. Edit and fix each of these.

I will point out that we could have achieved the same result by creating a new package using a new package name and root directory, installing and configuring QuickBooks, and making sure to modify the Application Name and OSD FileName for each of the applications. When the application installation is painless, this might be the way to go. Using the branch method tends to be easier for more complicated installations.

Happy Sequencing!