What’s under your hood? PowerShell?

What’s under your hood? PowerShell?

What’s under your hood? PowerShell?



This blog is the first part of a series that aims to illustrate why it is important to understand what technology is driving your application automation and why it should matter to you. (Pre-Analysis and Flat File conversions to follow in separate blogs)

In this initial post, I will write about one of my favourite additions to the App-V world, the PowerShell commands. Before I start, I just want to point out that I really love the App-V PowerShell commands and I use them often. If this blog appears in some places a bit negative, I am only referring to a tiny subset of the App-V PowerShell command offerings. I only have some gripes on how these conversion commands are used and sold to you.

There are a number of ‘automation solutions’ that rely on just the PowerShell conversion commands. To keep in line with our topic question “What’s under your hood?”, many conversion tools will probably proudly (or not so proudly) answer with “I am running on PowerShell!”. I discovered that some hide this information, but there are some indicators to look out for to establish if they are using the PowerShell conversion commands provided by Microsoft to power their conversions on.

I must confess, I always cringe when I hear that Product X is doing App-V 5 automation and I find out that they are just using the PowerShell commands. Don’t get me wrong there is nothing technically wrong with using the PowerShell commands to convert to App-V 5.0. However, there is a time and a place to use the PowerShell commands which I will show you a little later. For me, it is not ethical to be considered as part of an ‘automated’ commercial solution.

The other objection I have with these ‘automated’ solutions is that they just slap on a fancy UI over something that Microsoft already provides you for free. If you like analogies, then think of sticking a VW Beetle engine in a Ferrari but paying the full Ferrari price. The car looks great and runs but not as you would expect ;).

I don’t think these companies are purposely trying to fool you and I found that although they are normally run by very technical apt individuals that they don’t really understand App-V and/or automation. I am very aware that it is very hard to find good developers that a) understand automation and b) understand virtual applications + installer technologies well. (If you know someone then please get in touch as we are always looking for new talent).

There is also little or no documentation available in regards to automating applications from physical to virtual and I hope this series of blogs will in some small way shed some light to the uninitiated.

Don’t worry, this is not a blog where I bash the PowerShell commands in terms of automation. In fact, I think there are many good uses for them and for some, the conversion via the PowerShell commands will be enough. If the PowerShell commands are a fit for you then I will show you in this blog how AutonoWare’s ConversionBox can help you in creating better packages for a fraction of the price.

I would strongly advise anyone to read the analysis in this blog (and the next two blogs) first before even looking at any Automation tools.

I hope that this blog will enable you to (using the car analogy) properly “test drive” your Automation options and check “what’s under the hood?”  I will leave it up to you to decide if the underlying engine justifies the price or not.

Let’s look at 2 applications that I converted via the PowerShell command and also converted with AutonoWare’s conversion technology to highlight some very basic differences. The below are just 2 very basic examples that quickly highlight some key differences. Don’t worry, I will delve into some more complex applications in the next few blogs and I will use some really nasty ones when we get into the Reporting pieces. If you require a more detailed under the hood deep dive then please contact AutonoWare’s sales team to arrange a session with a technical resource.

Issue 1 – No Root


For my first example I will use Orca and I used the minimum required of arguments for this demonstration:



Here is the output from the PowerShell command:





The package created is actually a pretty decent package as it is clean and seems to have all the necessary resources. However, there are two items that are not perfect. One is that it is sequenced to VFS and not to the Root.

“Hold on!” I can hear you App-V specialists shouting, “You didn’t specify the correct installation path and therefore it sequenced to VFS!”

Well, I had to guess the installation path to highlight a flaw here. The weakness here is that you only really know the actual installation path after you install Orca for example. There is unfortunately not one common way to force an MSI installation to a certain installation path. INSTALLDIR for example is actually rarely used properly. A good example is orca.msi itself (compiled by MS) does not use the INSTALLDIR property either and uses a custom action to set their installation path.





If you are not an application installation guru, then the issue in a nutshell is that you cannot be certain of the installation path until you physically install the application.

So, there is no global quick fix to set the PVAD (PRIMARY VIRTUAL APPLICATION DIRECTORY) automatically beforehand.

ConversionBox has technology that only takes seconds to determine the proper PVAD for you though. See how to convert apps for a fraction of the price with PowerShell later on.

Also, note that ConversionBox sets the PVAD property automatically. (The path is Root\orca.exe and not \VFS\…) Sorry, I couldn’t resist to show you how great ConversionBox packages look.




Issue 2 – No streaming optimisation



For this one I will use another really basic application, TextPad, as it is a bit more interesting in terms of requiring a few more files to launch. Orca is not a good example as it only requires its main executable to launch. (It is already part of the FB0 and therefore it won’t be in a FeatureBlock as well, so it wouldn’t be a very good example…. )




