Skip to content

Virtualisointi EQU virtualization

Random ramblings from the world of virtualization and then maybe some other things as well

Archive

Category: App-V

What are the Package Accelerators?

Since the beginning of App-V times (or SoftGrid times, to be more precise), we all have had only one method of communicating to others how a specific application is to be virtualized and package is to be built: recipes.

These recipes or “prescriptive guidance” are simply a free-form documentation of how one is to sequence an App-V package using certain steps in various phases of Sequencer’s packaging wizard and post-wizard UI –based customizations. The main problem with recipes comes from their free-form nature and the fact that the person creating a recipe is responsible for remembering all the exact steps and recording them meticulously. Sometimes we forget things we had to do with more complex packages and even if we, the creators of recipes, remember to record everything of note, there’s still a possibility for consumers of our recipes to interpret things differently. Or maybe they have a slightly different version of the original application installer in hand, ending their sequencing effort in failure. And let’s face it, none of us really like to spend lot of time writing down things manually (well, not me anyways)!

To overcome the issue of interpretation-dependent recipes and to ensure App-V packages are consistently built, Microsoft has introduced a nifty new feature in App-V 4.6 SP1 called Package Accelerators. The idea in general is not novel as some of the other app virtualization technologies have similar features, but now with App-V we are also able to record the “essence” of a virtual application and extract out the files – which usually are problematic from an intellectual property and licensing perspective. We can then  “transform” a physical application into a virtual version without the normal Sequencer monitoring process. So Package Accelerators are all about automating the sequencing process instead of cranking out each package manually, using some pre-recorded information to accomplish this. Please note that this method of creating virtual applications is not suitable for all situations and all possible applications, but for applications not needing a lot of per-organisation/customer customization it is indeed a fast way to build a package.

In this post, I’ll give an overview of how you too can make Package Accelerators with the App-V 4.6 SP1 Sequencer; be it for storing that for internal organization’s use or,  what’s more beneficial for the whole App-V community,  for sharing your package with the whole world Be aware that due to nature of Package Accelerators you have to make sure that they do not inadvertently contain any proprietary information you do not wish to disseminate (like internal machine names, user accounts, serial numbers, passwords and so forth) or include any physical assets that you are not allowed to redistribute, such as software components for licensed software.

Preparing for the Package Accelerator creation

Before we create an actual Package Accelerator, we follow normal preparation steps or best practices for App-V sequencing. So make sure your sequencing machine is reverted to a clean state, all the installation media needed is copied locally to the sequencing machine, and there’s no extra processes running in the system. In 4.6 SP1, some of the enhancements Microsoft made to the sequencing process is to check certain technical issues for you, but nevertheless you know the best if there’s some 3rd party software installed that should not be there (like anti-virus or such).

There is one change from the previous guidelines though; as you may have noticed while installing 4.6 SP1 Sequencer, it asked for drive letter for the package drive. What that meant was you no longer need to have that second partition (“Q” drive) physically on the sequencing machine. The Sequencer will take care of creating a “virtual” Q –drive for you by using (very old) technology in Windows  which mounts one folder in the [system] drive as separate drive letter. That’s subst usage for 21st century!

