How fast are the updates to App-V package with AVE? Fast!

It so happened a while ago that I was on consulting day for a customer and we needed to make smallish update to an existing App-V package I originally did with Sequencer (because AVE does not currently have a monitoring functionality nor package creation from scratch). This update was only about adding a bunch of files to the sequence (some additional data/definition files for the application within) and as I did not had AVE installed on their packaging machine, I went with the usual Sequencer route. I soon discovered that I shouldn’t have done that…

The package contained about five to six different applications, part of the same suite. When I originally sequenced it, I had to do a lot of cleanup for shortcuts because the actual application installer was – quite frankly – rather assbackwards in its placement of those shortcuts. What should have been a one program group in a Start Menu with 20-something shortcuts, ended up being at least three different groups with some of the shortcuts in each one. And one of the groups was hilariously named with something like: C__Users__Administrator… and so forth, revealing that somebody escaped path to a programs folder in a wrong place.

Anyhow, much cleaning ensued after which all the shortcuts were placed correctly in their groups. And all was fine, until now when I needed to crack open the package and add few files to it. Package did not have any FB1 optimizations in place and I did not have an intention of launching any of the programs during sequencing (so that they don’t litter user profile with all sorts of folders and files which then would be captured too [unless explicitly excluded]) or now when updating. So you would think that the changes to the VE would be minimal and this would be quick job, right?

Turns out, it wasn’t a quick job after all.

After I had done the usual dance of copying the package to a virtual machine where my pristine Sequencer environment was, I opened the package for editing (4.6 RTM version) and proceeded to copy those few new files into one of the VFS’ed subdirectories in the package. Stop monitoring and forward I go… except that Configure Applications -screen looked little bit busy; however I did not pay too much attention to it since I had not installed any additional programs or anything, so I assumed everything was good.

(A side story about the same package: after the wizard had been run, I noticed in the Deployment tab that uncompressed size of the package was about 1.5 GB, which was bit strange because my SFT was only about 66 MB in size. On a closer inspection, I discovered that all five to six applications stored in the package had on-disk size of between 200 and 300 MB each! But as my package was compressed, they shrank in incredibly manner resulting 1.5 GB of total data being squeezed into less that 100 MB… a quick look with hex-editor showed each of the executables storing a large number of repeating characters, which – I assume – had to be some kind of embedded resources that application uses, which then explained that unbelievable compression factor)

When I moved the package to SCCM and began to update the existing (App-V) package publishing over there, I clearly could see from the preview screen showing applications in the currently published version and the version I was adding as an update that there was exact duplicate of each and every shortcut the original package had. After much cursing I came into explanation that Sequencer had picked up / refreshed the shortcut information incorrectly and decided to add all shortcuts again as new applications, although they already existed in the package. And of course these duplicate shortcuts didn’t have any icons associated with them.. (I have been bitten by shortcut behaviour in App-V Sequencer before too, SAP package I’m regularly updating always resurrects one uninstall shortcut in it that I each and every time remove manually in the Configure Applications -screen)

Back to the earlier snapshot in Sequencer VM (you see why multiple snapshots for VM are good thing) and updating the package again, but this time making sure that on application -screen I carefully remove each duplicate. It’s rather easy to see which are the duplicates, because they have generated OSD name with ends with “(1).osd”. After saving the package, I decide to give it a spin in a standalone App-V Client machine so that I don’t have any other nasty surprises when publishing it to those few users through SCCM.

Can you guess what happened this time over? Right: some (most) of the shortcuts were missing from the machine when deployed! I can only guess (again) that this was due to my original suffling of shortcuts during monitoring mode, and subsequent “re-detection” of all the applications during upgrade that had assigned visible shortcuts to the duplicate entries while removing them from the original applications (OSDs).

Now I had already used more than 30 minutes for this “simple” upgrade, and decided that I should do what I thought of originally doing. That is, using AVE to inject those files into sequence and be done with it!

So, after quick AVE installation, I opened the copy of the (original) package with it, went to the Virtual Files & Folder -tab, and located my folder of choice I needed to add files to. “Import or replace files” -function from the context -menu:

With the opened dialog, browsing to a temporary directory where my files-to-add are and AVE places them into the selected virtual directory (and updates VFS mappings etc.).

Next Save -function from the File -menu, and my package was updated. Took maybe 2 minutes.

Have a good weeked!