App-V is one of those technologies that has a small but extremely enthusiastic fan base. And thinking it might be useful at my company, I decided to give it a try. After doing a 2-week deep dive into it and sequencing/publishing a few apps (Java, Reader, Citrix, Chrome, etc.), I think I have a pretty good handle on what it's all about and what it can do.

Unfortunately, I'm rapidly coming to the conclusion that App-V creates more problems than it solves, and I am posting this question in the hopes that someone can help me understand if I'm missing some fundamental point of the product, or if App-V just isn't a good fit for my environment.

So here is a list of App-V's promises as I understand them, and the reality I have observed working with it:

Promise: Application coexistence. App-V allows you to package and run applications together that normally don't get along well with each other. We have two line-of-business apps with dependencies on the Pro version of Acrobat 9, and Excel 2010 respectively. Both break horribly when modern versions of Adobe Reader or MS Office are installed, and neither works well in an RDS environment. Since Office and Reader are core apps, I have to manage those PCs separately, which is a pain in the butt. App-V should allow me to package those apps together with their dependencies inside the App-V bubble, so they won't be disturbed by their natively-installed brethren.

Reality: It doesn't work that way. In order for coexistence to function properly, both instances of the dependent application (Acrobat Pro/Reader, and Office 2010/2016) must be virtual. Which means I either have to make them virtual for the whole org, or I'm still stuck managing those PCs separately. App-V doesn't get me anything.

Promise: App-V allows you to package applications with your own customizations so that users do not see things like first-run dialogs, useless icons, or prompts for information they don't know (like server names) that would ordinarily generate help desk calls.

Reality: I've gotten really good over the years at suppressing all that garbage with scripts, group policies, etc., so we're already doing this with natively-installed apps. The amount of time it takes to shut these programs up with scripts and registry hacks is about the same as it takes to sequence and customize the program on a reference PC. There's no time savings there. Also, some apps just plain don't work with App-V so you have to script and hack those anyway.

Promise: Virtual applications are fully sandboxed, offering better security and application resiliency. App-V packages cannot interact with one another except through connection groups that you control. And while Microsoft explicitly warns that this is not a security boundary, it nonetheless does reduce the attack surface for malware. Additionally, native applications frequently leave turds all over your filesystem and registry that do not get cleaned up when you uninstall, making troubleshooting more difficult. But virtual apps are self-contained bubbles, making them easy to cleanly remove or revert to a known good state.

Reality: App-V packages are not Docker containers. They are hidden from the OS, but the OS is not hidden from them. They still leave turds all over your filesystem and registry. And because most apps have COM interfaces must be exposed to the OS, virtual apps are mostly hidden from the OS, but not fully. This makes troubleshooting harder, not easier. Also, we use profile roaming, folder redirection, and have a homogeneous desktop image. Any computer that will take more than an hour to fix gets nuked and reloaded.

Promise: Streamed content. Virtual applications are delivered only on-demand, and only take as much disk space as required for the features that people actually use. This is good because we do have a disk space problem around here. Also, streamed content can be used for locked-down static desktops such as thin clients with write filters, or VDI scenarios.

Reality: Content streaming is just too slow to be useful. Even on a standard workstation with a LAN connection, there is an initial delay on first-launch while the package's critical bits are fetched and cached. Then, as new features are used, there is another delay for those bits. There is no user feedback given, and the delay is long enough to make people think their computer is broken. This makes for a truly awful user experience. And then there's the issue of laptops. If you take one off-campus, you're dead in the water if you try to use something that hasn't been cached. You can only mitigate this problem per-package, not per-device. Unless you're using SCCM (which we are), in which case, the package "streams" from the local SCCM cache to the local App-V cache, taking up TWICE as much space. Yay!

So I reiterate my question. What's so great about App-V? I can see some great benefits to virtualizing apps, and there are entire web sites out there dedicated to App-V recipes and techniques. I want to love this product. But with the problems I've outlined, I can't really justify it.

Or am I missing something here?

closed as primarily opinion-based by yagmoth555, womble Sep 22 '18 at 0:03

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.


You've pretty much hit the nail on the head with your very thorough critical analysis. There are certain apps that work in all your scenarios and other that just don't play well.

I'm not sure that your comment that streaming content gives no feedback is accurate, there is a status bar that shows initial launch progress and a confuration option to background stream the rest of the package silently.

Full disclosure, I haven't used it in a few years (was using in pre 4.0 days when it was softgrid up to about 4.6) bit I'm looking to start testing it again soon.

I was using it in a reasonably large education institution and found a few things that were useful that you haven't mentioned.

We had a very large range of applications that users could want to access from any desktop, using App-v meant that we did not need to deploy these in advance meaning core image size is massively reduced which speeds up image deployment time.

The inherent concurrent use limit meant that we could licence some applications that were to costly as a site licence but allow them to be accessed anywhere.

Applications could be resequenced for updates etc and be immediately available on any machine.

TL;DR It has some great benefits but it's not the holy grail.

  • I have noticed that progress bar you speak of, but it seems inconsistent. Sometimes it shows and sometimes it doesn't, and I'm not sure why or how it decides when to appear. I had it on my list of things to circle back around to if/when I got to the point of polishing and dropping a final solution, but I never got that far. – Wes Sayeed Sep 21 '18 at 17:09

Firstly, I agree 100% with you.

Secondly, I work only with SBC (Citrix, but RDS would be the same). We host multiple small (1-50 users) customers on large servers, up to 100 user per server (yes I know, no it's not my call).

App-V is great for one thing for us. Hosting several totally separate customers who have the same application (a lot do because we are a big actor in one industry) that does not support more than one installation per computer. App-V makes it at all possible, where without App-V (or similar virtualization) it would not be.

That said we have had a hell of a time wrangling with App-V throughout, and many of its promises fall flat. Application management is horrible. Updating the packages is actually impossible in many cases and we need to roll new applications for new versions, making deploying them even more work. And don't get me started on the Sequencer or bugs in streaming that can happen. It also takes a lot of time to get a recipe right for a complex application, and you might need a deeper understanding of it than otherwise.

We try NOT to use App-V for application we can install without it simply because it is easier, faster and simpler to troubleshoot and maintain.

As for answering your question and concluding: It lets us do something that should be impossible, but at a cost.


App-V allow me lower maintenance time when coupled with XenDesktop.

It prevent me to locally install in a golden image unwanted software, that can't be published by RemoteApp or XenApp.

It allow processus intensive to run inside the machine, and not over in the terminal server.

Not the answer you're looking for? Browse other questions tagged or ask your own question.