AVE Processing Automation

As some of you may remember, we used to have a product called Virtualization Encoder available a few years back. The idea of that product was running scripted – or template-based – automated operations against App-V packages, without user intervention. Now, that feature is sort of back in AVE!

In the new Application Virtualization Explorer version 4.2, released yesterday, we added a new functionality called “Processing Automation” to the product. The very basic idea of processing automation is to be able to perform certain operations against the App-V (5.0) packages that you would end up doing often, and for multiple packages.

Let’s say that you always want to remove certain directories from the packages, or if there’s some known extraneous files that you don’t want to have stored in every package (for example, cached MSI files) or you need to add some sort of watermarking information to the registry. Normally, what would happen is that you do the rote of performing those steps, one-by-one, manually, when you have new package from the Sequencer or created scratch with the AVE.

Sounds like a good candidate for automation, right?

Processing automation overview

With processing automation, you can now instruct AVE to run pre-defined “script” of operations against the package, using AVE Processing Automation -files (with .apa extension), that perform these pre-determined actions. At the initial release of the functionality, we support a handful of operations against virtual filesystem as well as the virtual registry but anticipate adding other areas related to App-V 5.0 packages later on, such as configuring Integration Subsystems or configuring extensions.

To make it easier to start experimenting, we have included two example .apa files with the 4.2 release which can be found from sub-directory called “Automation” underneath AVE’s installation directory:

The first example is purely documenting the different keywords available, and is a suggested place to start learning more. The second one, cleanup.apa, is an example of what real automation files would perhaps be that you’d use regularly. It removes number of directories and registry entries that Sequencer frequently captures into .APPV package, but which are unrelated to the actual application within (i.e. artifacts of Windows’ own operation).

You can run processing automation files from the AVE when you have package loaded, using Tools->Run processing automation -command from the menu.

How to define the operations

The syntax for .apa files is rather simple, first there’s the main (heading) level declaration of which object type you are performing operations against. As said, we now have both filesystem and registry, but hopefully later other objects as well. As such, the objects are “RegistryKey”, “RegistryValue”, “Directory” and “File”. These declarations has to be non-indented.

Underneath the object type, all other declarations need to be indented (with tab or spaces). The syntax is based on keyword:data format, where keywords are properties or commands known by AVE, and data is related to the keyword. All declarations always end with “Action” keyword which then performs which-ever action is required. All declarations always start with “Path” or “Scan” keyword which tells to AVE which particular piece or pieces of filesystem or registry is being operated against.

As an example:

File
  Path: Root\MyApp\myapp.exe
  Action: Remove


This will tell that AVE has to remove a file called myapp.exe, which resides underneath Root\MyApp -directory within the package (remember, all paths start with Root as in the actual root of the package’s filesystem are files used by App-V itself: appxmanifest.xml, streammap.xml etc.).

As another example, if we want to change the virtualization level for particular registry key, we could use the following declaration (this one also create the key, if it does not exist):


RegistryKey
  Path: MACHINE\Software\Gridmetric
  VirtMode: Override
  Action: ModifyOrCreate


Or even change all registry keys that have a certain name (wildcards allowed):


RegistryKey
  Scan: Google*
  VirtMode: Merge
  Action: Modify


Or change all registry keys that are under some specific path:


RegistryKey
  ScanPath: MACHINE\Software\Classes\CLSID\{CAFEE*
  VirtMode: Override
  Action: Modify


Of course if you multiple operations for registry keys, you can put them all under one “RegistryKey” block.

In the AutomationExample.apa file, you can find other commands that can be used; including a method for doing search&replace inside text files within the package.

We have tried to come up with a sensible syntax and features for .apa files, but of course only time will tell what else might be needed. As such, please send us your feedback and if you have specific use -samples that we could add support for!