In the example, I’m going to create Package Accelerator out of freely available 7-Zip file compressor (http://www.7-zip.org/) so you can follow along in your own machine.

Depending on the intended target machine architecture, download either the 32-bit install package or 64-bit install package from 7-Zip’s website. The version I’m going to use, and which is contained in the completed Package Accelerator linked to this article, is the 32-bit version of 7-Zip 9.20.

Creating a sequence

Since the Package Accelerator is based on an existing sequence, the first order of business is, of course, creating the sequence for the application we intend to base the Accelerator on. Since 4.6 SP1 has introduced significant UI changes to the actual sequencing (although the underlying process is pretty much the same), we are going to walk through the main points in this article as well:

The option to create a new package is now in the main interface, like with the 4.6 RTM version, but the interface has been streamlined still a bit from 4.6. Choose to create a new virtual application package to start the wizard.

App-V Sequencer wizard selection
In the new sequencing wizard, you now have an option to select between creating a package normally or from the existing Package Accelerator. Since we are going to create an Accelerator, we proceed with the normal route.

Selecting package creation method

Like briefly noted above, the  4.6 SP1 Sequencer will check for some known “problematic” technical aspects of the sequencing machine, one of which are the various default Windows services running on the machine. You can of course proceed without taking any actions on these issues, but doing so may cause unwanted data in the package or some of the services may interfere otherwise with the packaging process. It’s recommended to do as told in the Resolution column (in this case, stopping said services).

New warnings before going into monitoring

After stopping the services, you can press the Refresh button on the screen to allow the Sequencer to notice that you “fixed” the issues:

Pressing Next will start monitoring

Yet another new feature in the 4.6 SP1 Sequencer comes in the next screen, where you have to decide what kind of application you are currently sequencing. The selection here will somewhat affect the upcoming steps in the wizard, but it is good to remember that the actual process (monitoring changes in the system etc.) has not been changed. It is just that Sequencer will guide you more than before and tries to help more in some of the steps required to sequence certain type of applications.

In creating the current package in the example, we are going to proceed with the default selection of Standard Application, which is the type for majority of applications you are going to sequence overall.

Selecting application type

In the next phase, you have an option to select the path to the installer for your application. This is for scenarios where you have only one installer that does all entire job of getting an application installed and no further steps are needed. With 7-Zip, this is something we can use as running the installer is the only action required.

Installer selection

Now you have to set the name for the new package, something you did as first thing in previous versions of the Sequencer. Unlike the previous App-V versions, the chosen package name will also automatically be suggested as a root directory name for the package … I’m sure at that this point you will say “hold on, what about that 8+3 naming?!”

Well, that is now done for you automatically by the Sequencer through setting that 8+3 name to random name which is not reflective of what the long name (i.e. the package name) happens to be. If you truly want to, you can still override the default with the root name of your own choosing so that option is available too even though it is highly unlikely that random names would ever clash on the client.

Setting package name (and root)

If you chose the installer in the previous step instead of opting to go with custom installation, the Sequencer will start your installer in a short while after bringing up the virtual environment for monitoring. Note that there aren’t “Begin Monitoring” / “End monitoring” buttons anymore but monitoring is entered immediately from pressing the Next -button on the package naming screen.

After entering into monitoring mode, what’s very nice to see is that we once again have the possibility of minimizing the Sequencer out of way. This was probably the most annoying design choice when 4.6 originally came out (note that I’m settling for very little :-)) and I’m glad that Microsoft finally agreed on fixing it.

For the purpose of this example packaging – so that we may finally get to the interesting Package Accelerator bits – let’s perform a standard installation of 7-Zip as a VFS sequence.
When the installer has finished, let’s get back to the Sequencer again.

Pressing checkbox enables stopping the monitoring

You’ll notice that there is actually a possibility to run other application(s) still but for our purposes let’s finish the installations with “I am finished installing” button which effectively means “I’m going to stop monitoring”. I cannot say I like misusing the checkbox usage model (somebody needs to read Windows User Experience Interaction Guidelines -document) wherein a button would have been more appropriate like in the previous versions, but I guess it’s somewhat more clear for newcomers.. Pressing the Next button after checking the checkbox actually ends the monitoring.

In a deviation from the process of sequencing in previous versions of App-V, the new Sequencer presents the run programs, or launch applications, screen before you actually have chance to customize what applications you intend to publish from the package and the intended behavior is now to make those first-time tasks (or 10 most common actions as we were taught in the past) during this phase rather than during installation monitoring. So start up the main 7-Zip application (no need to start help file) to set some options we want to enable.

Forming FB1

From the Tools -> Options menu, make file-type association for all associations known to 7-Zip. In a  real situation, you probably would not want to associate all possible extensions as some of them are already handled by Windows Explorer (like for .ZIP) or some other more specialized programs (like for .ISO).

Selecting file-type associations for 7-Zip

After accepting the changes and closing the 7-Zip program, you can go forward in the Sequencer with Next –button and see a summary report of the installation. Note that in 7-Zip, the Sequencer has correctly identified Explorer shell extensions (not supported by App-V technically) that were installed but could not be included as virtualized. This new summary screen will be of good help in packaging applications that we may not know that much about in advance as it gives overview of things that might not work with virtualized version just like in traditionally installed one.

If you want to customize the package further, you could do so – and I would recommend doing so in the “real world” – but we will take what we have now and save the package in order to start creating a Package Accelerator from it.

Selection to finish with package or customize further