The issue is that you cannot launch the applications during the PowerShell conversion process to create feature blocks that get streamed first.

Feature blocks can greatly enhance the launch speed of your application. In essence, it will stream all resources that are required to launch the application first and the rest of the application after that. A bit like a YouTube video where you don’t need to download the whole content before watching it.

Here is a link to a good blog about the Publishing Feature Block http://blogs.technet.com/b/virtualvibes/archive/2013/02/27/feature-block-0-the-publishing-feature-block.aspx.

Here is what the stream map for TextPad looks like when converted via the PowerShell command:




So with the PowerShell conversion we only created FB0 – also known as the “Publishing Feature Block”. (It just contains all info for publishing the application like the icon etc.)

And here is TextPad that has been automated with ConversionBox:



ConversionBox sets the “PrimaryFeatureBlock” correctly. During ConversionBox’s own conversion process it launches all the application shortcuts and captures all the relevant files that are required to launch the application and creates the primary feature block accordingly. This will result in much faster loading packages than the one converted with the PowerShell command. ConversionBox also gives you a screenshot of what was actually launched:


And, for completion purposes, here is the VFS vs Root comparison:




When I would use the PowerShell conversion commands



I would use the PowerShell conversion commands when the applications to be sequenced are very simple and if I didn’t care about streaming optimisation or the fact that all files are sequenced to the VFS. One possible usage would be to stress test your App-V environment in a lab with actual applications.

If you don’t care about “Sequencing to Root”, “Streaming optimisation” and only want to convert easy applications then jump to the “How to convert apps for a fraction of the price with PowerShell and ConversionBox” part below.


When I would NOT use the PowerShell conversion commands



Any situation where I would likely encounter medium or complex applications.

I also like my packages to be nice and clean and the PowerShell commands can capture and includea large amounts of unrequired elements that clutter the resulting package (dirty package), which in turn can cause issues for the application. In fact, I personally never recommend the use of the PowerShell conversion commands for production purposes as they just don’t create packages that are good enough.

How can I tell if a tool just uses the PowerShell command lines?

Well, that can be a bit tricky as not everyone will be willing to tell you that their magic box is actually not so magical at all. A bit like the “The Turk” (Automation Chess Player) http://en.wikipedia.org/wiki/The_Turk


What’s under your hood? PowerShell?

What’s under your hood? PowerShell?


Here are some simple things that I ask or look for:

  • Do I need to specify the PVAD first?
  • How does it resolve the PVAD?
  • Does it sequence the files to root or VFS?
  • Does it create a proper feature map i.e. Can I have the option of creating a FB1?
  • Do I have the option to create streaming optimised packages?


Most importantly, as a last test I send 3 packages that I expect a Conversion tool to handle (easy, medium and complex). I would be surprised if they handle medium and complex applications well!

I have not seen any other automation solutions that can handle those apps properly. Incidentally, we test 1000s of applications that are an equal mix of easy, medium and hard applications with every release and always add new ones when we encounter a rogue application that stumps us.


How to convert apps for a fraction of the price with PowerShell and ConversionBox


OK, so you have decided that conversion via the PowerShell’s conversion command is good enough for you. Let me let you in on a little secret that if you purchase a base license of ConversionBox you will get all our reporting for free. The reporting will not only give you the insights of which applications are easy to convert or are compatible with Windows7/8 or App-V but they also give you the PVAD that we discussed earlier.

We have made it even easier for you and included a right click function in our reporting tool that will create the PowerShell commands with the correct PVAD’s for you.With a simple click you can create a PowerShell script with all the applications that you have selected. There are no volume restrictions.


We really don’t want you to spend a fortune on something so simple like PowerShell conversions. No one should!






I hope in some small way I have been able to show you how and when to use the App-V PowerShell commands to use. Hopefully, if you are interested in App-V automation, I have given you some good options to “test drive” & identify the automation solution that best suits your needs.

OK, I may be a little biased about what I would choose, but please use the above information to ensure you make the correct, well informed decision for your environment & specific needs. If you are OK with the result that a PowerShell conversion engine provides then please either you need to consider ConversionBox, which at least will give you the proper PVAD entries for a fraction of the price, or hire a junior engineer to write a script for you – either way you will be better off. If, however, you have some medium to complex applications & decide that PowerShell automation is not a good enough solution for you, be sure to take ConversionBox for a free test drive to greatly accelerate accurate clean conversions at a fraction of the cost.


CTO and founder of AutonoWare


One Comment

Leave a reply

You must be logged in to post a comment.