App-V Decision Matrix v5



Recently I updated my decision matrix. It seems to be one of my most popular posts on this site. I’ve brought it up a few times whilst presenting over the last couple of years. In my last two presentations, I told attendees, look this exists currently but I’m not entirely happy with it. I want to change it around  a little bit and make the length of the post much smaller, if possible. Well, this is that post! I’ve split up each individual decision in to it’s own post to keep things a little more organized.

Although this does reflect App-V 5.0 SP3, it really did not have a huge impact on the decision matrix. The ability to use RunVirtual in both User Publishing and Global Publishing may help you out with those Add-in, Middleware or Runtimes but other than that the drive for change has mainly come from my own experience and comfort level with App-V 5.0 and it’s awesome scripting capabilities. So, check it out. Feel free to comment. Much of this is based on my own experiences. If you disagree with anything please comment.


I have to thank Aaron Parker for the awesome job he did redesigning my previous, awful Decision Matrix! Thanks, Aaron. I hope I didn’t mess it up too much making changes.

1.) Machine Specific Licensing : Machine Specific Licensing Decision Explanation
2.) Boot Time Services : Boot Time Services Decision Explanation
3.) COM+ : COM+ Decision Explanation
4.) DCOM : DCOM Decision Explanation
5.) Drivers : Drivers Decision Explanation
6.) Middleware\Runtimes : Middleware/Runtimes Decision Explanation
7.) Add-ins and Links : Add-ins and Links Decision Explanation


Dealing with App-V Limitations: Add-in or Links




If you have an application that’s an Add-in or a Link, you should consider if it’s an Office Add-in. If it is, do you have Office virtualized in your environment? If you do, Deliver it with App-V and use a Connection Group. If Office is not virtualized, you could use RunVirtual or modify the local Excel, Word or whatevers shortcut target with the appvve switch pointing to the sequenced Add-ins ProductID and VersionID as explained HERE. Of course, changing the Office Shortcuts in that way is a little messy. Using RunVirtual requires a level of planning and maintenance that may seem to much, particularly with Office Add-ins as they are quite common. I also talked about RunVirtual a little bit in a previous post: HERE

If your link or Add-in is not Office related, deliver it using App-V :) Though, I will make one additional point. If it’s just a Website, consider whether or not you really need to use App-V. Of course it is possible to use App-V to deploy web apps but sometimes, personally, I feel like it’s overkill.


Dealing with App-V Limitations: Middleware\Runtimes

This was a tough one to put a label on. Here I’m referring to commonly shared dependencies. This could be Java, Flash Player, VB runtimes, Access runtimes or other forms of runtime, middleware or even just a widely required pre-requisite\dependency. As the title of my blog post might suggest, App-V has limitations. Certain application will not work when sequenced. So what happens when your application cannot be sequenced and say, it requires a vb runtime. You have sequenced this vb runtime for use with other applications. Now, you’ll need to package the vb runtime and deploy it locally to cater for this other application which cannot be sequenced.

With App-V 4.x, you’d have no other option but to re-package for a local install BUT with App-V 5.0, we now have the RunVirtual feature and with App-V 5.0 SP3 this feature is much more flexible as it allows for publishing using User Publishing or Global Publishing. RunVirtual will allow you to set a registry key which will enable your locally installed application to see and leverage your virtualized Middleware\Runtime\Whatever. For more about RunVirtual check this out HERE Now, using RunVirtual can require some proper planning. It’s a little limited in that you may need to create connection groups with many different applications (if multiple virtual applications are required) which are required by the local app and set the RunVirtual for the primary application which will invoke the connection group. I know, it’s confusing, right!?

There’s also the option to use the /appvve as documented HERE if the commonly required local application has a shortcut which is invoked. Basically you set an argument in the Target of the local application shortcut which points to the virtual application ProductID GUID_ Version ID GUID. It works but it’s a little messy!






As per the graph, I suggest that if your application is Middleware, Runtime, something which is commonly required by applications there’s a bit of decision process I’d consider. Is the application shared by virtualized and installed apps, if it’s not and you know it’s not going to be, go ahead and sequence. Now, if your application is shared by virtual applications and locally installed applications I’d suggest that you could still sequence the application and then use RunVirtual or the appvve switch to support the local applications that require it. If the application is middleware but you don’t want to use RunVirtual or the appve parameter due to the messyness or possibly the limitations of RunVirtual, go ahead and deploy as a local install.