Even if you do not select customization, you can enter package comments and select whether or not to compress your package. Note that although it states that compressing is required for packages over 4GB, the resulting compressed package still cannot exceed 4GB size limit.

Creating the Package Accelerator out of sequence

Now that we have our sequencing for 7-Zip done, we can create the Package Accelerator from it. Functionality for doing so is started from the Sequencer’s Tools menu, which has gained few new options.

Invoking Package Accelerator creation from Tools menu

Selecting the “Create Package Accelerator” option starts a brand new wizard designed to guide you in making Package Accelerators. Very first thing in the wizard is to browse for our App-V package against which the Package Accelerator is created. In my example sequencing, I’ll select the SPRJ file from the location I used for saving the 7-Zip package.

Selecting existing App-V package as basis for Package Accelerator

In the next screen you have two choices for specifying the source files required for the package. These source files are basically a location from which the Package Accelerator’s users will get the files from on their sequencing machine, since Package Accelerator does not store (most) of the application files. Otherwise you would not have any difference between the package itself and the Accelerator!

The way a Package Accelerator technically works is that it copies the files from their original location back into generated SFT file according the mapping information in the Accelerator when it is executed under the Sequencer and all the other metadata information like virtual registry etc. are imported from the PA’s CAB file directly.

First option for finding the installation files is to point to the folder containing installer source files for application. This option requires that the source folder contains application files “in plain” in the directory structure. If application files are coming directly from inside a pre-existing installer (typically EXE having files embedded within), that cannot be used as-is since there is not a 1-1 mapping of files available for Sequencer to copy files from. And in our 7-Zip example, that is exactly the case since installer is just one EXE file which self-extracts files as part of an installation process.

A counter-example of installation sources that can be used is if the original setup program has all the files in the directory structure and the installation program merely copies them to correct locations, like with some CD/DVD based installation media. Or alternatively, if you know that the installer can first be extracted to the disk to reveal actual files then that would be suitable source for installation files after manual extraction process (see guidance file –phase later on).

Selecting source of files

If the installation sources are not available in suitable form, a second option is to point to the default installation directory of an already installed application. This means that you have a pre-existing installation of the application you have in the package in the sequencer machine. Since that is what we have in this 7-Zip example, having installed the package to the sequencer machine during monitoring, we are going to point the wizard to our installation directory. Please note that choosing this option requires that the installation of the application on the local machine needs to be in default location (and in real life you probably want to re-set the Sequencer back to clean state and perform physical installation of application before starting Package Acceleration creation process, just to be sure).

Special note about the situation wherein an App-V package is not a VFS sequence and it’s installed during monitoring to subdirectory under package’s root directory; in this case you have some rather complicated requirements how to specify the path for the Package Acceleration wizard in order for mappings be done correctly, making a VFS sequence to default installation directory is a much easier case for Package Accelerator creation.

After pressing the Next –button, the Sequencer will now figure out all the files in the App-V package and tries to find corresponding ones in the location you specified. If the installation files source for some reason does not contain all the required files, the Sequencer will give a list of missing files and you have the option of going back to  re-specify the source. If all goes well, like in our case, the Package Accelerator is created and is ready to be customized.

Package Accelerator is created

Next you will be able to customize the contents of the Package Accelerator – file-wise. The Package Accelerator will copy the main files from the installation file sources when the Accelerator is run, but some of the files will be stored inside Package Accelerator – so if you need to remove some of those files that would otherwise go along, you can uncheck the item and the file will not be included in the Package Accelerator. In this example, we will take everything in that is detected by default and besides, one of my rules for cleaning up the sequences has always been, “do not remove anything you are unsure of”.

Selecting/de-selecting files

Going into next screen, you can customize the application information that Sequencer will present to person executing your Package Accelerator. This list is simply metadata information about applications that the packager should first install to the machine before proceeding, so that Package Accelerator is able to find all the correct source files to be included in the SFT file.
The Sequencer will not check for existence of these applications, since Package Accelerator does not store any file paths or anything like that mapping to listed applications. The packager simply needs to acknowledge “I have installed these” to proceed. If you know that application needs some pre-requisite components and such, you should list them here so that the environment matches one you are basing this Accelerator on.

For now, accept the default application that the wizard detected.

Setting application information

The Wizard will now ask for location of a guidance file that gets included in the Accelerator and will be shown to packager executing it. If you need to include any manual instructions related to the application being packaged, or some other information to the users of your Package Accelerator, you can do it via contents put into this guidance file.

