As an App-V 5 enthusiast and App-V 5 trainer I virtualized almost all my applications and run them locally. This made it so easy to join the Windows 10 Insider Program and run the latest build on my production laptop. If something goes wrong, I easily revert to a previous build and import my App-V applications again.
On the 6th of April of 2016, Microsoft announced Windows 10 Insider Preview Build 14316 which I directly installed. After the upgrade I didn’t find any issues, different then described in the known issue list released by Microsoft (https://blogs.windows.com/windowsexperience/2016/04/06/announcing-windows-10-insider-preview-build-14316/). I did notice that one of my virtualized apps (App-V) crashed at launch, but because another app did launch, I thought it had to do with that specific package.
Two days later I noticed that another virtualized app, didn’t work as before. And then it struck me. App-V would be integrated in the upcoming Redstone release. So did Microsoft added App-V in this build already? I found that my App-V client was removed, but I couldn’t find an App-V feature. After contacting my friend Ryan Bijkerk (MVP), I tried to enable App-V through PowerShell, but still no luck…
When I started to use Windows 10, back in June 2015, I downloaded the Insider Pro build. Windows 10 Pro doesn’t have App-V integrated in the build and it doesn’t allow an App-V client to install.
Basically Microsoft only allows App-V on the Enterprise version of Windows 10. But why didn’t I notice this directly after upgrading to the latest build?
The answer I find quite disturbing…
During the build upgrade, the binaries of the installed App-V 5.1 client have been removed, the folder itself is still available but empty. Looking in Programs and Features, the App-V client is removed, but the client seems not to be uninstalled in a proper way! This can be seen when opening the registry. I noticed that almost all of my registry keys are still there. Even the version key is this available and giving me version: 188.8.131.52. The PackageInstallationRoot key still points to %programdata%\App-V and looking into my Start Menu, all of my App-V application shortcuts are available and still “working”!
Because the client binaries are not available, the packages weren’t working as they should. A good example is the Microsoft App-V Client UI which can be downloaded as an App-V package from Microsoft. I was able to launch the application, so it looks like App-V is working. But when I tried to open “Virtual Apps”, the UI showed me nothing… Not even the App-V UI application itself.
To summarize my findings after the Windows 10 upgrade:
- App-V registry for 99% intact
- InstallPath key is removed!
- SubSystem\Modules & Modules64 still have references to “C:\Program Files\Microsoft Application Virtualization”
- PowerShell module App-V is missing
- PowerShell cmdlets are missing
- Enable-AppV doesn’t work
- Installation folder (C:\Program Files\Microsoft Application Virtualization) still there, but empty
- App-V shortcuts and EntryPoints are still available
- App-V apps crashes at launch or not working as they should work
- e.g. App-V UI launches, but not able to find any App-V app
- e.g. I was able to see the splash screen of Adobe Reader, but then it closes directly.
As I was still running Windows 10 Pro, I thought that maybe after an upgrade to Windows 10 Enterprise, I could enable App-V and test again. So I upgraded my laptop to Windows 10 Enterprise, which is a sweet process as described in my previous post. And after the upgrade I was able to open PowerShell and use the command “Enable-AppV”. Although enabling doesn’t give you any response in return, I could see that the App-V service was running. Also the App-V cmdlets were available and gave me all my previous App-V applications! YEAH! It works!
Time to launch my apps…
What? So there is still a reference to the previous installation location? Lets quickly copy AppVEntSubsystems32.dll to its previous location, if…. it’s available. But it isn’t! After the installation of the App-V feature (during upgrade to Windows 10 Enterprise edition), only the AppVEntSubsystems64.dll is installed. So what’s next? Clean the registry?
I tried to disable the App-V client by running “Disable-AppV” in an elevated PowerShell prompt and renaming the App-V registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. So far, so good. But when I tried to enable App-V again, PowerShell returned error that it was unable to find the file specified. The App-V module apparently has a requirement on the registry key, instead of creating a new key…
So how to fix this App-V issue?
Best way is to prevent this situation. If you know you’re about to upgrade from a Pro Edition and you’re running App-V, upgrade your OS edition first! When you’re running Windows 10 Enterprise, you can easily upgrade to 14316 and enable App-V the normal way as described by Aaron Parker on his blog. When I was reproducing my findings, this was one of the tested scenarios and a “normal” upgrade works fine.
But what to do if you’ve already upgraded to the latest Windows 10 build and from that point you’ve upgraded to Windows 10 Enterprise?
To enable App-V after the upgrade to 14316 and the upgrade to Windows 10 Enterprise the following steps are needed:
- Remove App-V apps
- First Enable-AppV
- Then Unpublish all apps and remove them:
Unpublish-AppvClientPackage -name * | Remove-AppvClientPackage
OR if published global/machine-based:
Unpublish-AppvClientPackage -name * -global | Remove-AppvClientPackage
- Disable-AppV again
- Remove Registry key: HKEY_CLASSES_ROOT\AppV
- Remove all references to C:\Programdata\app-V from the registry
- Remove all references to C:\Program Files\Microsoft Application Virtualization from the registry
- Remove App-V folder in user folders:
- Remove the App-V packages manually
- Take ownership of the package folders in C:\Programdata\AppV
- Enable inheritance on each Package Version folder. (By default the permissions on the package version folders are set by the App-V client and have inheritance disabled. This might result in a situation where the End-user doesn’t have permissions to remove the files and folders).
- Make sure you have enough permissions on the folders, by granting your username full control permissions on the package ID folder
- Remove all files and folders under C:\Programdata\AppV
- You could remove all App-V shortcuts, but most likely you want to run the same apps afterwards, so this steps is not necessary.
- REBOOT your computer to make sure no files are loaded anymore
- After the reboot, Enable-AppV via an elevated PowerShell prompt
- Add and publish your apps, and you’re done!.
Request to Microsoft for next build
I think integrating App-V into Windows 10 is a great step, but also a necessary step looking forward to e.g. Project Centennial. I do understand that Microsoft wants to limit the App-V feature to Enterprise edition users only. But by installing the upgrade, the End-user might lose an important application and of course all App-V applications published on that device.
Microsoft should be able to perform a check if App-V is installed on the device, before starting the upgrade. If App-V is installed, Windows Update should notify the End-user on what will happen when the user agrees with the upgrade to the latest build.
- If the End-user is running Enterprise edition, the End-user need to know to enable App-V after the upgrade, else the applications might not launch or will not work as expected.
- If the End-user isn’t running Enterprise Edition, Windows Update should notify that the End-user will not be able to use App-V and all published apps anymore. The End-user then should have the option to postpone the upgrade or upgrade to Enterprise first.
Also I think; if the End-user decides to upgrade Windows 10 Pro edition to the latest build, Microsoft should ensure the upgrade removes the current packages, shortcuts & all App-V entrypoints. This is required to make sure no App-V package footprints are available, if the App-V client isn’t installed.