Addition to package branching instructions with AVE when using App-V Management Server infrastructure

My earlier how-to article about doing App-V package branching operation using AVE was otherwise correct, but if you are intending to use your branched packages in App-V’s traditional Management Server infrastructure, there’s couple of additional details you must attend to in order to be able to import your branched packages in.

The branched package itself is valid and a completely new package from App-V Client’s standpoint, but App-V Management Server (and the Console) has some specific additional requirements in order to import it successfully; otherwise you will get the following type of error message (ouch!):

So what is the problem here then?

Step 1 – clear out the history

As you likely know, each and every App-V package since the SoftGrid 4.0 times stores version history information inside the SFT file. This version history on the one hand is a handy way for a packager to see exactly what the packaging environment was during the previous version save (thinking being that you would then use that same environment during upgrade as to not introduce any unwanted changes to VE because of the change in the overall environment), but also a technical way for App-V Management Server to enforce strict lineage of multiple SFT files per package.

The possibility to have multiple active SFT files per one package on the backend was introduced also in the 4.0 version, so there needed to be a mechanism for ensuring that administrator does not accidently add new SFT version for a package which is not really an upgrade of the one(s) that were already there; doing so would break the Active Upgrade mechanism at the client level for that package. And the save history information could handily be used for this purpose too, since each history entry has a package version GUID associated with it which allows tracking of all the previous version GUIDs in the save lineage.

Now, when you do save as new package –operation in Sequencer, it will clear out the save history for a resulting SFT file. This, turns out, is an important factor for Management Server –based publishing, because apparently it stores version GUID(s) found in the package history to the database in a manner where two packages with overlapping history entries will cause some unique key in table package_version_lineage to conflict. In AVE, since we do not have explicit branching save –functionality but you instead have to enable regeneration of GUIDs as discussed in the original branching article, nothing automatically clears out the history (as you obviously would not want to do that during normal save). This then will cause the issue and error message described above when trying to import branched package to the App-V Management Server [database], since branched package by default has the same history entries inside it although otherwise it is a completely new package.

To resolve this, you will also have to enable “Remove version history information” option in the Save as –dialog (in addition to regenerating GUIDs, which make the package itself unique from technical perspective), as this will cause AVE to clear out all the history entries in the package, making the Management Server import happy:

Step 2 – modify content location

Another step that you should take – if looking to import branched package to the Management Server – is to change the streaming URI, since that piece of information is actually used by the Management Console (the backend one, not one on a client) when importing new applications to the system.

It is a kind of old knowledge, but I think seldom understood at least by the those new to App-V that when you import your App-V packages to the console, relative path to the SFT file itself is not magically interpreted by the console from the location you chose the SPRJ file (or OSD file) from, but rather what it says in the first OSD that gets read in.

What I mean by this is that if you have a CODEBASE HREF line like this in your OSD:

… HREF=”rtsp://appv45:554/winscp.v3/WinSCP_11.sft” …

Management Console importation simply takes the path information from the whole URI and sets the relative path to the SFT file linked for imported virtual applications to it (you can even see the forward slash instead of actual Windows file system path separator of backslash):

To avoid having problems during import, you will need to modify the Load content from –information in Package Configuration –screen in AVE before saving the branched package. Otherwise package importation will (likely) try to find the SFT file from subdirectory of the original package in your content directory, which obviously is not the place your newly branched SFT file is sitting in:

The name of the subdirectory has to reflect the name of the subdirectory you physically have inside your content directory, of course, so use whatever name you actually are using. The name of the SFT file itself in the streaming URI does not matter though; AVE will change that for you during the save.

—

With these two addition steps, you AVE branched package should be good to go in the Management Server infrastructure scenarios as well!