The guidance file is simply a text file in Rich Text Format (RTF) or plain text format, and things it could (as an example) include are instructions for preparation steps in sequencer machine (extracting source packages, installing some pre-requisites components like VC++ runtimes etc.), things to customize in the resulting package or basically any contextual information for what needs to or should be delivered to whomever is running the Package Accelerator.

In this example case, we can just create and browse for empty TXT file as the wizard won’t let us proceed without specifying some guidance file. In creating a more “serious” Package Accelerator, I would recommend that you put in at least some basic information about the exact package version installer or maybe an actual URL to it if it’s freely downloadable.

Selecting guidance file

When all of the other steps have been completed, all that is left to do is to save our Package Accelerator to disk. App-V Package Accelerators are stored in the form of a CAB file and in this case we save the resulting CAB to our package’s directory in want of a better place.

Creating actual Package Accelerator file (CAB)

As you can see the creation of App-V Package Accelerators – a new feature of the Sequencer 4.6 SP1 – is pretty straightforward at least with the smaller applications. In more complex and bigger applications it could take considerable more time given that you need to virtualize the application first and then make sure that your installed application or source location matches files very accurately. But, in bigger applications the outcome is also much more useful if you need to reproduce the package again from scratch since executing the Package Accelerator is a very foolproof way to produce package “to the spec”.

Download Package Accelerator for 7-Zip File Archiver

Now that 4.6 is officially out, many of you who are existing Softgrid / App-V customers are looking into migrating to this new version, especially if having Windows 7 projects etc. going on as well.

However, what Microsoft recommends you to do in such case is to upgrade all your virtual application packages into new 4.6 format. This was also true and official recommendation when 4.5 came out back in the day. But if you really want to do this for all of your packages, opening up every package one-by-one with 4.6 Sequencer, and then saving out (remember, you need not do anything besides Open + Save, this effectively writes out SFT file in new format and creates manifest file if none existed before) can be tedious task.

Also somewhat depending on what App-V infrastructure model is used, there might be need to change streaming URL (HREF attribute in the OSD file’s CODEBASE element), set of supported OS values and perhaps other aspects for the package,

Fortunately there is a better, not to mention much quicker, way to do this tedious task with little actual human involvement. The answer of course is my SFT Encoder product, which is designed to be used as command-line based App-V package processing utility and with batch processing GUI, handy mass-migration tool. As 2.0 version now fully supports new App-V 4.6 package format in both 32-bit and 64-bit environments, this means that you can migrate your old packages to newest format with automated process in one go!

As a brief example, let’s look at how to upgrade batch of packages to 4.6 ready versions:

After installing SFT Encoder, we run it once from the command-line and supply license with /license -switch (note that this is not needed with trial version). After that, we can start using batch processing GUI.

Firstly we have to tell where from source packages are read in, by supplying directory path under from Encoder scans for available packages. We also specify where to packges are to be output when conversion has been done: 

Select source and target directories

Select source and target directories

 Next, we specify parameters for conversion. In this case, we want to change fileformat version (as selectable from Version -dropdown list) but even if it is technically possible to change block size setting to match 4.6 default (and for new packages, only) of 64 kB it’s generally a ad practise to change it afterwards and not really supported by Microsoft either. We also want to put outputted packages each to its own subdirectory on target directory and we want to change streaming source for SFT file in all of the OSD files to match our new target environment.

Select processing settings

Select processing settings

As a special treat, we also want to remove possible Windows Installer runtime files found inside the VFS as part of the processing. As you might remember, App-V up until recently defaulted into adding those runtime files for all new packages unless explicitly removed during sequencing wizard. Problem with MSI runtime files is the fact that they may prevent package from self-repairing virtual environment on the client for the current user if Windows Installer runtimes differ between host and DLLs stored in the VFS.

If we wanted, we could have prevented generation of new history entries or even removing all traces of past history entries, but in normal migrations there is really no need for it. If however deciding to so, these two settings cannot be mixed together as that would result invalid SFT file!

Lastly, we can adjust other few content generation/modification aspects for processed packages, if for instance we wanted to inject some registry or file data into the package along the way. In this case, we are only intrested in removing all possible OS -elements from the OSD files so that they will show in our brand-new App-V client environments, be it 32- or 64-bit or workstation or RDS session host: 

