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?
