While I will admit that I thought about this possibility, I never would have written about it unless I found a customer actually doing this.
I met them in a recent training class, and here is their story.
For most companies, delivering applications as App-V virtual apps is one of many ways that they deliver applications. They might also use imaging, they might use an electronic delivery system (such as Configuration Manager, Marimba, or BigFoot), they might use application layering (UniDesk/Citrix App Layering, Cloud Volumes, or Liquidware Labs). Heck, they might even be using Group Policy or “sneakernet” to deliver apps.
If you are really into App-V, you likely first try the app with App-V and then fall back to one of the others if there is an issue. If you are self-learned on App-V then maybe you start with one of the others and fall back to App-V when that one has a problem. Let’s face it, no delivery method is foolproof for every app.
Or is there one?
With the creation of App-V, Microsoft provided a method that we can leverage with App-V to pretty much install anything. The AddPackage script is executed by the AppVClient windows service on the endpoint, making it capable to install software in the local system context even when the end-user does not have administrative privileges.
So this company just packages everything in App-V first. If there is a problem, or the app is just clearly unsuitable for App-V, they create a dummy package that just has one dummy registry item (Valid App-V packages do not have to have a content file, but must have a virtual registry file so there has to be at least one virtual registry item.), a silent/passive installation script file, and an AppPackage script that runs the script file. This is then assigned to users via the App-V Server just like any other app.
So why don’t they use another method? Because they are not an enterprise scale company. They don’t use Configuration Manager. This is in part because ConfigMan is expensive, but the real issue is that they just don’t have enough IT staff to become proficient in it also. They are never going to learn any kind of App Layering either. They also almost never update a user’s desktop image after deployment.
So this is what they do. Images are always just a base OS images. OS Patches are handled via WSUS. Everything else goes out from the App-V server, either as a virtualized application or a package script to install natively. And it all works. 100% delivered via App-V!