Content modification options

Content modification options

 When we are ready to proceed with actual conversion process, just hit Start Processing -button!

Batch processing GUI will then go through all subdirectories in the selected source directory and tries to detect all Softgrid/App-V packages from the presence of SPRJ files, and then issues appropriate parameters to actual SFT Encoder executable (command-line -based, but run hidden) to process each package individually: 

SFT Encoder processing packages

SFT Encoder processing packages

When all is said and done, we have collection of App-V 4.6 conforming packages in our output directory and beneath, without having to go and processing each with Sequencer one-by-one. Of course this does not imply that packages shouldn’t be then tested with actual clients, since sometimes some old packages might refuse to work in the new environment especially if operating system changes underneath. But at least with larger number of packages time saving can be significant, especially since you can also automate annoying server address and OS changes within OSD files.

Please note that SFT Encoder will not output MSI wrapper installer (at least not yet), but all other package files including the manifest are automatically generated if none exists in the source package. And there’s quite much more than just this for SFT Encoder, since batch processing GUI exposes only few of the options available, those most common things needed during mass-migration.

If you don’t want to jump in and purchase SFT Encoder right away (which you should of course :-)), there is a trial version available for time-limited testing.

Happy conversions!

Microsoft has just announced public availability of official App-V 4.6 version.

The highly anticipated 64-bit support is now here as are few other enhancements plus two new App-V Resource Kit tools, Application Virtualization SFT View Tool and Application Virtualization MSI Compat Transform.

Both Desktop (part of MDOP 2010 package) and RDS versions of App-V 4.6 are immediately available.

One of the admittedly greatest puzzles in Microsoft App-V usage has so far been the lack of visibility for the PKG files.

These PKG files – as all App-V admins very well know - basically contains file and registry data that has been cached for the user and for the machine after App-V enabled application has run on the client. To make things more complicated, it is just not user and machine data as such (like Sequencer presents the division with Application Data and User Data in UI) but it also involves the factor of who has made change in the client system. And “who”, in this context, being either present user or system itself. Before Softgrid 4.2 really, this was more clear-cut and simple: changes to files marked as Application Data/Config were visible to all users on the client machine whereas files marked as User Data/Config were visible only to user who initiated the change. But alas, not anymore.

On a physical level, App-V client caches data to several different PKG files depending on who’s change we are talking about:

  • UsrVol_sftfs_v1.pkg file in user’s own (roaming) Application data represents changes to files marked as User Data that are initiated by and visible to processes of that user (i.e. are running as that user), usually meaning applications you  (as user) launch and use from App-V package. This file also contains cached virtual environment configuration, which practically means changed virtual registry, for the user.
  • UsrVol_sftfs_v1.pkg file in per-machine App-V cache (C:\ProgramData\Microsoft\Application Virtualization Client\SoftGrid Client\AppFS Storage in Windows Vista and 7, under All Users -profile in earlier Windows versions) represents changes to files marked as User Data that are initiated by and are visible only to few selected Windows system processes (like winlogon.exe) having access to Q: drive.
  • GlblVol_sftfs_v1_user_SID.pkg file in per-machine App-V cache represents changes to files marked as Application Data that are initiated by and are visible to processes of user account having SID in PKG file’s name. Normally, you should see one with your account’s SID in there but on machines having multiple users there’s one for each.
  • And finally, we have GlblVol_sftfs_v1_S-1-5-20.pkg file in per-machine App-V cache representing changes to files marked as Application Data that are initiated by and are visible to system level processes running in the virtual environment. These processes are, for instance, virtual services started from the package. This file also contains cached virtual environment configuration for the system.

 So knowing that there’s multiple contexts involved for caching, how do we know what the heck is actually cached (as opposed to coming from original SFT) on the client since sometimes this is needed for troubleshooting purposes? Sad answer is that we actually do not know this, since App-V Client does not provide any tool to view cached information besides starting cmd.exe or such in the package’s VE and trying to poke around in system with registry editor etc. The problem of course is that this method does not provide any information which of the files or registry values differ from what we have from SFT itself as everything is merged down for us by App-V itself. Also, this method does not reveal contents of alternative contexts, since we (or our processes) are by definition operating under our own user account.

