Diagnostics in the App-V 4.6 SP1 Sequencer

About 12 months after the initial release of App-V 4.6, Microsoft released the first Service Pack of version 4.6 of its Application Virtualization product. App-V 4.6 SP1 covers many exciting new features and the most interesting part of it is that practically all of them are around the sequencer! As far as I know this is the first time in the history of App-V that so much effort and improvement is done only in the tool to transform traditional applications into virtual ones. In this post I will address one of the features I like the most and have been asking for and talking about for years: internal diagnostics.

Most organizations turn to App-V because they want to reduce the Total Cost of Ownership (TCO) of their IT infrastructure. For App-V this cost efficiency lies in the fact that the process of creating virtual applications is simplified compared to traditional applications. Traditional applications are more difficult to create because they make assumptions about their execution environment and make changes to the target system, which could potentially decrease the stability of the system or cause other applications to malfunction. Virtual applications however never make changes to the system and their dependencies can be either virtualized together with the main application or suited as a separate virtual application.

But as with any piece of technology, App-V also has its limitations. Some applications, or parts of an application, may not work correctly when they have been virtualized. Applications that are tightly integrated with the operating system or for example use COM+ or kernel-level drivers, contain components that are not supported with App-V. The issue with all previous versions of the sequencer is that to know that an application has such components, you’d have to virtualize and test it on a target machine. This means that you’ve already went through the entire virtualization process.

Service Pack 1 of App-V has been altered just for this scenario. When the sequencer notices that the applications uses unsupported components it will bring this to your attention during the sequencing process. This way you don’t have to go through the process of testing and troubleshooting the application only to find out it can’t be virtualized. The following possible issues are detected by the sequencer:

  • Drivers
  • COM+
  • SxS Conflicts
  • Shell Extensions


Picture 1: 7zip uses shell extensions which were reported by the sequencer.

Another great addition to the sequencer’s intelligence is that it also gives you an extensive report of files and registry keys that were excluded from the package. With earlier versions you could spend a lot of time figuring out why the application was running on your sequencer machines and wasn’t running on your target machines. This information is not only presented during the sequencing process but it’s also saved as report.xml in your project directory for later reference.


Picture 2: Google Chrome installs its main executable in an excluded directory, which was reported by the sequencer.

When you are updating an application and the sequencer notices that the machine you are currently running on does not have the same baseline as the one you created your sequence on, it will give you information about these differences. System differences might influence the way the application is behaving, which is not preferred. If you think the application might have issues with these differences, you can change the system accordingly. The sequencer looks in your Add/Remove Programs control panel applet to find installation differences.


Picture 3: The .NET Framework was updated compared to the version that was installed on the machines where the sequence was created on.

Improving the success rate of virtual applications can also be done before the sequencing process. Microsoft has summarized many best practices in the whitepaper [Microsoft Application Virtualization 4.6 Sequencing Guide; http://bit.ly/SeqWp46Sp1]. However more than once, inexperienced people are not familiar with these best-practices and run into trouble during the rest of the process. The App-V 4.6 SP1 sequencer checks most of the common best-practices prior to starting the sequencing process.

It will warn you when certain services are running that can negatively influence your virtual application because they can lock certain files (like Windows Defender or Windows Search) or because they may update your system in the background (like Windows Update or the Configuration Manager client). If these changes accidently end up in your sequence it may become unnecessary large, slow or even unusable. But also pending reboots, non-reverted virtual machines or other running applications are reported.


Picture 4: Pending reboots, Windows Defender, Windows Search, Clean Machine, Disk Defragmenter, Configuration Manager Client; all were detected by the sequencer prior to starting the virtualization process.

Like I said in my introduction, I’m very excited by these new features because it will improve the predictability and success rate of App-V virtual applications. It definitely saves a tremendous amount of time troubleshooting applications because of malfunctioning.