Had a wonderful time @ workshop in Stockholm, Sweden this week. Transition from ThinApp to App-V 5.0 for a customer.
General playing around.
It’s been one and a half year since I’ve visited the subject of App-V 5.0. Since then MS released the latest and greatest App-V 5.0 SP2. What I find hilarious is that some of the release highlights are actually features that were suppose to work at the time of the core product release, such as:
- App-V 5.0 SP2 now supports folder redirection for local user appdata directory (oh, really?)
App-V 5.0 SP2 supports local %AppData% folder redirection. For more information see the Deploy the Client section of Deploying the App-V 5.0 Sequencer and Client.
- App-V 5.0 Package Upgrade Improvements
In App-V 5.0 SP2, you will no longer be prompted to close a running virtual application when a newer version is available. When an application is running, related publish operations will only run at a later time when the virtual environment is no longer in use. Un-publish operations for an application in use will also pend and will be processed at a later time.
Reading into the above lines and letting the knowledge sink into you only elevates degree of confusion. 😉
In past experience I remember that App-V 4.x wasn’t usable without hotfixes (apps breaking after updates, technology not allowing to virtualize several apps and the like). Same applies to this release. “Hotfix Package 2 for Microsoft Application Virtualization 5.0 Service SP2” don’t go home without it. @ the workshop when sales/tech guy from MS was confronted with the question he confirmed that the core product is not really “usable” without hotfixes. And by usable I mean – the whole list of issues described in KB from 1 to 5. Looks a lot like the list of issues version 4.x had. Update: And followed-up by HF3.
Generic Requirements and solution draft.
1) Improving app lifecycle
2) Streamline and simplify updates
3) Improve quality
4) Unify SCCM, Citrix XenApp, XenDesktop
Generic Solution sketch.
1) SCCM integration with App-V 5.0, apps to desktops/laptops are distributed through SCCM console, download and execute, not stream from distribution point, since the % of mobile workforce is high.
2) App-V Management Server for Citrix XenApp, XenDesktop, apps are pre-cached on RDS servers OR shared content store is used.
3) Same apps are used across the enterprise. Publishing methods differ.
4) For seamless update experience a new package will be created from ground zero each time to generate a unique ID for the package. It has been established that with version update seamless experience is not possible. A simple example of that is an app with shell extensions that hooks into explorer.exe – it will never update before the users relogs, which is not a scenario enterprises want to see. In RDS environment this issue escalates.
The downside of this approach is per-application user data that will not be migrated between version ID changes. Potentially “Microsoft User Experience Virtualization (UE-V)” should be considered for this if the existing User Profile Management solution doesn’t prove flexible (scriptable) enough.
Furthermore, it has been established that rollback of an application version that is globally published is not possible without PC restart. This undermines the appeal of using the app version model. I am truly surprised by this, but in my experience the same issue was present in 4.x.
Note: Apparently the “branch out” or “save as new package” feature has been cut out from app-v 5.0. This puts an additional heavy burden on the lifecycle of the apps, as instead of just installing a patch on top of the existing configuration – the whole configuration is re-made from ground zero each time – with this approach there is a risk of malfunction or bits and pieces of functionality falling off after, for example, a patch install.
Generic Technical solution sketch.
1) “System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager.” in place as a prerequisite.
2) Implementation of App-V 5.0 Management Server, Reporting Server, Publishing Server for Citrix XenApp, XenDesktop. One server box, 3 IIS websites, no HA in scope.
3) Two databases for App-V 5.0 – Management Database, Reporting Database.
4) GPO for Citrix XenApp, XenDesktop App-V Client Configuration.
5) Network share (SAN) for application files.
6) .ps1 script for pre-caching apps on RDS servers if Shared Content Store is not used.
7) Troubleshooting scripts for technicians – Repair-AppvClientPackage and Sync-AppvPublishingServer. Note: Self-service for users not possible if App-V 5 app is distributed to machine accounts (globally cached).
Notes & References.
App-V 5.0 still looks like a big scripting playground/challenge. For example – there are no special APIs SCCM uses for distributing app-v apps, it’s plain powershell.exe and scripts. There is no UI in the client application, well, there is, but it comes as a separate installation.
I’ve been really surprised by the level of detail for windows event logs from app-v systems (client, server, etc). Detailed and even with auditing for user access built in. SCOM people will rejoice.
It’s very much like XenApp 6.5 (amazing product) vs XenDesktop 7 (not so much). At this point there is no going back to 4.x and you either have to accept or move to another vendor (ThinApp comes to mind).