Thus, the holy quest for PKG viewer :-) Up until now, nobody has been able to produce such viewer (at least publicly!) and Microsoft has not been very forthcoming in opening up PKG fileformat (which incidentally is actually the same fileformat as App-V’s very own package cache, sftfs.fsd file, uses). But, in preparing for very near release of SFT Explorer, version 2.0, I decided to once and all to resolve this need and am happy to report that I have been able to do it!

Code is not finalized yet, but I know how to do it, and as a proof here’s four different view of cached [PKG] contents of Firefox 3.0 package that I have been running for ages on my machine:

Here’s how the UsrVol… -file looks like for the current user:

UsrVol_sftfs_v1.pkg for user

Here’s how the UsrVol… -file looks like for the system:

UsrVol_sftfs_v1.pkg for system

Here’s how the GblVol… looks like for the user:

GlblVol_sftfs_SID.pkg for user

And here’s how GblVol… looks like for the system:

GlblVol_sftfs_v1_S-1-5-20.pkg for system

As you can see, there’s clearly a vast difference how different processes see the world, and these screenshots are not even including virtual registry!

As stated above, this PKG viewing capability is now likely to be part of upcoming version of SFT Explorer, and to track things related to it I invite all to join to SFT Explorer Users -group in LinkedIn.

As a natural succession to a fact that Microsoft has now included App-V’s Terminal Server (Remote Desktop Services) version usage rights in its RDS CAL (previously known as TS CAL), this version is now downloadable straight from the Microsoft Download site instead of using Licensing -site as before.

However, to download this package, you first have to enter Product Identification Key of Windows Server 2008 or 2008 R2 TS into mandatory registration form..

I noticed that Remote Desktop Services Team has posted a new App-V related script to Microsoft TechNet Script Center.

This script is mainly meant for running locally installed apps inside App-V’s virtual environment – without sequencing them – in order to quickly fix certain compatibility problems that App-V’s VE can make go away (like, for instance,  registry change conflicts). This in no way  means that application being run this way is truly virtualized application and that it couldn’t in any way conflict with other locally present applications.

To do its “magic”, script utilizes one lesser known feature in App-V Client, first introduced in 4.5 version, making it possible to specify alternative executable which is launched instead of file pointed by OSD’s FILENAME attribute.

It should be noted that the script requires that Default App-V Application (DefaultApp.osd) has been published to a client as script uses that OSD as virtual environment for application.

In this multi-part series, we take a look at under covers of files that make up an App-V package. Some of these files are in binary format, which makes them interesting more or less to those of us who develop software, while those files that are human-readable (XML formatted) textual data can easily be examined and edited by App-V administrators and packagers using normal text editors and tools.

 

Overview of package files

We begin our journey to App-V files by taking an overview on what files (by extensions) you generally can expect to see when looking at the directory holding a complete App-V package:

.SPRJ file

This file, of which there is only one per each package, is Softricity Project File, binding logically all other package’s files together. This file is used by the Sequencer and optionally Management Console which is associated with Management Server –based infrastructure.

.OSD files

Per each package, there could be a multitude of these files, which derives its name from ages old (and mostly forgotten) RFC note called The Open Software Description Format (http://www.w3.org/TR/NOTE-OSD.html), originating from Microsoft and company no longer with us, called Marimba. This file used and required by the Sequencer and App-V Client, each OSD file representing one single startable application from the package. Or as another way to look at it, each one representing one particular shortcut you intend to publish to client machines.

.SFT file

This file which got its name from Softricity, the company who originally created App-V, nee SoftGrid, is the second absolutely required file by the App-V Client. It contains all the actual content (applications and related files plus virtual environment) of the App-V package, packaged in binary format somewhat like in ZIP archive.

.ICO files

In one package, there could be number of standard Windows icon files, which map either to application shortcuts (i.e. OSD files) or to file types associated with individual applications found inside the package. Since App-V packages do not carry executable (EXE) files for applications outside the virtual environment, Windows needs to have icon files separately so that users can see familiar program and document icons when virtual applications has been deployed to their machines. For this reason, Sequencer extracts these icons as “naked” ICO files to the package directory.

.XML file

Each package has one package publishing -related file, called Manifest file. This file contains aggregated information from SPRJ file and OSD files, and it is used (quite rarely directly) by App-V Client but more prominently so by Microsoft System Center Configuration Manager (SCCM) to make the whole App-V package and all individual applications from it available to the client, when no App-V Management Server is available as source for publishing information.

.MSI file

As an optional and additional file, standard Windows Installer database, MSI, is created by the Sequencer, one per each package. This MSI can be used to deliver the package to App-V Clients as alternative way to using App-V Management Server publishing or SCCM delivery.

 

In addition to these physical files that you can observe directly in the package directory, each SFT file holds – among other application related files – one App-V package specific file which is also referenced from each and every OSD file in the package:

.CP file

This special file, having extension officially coming from “Computer Protection” (thanks for Tim for revealing that bit of info ;-)), is the virtual environment’s configuration file for the package. It contains not only the virtual registry in it, but also something called Virtual Filesystem (VFS), and it is used by the App-V Client while establishing (or “uploading”) Virtual Environment when virtual application is launched.

 


