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!

By Tim Mangan

Tim is a Microsoft MVP, and a Citrix CTP Fellow. He is an expert in App-V and MSIX.


    1. Customer was using 4.6SP1 sequencer without any hotfixes. Didn’t go back and check the hotfix details, but don’t remember this being addressed in them.

    2. No, I don’t think that the WORKINGDIR renaming (or lack of..) has been fixed in any of the hotfixes. And to my knowledge that issue has always existed in the Sequencer.

      But if you used 4.6SP1 without any hotfixes, didn’t you encounter another issue that apparently was finally fixed in HF3, I think, which relates to fact that Save As loses all VFS mappings? When you look at the resulting package in Sequencer, it shows mappings seemingly in place at the Virtual Filesystem -tab, but looking at the package using AVE shows that none of the directories or files under VFS subdirectory actually has any virtual mappings at all. Running the package on the client verifies this as you are not able to see any VFS’d directories or files inside the bubble (via cmd.exe or similiar).

      I was bitten by this in 4.6 RTM Sequencer half a year ago, and verified that SP1 version had the same bug as well.

  1. I thought the string that had to be unique was in fact the application name with the version appended? e.g. on the client you launch SFTTRAY /LAUNCH “MYAPP 1.0.0”. I can have another sequence with an app named MYAPP, but it must be a different version.

    1. I simplified it a bit there:
      1) app name + version needs to be unique at the client to import to the client.
      2) app name needs to be unique to import to the management server.
      3) app name should be unique at the client because it is also used as the shortcut link name if you want to deploy in parallel.

      So yes, you could have the same app name with different version strings at the client if you don’t use the management server AND you put the shortcuts in different folders. I like to deploy in ways that can be re-used should you decide to deploy using a different method later on. So complete uniquness at the app name is best.

Comments are closed.