One of the big benefits of App-V has always been that applications that needed certain kinds of remediation to work today were automatically dealt with.
I’m talking about apps that were developed without complete support for multiple users (or multiple tenants), or for apps that assumed systems that have no security protection to write to common locations.
We just sequenced them, and App-V automatically redirected any writes by the user to a safe location isolated to only that app. And it all roamed with the user.
Until version 5.0, where Microsoft decided that virtualized apps should behave more like non-virtualized apps. For the most part, the changes in 5.0 are welcome and make the job of preparing and distributing apps easier. But not for a log of older apps.
Primarily we are talking apps that were originally developed before UAC in Windows Vista, but also apps originally developed before people understood multi-user in Windows XP. These categories, unfortunately, include a whole lot of business apps developed by enterprises themselves. And in most cases the enterprise cannot update the app. Reasons for being unable include:
- No longer knowing where the source code is
- Developer is no longer at the company
- Don’t have the tools to even rebuild that old code
- Nobody wants to take ownership of it
In App-V 5, we really have a couple of big problems with these apps:
- The virtual app doesn’t roam all of the changes made by the user (the ARD).
- The app won’t work because of file or registry writes that now fail
You would still have those problems with a natively installed version, so App-V 5 isn’t breaking anything that way, but usually these apps worked great in App-V before.
A while back, I created a tool (AppRemediation) to take care of much of the first issue. I continue to find more things and need to update that tool at some point; it doesn’t get 100%.
So to better understand the problem, I performed some new testing. The accompanying chart shows the results of all of that testing.
Testing was done using a new version of my home-built AppVPersonalization tool that allows you to write to specific places and see if it works, or where the data is being written.
The testing consisted of making a package with files, registry items, and environment variables of different kinds inside the package. I tested both cases of having the program be located inside the PVAD folder and not (VFS’d). I also tested as an admin or standard user, and with the program elevated to a different admin user using RunAsAdministrator. The chart above shows what happens in the different scenarios.
I am hoping that Microsoft will continue to adapt the App-V product to improve it’s ability to make virtual applications easier for these older applications. If not, at least you know a little more about what to look out for.