In the upcoming articles of this series, we will take a closer look at the contents of following file types described above: SFT, CP, OSD, SPRJ and XML.

Stay tuned!

Sorry, this entry is only available in Suomi.

Sorry, this entry is only available in Suomi.

One of the more obscure functionalities in App-V is the concept of differential SFT files. These DSFT files were introduced into product during 4.5 Release Candidate -phase, at which point you actually had UI option in the Sequencer for generating such an output:

DSFT Option in Sequencer's UI

 

In a very surprising move, this option was actually removed from the Sequencer when RTM was released. I guess it was confusing enough that they felt better to hide the whole thing rather than trying to explain it.. But fear not, DSFTs are still with us (yes, even in 4.6 beta), it’s just that you don’t really see it anywhere. The purpose of this post is to explain them and also show how you can use DSFTs and why.

 

So what is DSFT anyways?

Differential SFT files are, like the name implies, SFT files that contain the differential data (delta) between two versions of the SFT files; the older one and the upgraded one. This is a bit like what you would expect from the MSP files in context of Windows Installer, but of course it is not fully analogous.

DSFT files contain the identical headers to the upgraded SFT file, but only those blocks (FB 1 and 2) that is new to that particular version. This basically enables you to deliver upgraded App-V packages just as that, as upgrade, instead of traditional way of delivering new full SFT file which may contain loads of [old] data the client already has. With streaming, this is of course no problem because of differential streaming, but when servicing standalone client it would be handy to deliver only those bits that matter.

I should stress that the differential SFT file is just the differential between two consecutive versions i.e. if you have package in the client cache that is from the older SFT version (not previous to the most current one) you are not able to bring it up-to-date with the latest DSFT file; you would actually need to have one DSFT file applied per each upgrade version!

 

How do I create one?

As previously said, there used to be option in the Sequencer for a very brief while for creating a DSFT file. You can notice still in 4.5 builds the strange missing line in the checkboxes for Deployment -tab, that’s the placeholder where the DSFT checkbox used to be.

Now without GUI based option, out only choice – at least for time being – is to use executable that actually ships with Sequencer but probably not many knows about: mkdiffpkg.exe.

This tool is a very simple command-line based DSFT generator, which basically needs one input file and one output file; SFT file and DSFT file, respectively. The whole idea is that you choose your upgraded SFT file as source and the tool scans what blocks match the SFTs version (remember, as of 4.5, App-V Sequencer assigns file versions to match the SFTs version, instead of incrementing by one by each change as it used to be). These blocks are then written out as DSFT file, specified as second argument for mkdiffpkg.exe, ready to be delivered.

One of the reasons the checkbox in Sequencer UI was confusing is exactly this; DSFT generating is clearly an post-Sequencing task which did not sit in the flow how Sequencer is used. If you enable the check-box, does that mean you want changes for this version or the one you trigger by saving? You cannot also create DSFT against your very first version of SFT, that would not make sense. And hence the checkbox was always grayed out when doing Sequencing (adding to the confusion still), only when you opened package for upgrade you could enable it.

DSFT creation example

So, let’s create an example difference file for one of the applications available at my InstantApp -site. For simplicity’s sake I’ll choose VirtualDub which is an AVI video editor and provided in ZIP file instead of full-blown installer. The version I’ll base my upgrade on (and which is available at the site in time of writing this) is 1.6.14, clearly not the latest anymore as one available from VirtualDub’s SourceForge site is 1.9.5.

