Howto: App-V package branching in AVE

Having been inspired by a recent blog posting by Tim Mangan about currently known issues in package branching (and my own previous experiences of the same), both in 4.6 and 4.6 SP1 versions of the App-V Sequencer, I thought about to write a quick and short howto for doing branching operating with our Application Virtualization Explorer (AVE).

But before we go into doing things in AVE, let’s have a brief look at what the issues discussed around package branching problems in 4.6 RTM and 4.6 SP1 Sequencers are about…

Background on the Sequencer -based branch operation issues

(If you are not interested on examples of branching issues in Sequencer but are looking for instructions for package branching with current version of AVE, just skip to the next section.)

As Tim outlines in his post, there is a known defect in the Sequencer that makes branched packages to retain some remnants of the original package’s namings, which then causes branched packages to fail to launch on the client or have co-existence issues with the original package. There was also a bug that causes branched package to lose all VFS mappings during the process and there was a bug that caused virtual registry to be incorrectly updated during branching (which were both fixed in 4.6 SP1 HF3, but to my knowledge 4.6 RTM still doesn’t have matching hotfix).

Specifically regarding the VFS issue: interestingly enough Sequencer will still show mappings in place when looking at the resulting package but looking at the same package with AVE shows that they are not actually there! As you can see from looking at branched, say, in Adobe Reader 9 package (on 32-bit system); first how the Sequencer sees the VFS mappings after the fact (apologies for the “visual quality”, these were taken from XP machine):

Seemingly everything in place…let’s look at the same package with AVE:

Now we can see that the folders, while being physically present in the package’s internal directory structure, actually do not have any mappings applied to them! I don’t know why and from where Sequencer digs out that information but it’s clearly not a valid information since per spec there isn’t any mappings. So you shouldn’t necessarily trust your eyes, unless using AVE of course! And the lack of VFS mappings can be verified from the client as well, starting command prompt to the virtual environment and trying to go into any of the virtualized directories do not show anything that the package’s VFS supposedly has.

As a comparison, here’s how it should look like (taken from original package):

To see the effect of that virtual registry updating bug, looking again the branched package but this time virtual registry we can see that Sequencer has not updated the paths to the package root directory in proper manner:

Since this was supposedly fixed in hotfix package 3 for 4.6 SP1, let’s have a look what are the results for the above doing branch operating with the fully patched, latest Sequencer version available (4.6 SP1 HF3):

Well, isn’t this interesting: new Sequencer actually did not honor our rename of the package name (Adobe Reader 9 (x86) Foo HF3) which can/must be set in the Save As dialog! Even 4.6 RTM could do this! We can see that it indeed is the branched package – and not source package – by examining the root directory name, which was correctly set to adoread9.v3.

Oh well, let’s look at the VFS mappings again, first with Sequencer:

Yes, Sequencer again shows everything being alright. Should we trust it…?

Yes, indeed we can trust it this time, VFS mappings are now correctly in place! And what about the virtual registry:

That’s fixed too, very good to see.

So it looks like at least in 4.6 SP1 the latest hotfix will solve both VFS and VREG issues in package branching, but per Tim’s post there’s still issue with WORKINGDIR renaming and renaming of Package Name (if you try to do it during Save As, instead of from Deployment tab like Tim did).

Package branching with AVE

While we have not created a specific menu option in AVE to do all the things that package branching requires (maybe that’s something for 2.3 version..?), you can do mostly all of the things that package branching requires from few separate places as a manual process. You’ll notice that few things are still missing (like files renaming), but those will be addressed later on. Following branching instructions in this post requires AVE version 2.2.8 (available now!) or newer.

Let’s take a another package as example, Skype (guess that’s Microsoft’s software now..). We start by loading Skype package into AVE and do the following steps to make it new, unique, package which is what you would look to do with branching:

1. Let’s rename the package name from the Package Configuration tab. Load content from you need to update manually, if you (likely) change the subdirectory for the package in App-V Management Server’s Content -directory.

2. Go into Files & Folders -tab, and select root directory. Press F2 or open context menu and select Rename. AVE will warn you about that root directory renaming is breaking change, acknowledge it with Yes and change the directory name:

If we have a new-style long root directory name for our package that we rename, remember to change the 8+3 short filename as well!

If we go to Virtual Registry -tab and look around briefly, we can see that AVE already went ahead and modified references to package’s root directory:

3. Next thing to change is individual applications from the package. Go into Published applications -group in the Package Configuration -tab:

And select all applications, each in turn. Press Edit name -button on the top of the screen, under application’s name. Please ignore the Start in -field (aka WORKINGDIR) and Start program -field as those will be updated during save operation to reflect the new root and needs not to be touched now:

Change the name (and maybe version, depending on your need) of the application to make it unique.

4. If you have App-V package deployment MSI associated with your package, you probably want to rename the product name over there to reflect new name for our package:

5. As a last step, select Save package as -option from the File -menu.

Set output directory (to somewhere else wherein your original package was), expand advanced SFT generation options and enable GUIDs regeneration option:

Hit Save, and that should pretty much be it!