This will most likely need to be tested for each version of a potential App-V 5 upgrade, but lets clarify the issue.
When upgrading the App-V 5 client there are some nasty behaviors that cause grievances among users. Since App-V 5 is a middle-man there has been a personal hope that Microsoft would have addressed the upgrade path to offer the same seamless and smooth experience that for example Internet Explorer, Office or general Windows components offers.
What’s the issue?
- Install App-V 5 version old
- Deploy a few applications, get the users productive
- Version new of App-V 5 is released and of course this resolves some issues you have experienced
- Manually or in an automated manner install the new version.
All running virtual applications will be terminated
After the upgrade and until a restart has been completed no applications can be started
The impact of running the App-V 5 version new upgrade when a user is active on the machine is rather frightening and will decrease the end-user productive. Terminating active virtual applications would stop most change management, but halting productivity until a reboot is of course a deal-breaker.
Depending on your scenario this issue might be able to workaround using processes alone, however in a road-warrior type of world where devices are laptops and either used or offline the ability to control the upgrade path to minimize user friction is of course limited.
Since two thirds of the worlds corporate Windows client estate is managed by Configuration Manager there are certain abilities to ensure that something is not installed while a user is active on the client. The client would become aware of what needs to be executed, download the necessary files and then would not start the install until the following condition is met;
The issue that still stands is that even though the new App-V 5 version new is installed the user can not start the virtual applications (or interact with the client) until the device is restarted.
It seems that the to avoid a scenario where the device drivers loaded into the system should not be different than service running the upgrade will stop the service. There may of course be issues, however running with this version difference (services vs drivers) within a limited time frame is a minor risk if it allows a gradual upgrade path and setting a new standard baseline for the App-V 5 client version
So, run the App-V 5 upgrade;
appv_client_setup.exe /ACCEPTEULA /CEIPOPTIN=0 /MUOPTIN=0 /ENABLEPACKAGESCRIPTS=1 /AUTOLOAD=0 /q /norestart
Start the App-V 5 client service:
net start appvclient
The user can then restart in their own time and hopefully everything should be running without any major hiccups. Obviously – this is very unsupported.