As a first thing to do, I’ll perform an usual upgrade to App-V package. Note that my package was originally created in 4.0 (!) Sequencer, so the upgraded one is by necessity now brought to 4.5 level (I’ll use 4.5 RTM for this):

 VirtualDub v1 package

 

Ok, so for this upgrade I simplycopy few files over from the extracted ZIP file to my package’s directory structure on Q: -drive:

Copy files over to Q drive

 

Then we start the main application (VirtualDub.exe) like you always should (2-3 times) and this time for good measure; it asked about license agreement and also presented first-run dialog. Moving on and after stopping the monitoring, I’ll remove unnecessary MSI runtime files and also modify shortcut to reflect the changed version number.
After not optimizing for FB1/2 (it’s too small package to make any difference with such a thing) I’ll examine the results before saving and see that some of the files are not at version 2 but still at version 1. These are the ones that do not get included inside DSFT file I’m going to generate in a short while:

 V1 files in upgraded package

 

Next I’ll just simply hit save in order to create v2 version of my VirtualDub App-V package and sure enough, I soon have my package files for version 2:

SFT version 2

 

Comparing this new version of SFT file, I see that it’s size has increased by over 2 megabytes over v1 of the SFT file. Now only thing left is the interesting part, the DSFT generation:

Generating DSFT file for VirtualDub

 

Yes, it’s that easy ;-)

Looking at the DSFT file generated, it’s 3388 kB in size, so we really couldn’t save much space (3419 kB – 3388 kB = 31 kB!) in this particular upgrade scenario, but for packages where less files changes the saving could be significant. Just think of Office hotfix for instance..

 

How/where can I use this DSFT file?

That’s a very good question. As it is, there’s no UI options or indication in the MSI wrapper or SCCM integration or, well, anything anywhere that would suggest an ability to use DSFT files. But that does not mean there actually isn’t way to utilize those delta files!

Yes, I’m talking about good old sfttray.exe here. This is the executable that MSI wrapper also uses in the background for loading (importing) SFT file when you deliver virtual applications via MSI file to the client. And it is that very same syntax you can use for reading in DSFTs, just simply by pointing to DSFT file instad of SFT:

sfttray /load “MyApp 1.1″ /SFTFILE c:\tmp\MyApp_2.dsft

This will trigger loading of package into the client’s cache, but instead of loading the whole package we actually load just the bits available inside DSFT, resulting an update to the package without overhead of moving whole SFT around.

As can be seen, this would be very easy to incorporate into one’s own scripts. Or, maybe even to use when delivering those wrapped MSI packages, but instead of pointing to SFT just point to DSFT!

DSFT usage example

Continuing our earlier example of VirtualDub, let’s now apply the difference to the client. For this purpose, I’ll have 4.5 client installed which has already received the v1 of the VirtualDub package from Management Server. My task is to apply v2 version to the client using DSFT version instead of publishing our upgraded v2 SFT through Management Server:

VirtualDub, version 1 is published

 

 When launching VirtualDub at the client, I can verify from the GUI that it’s indeed original – unupgraded – one:

Version 1 on the desktop

 

So let’s do an upgrade via DSFT file we generated after sequencing.
Remember to close all applications from the package, otherwise you cannot upgrade package data in the cache (DSFT or otherwise)! You also need to have permissions set to allow importing or be local admin in order to import via sfttray and you HAVE to specify full path to the DSFT file:

 Loading DSFT via sfttray.exe

 

 Now, only thing left to do is to check if our upgrade with DSFT actually succeeded to achieve what we wanted. As we could see the version directly from the VirtualDub GUI, simply re-start it from the existing shortcut and see what happens..

DSFT upgraded package on the desktop

 

Success! :-) We managed to upgrade our package with DSFT file!

 

Although there is one caveat you should be aware of (and I bumped into this during my testing): if your original package has been delivered to desktop via Management/Streaming Server (as mine had), client will try to do downgrade of the package from DSFT upgraded one when you launch it, unless you have matching updated SFT file published in the centralized server as well. The reasonfor this is very simple: client will have a check with the server (if it can be reached) each time you launch an virtual application and if the server contains older SFT than one you delivered with DSFT, client will think it needs to revert back to older version (”Active Downgrade”, if you will)!

In any case, DSFT is something you definitely can take advantage of by following the advise I have outline in this article. Just be careful with it when combined with the streaming delivery.

You can download my upgraded package and DSFT file used in the examples from here and here.

Happy DSFT’ing!