Whether it is integration with XenApp, XenDesktop, PVS, or UPM, App-V 5 is the recommended application virtualization and streaming model for Citrix Session and VDI environments. I work with a lot of customers who leverage App-V in this capacity and they have been asking me to maintain a “living post” that contains links and references to Citrix and App-V 5 integration resources.
So with help of App-V 5 SEE John Behneman, (you may recognize him from the official App-V support blog) below is a collection of Citrix KB and documentation links related to App-V 5.0 when integrated with Citrix technologies:
(Page will be updated)
Citrix Official App-V 5 Version Support Matrix for XenDesktop or XenApp and App-V 5.0
Choosing an application and desktop delivery method
XenDesktop 7.5 and XenApp 7.5 Features and Entitlements
Reviewer’s Guide XenDesktop 7.5
Citrix App-V 5 Integration: Internals
User Profile Management and App-V 5 – Required UPM exclusions for App-V
Random Application Fails When Using Standard Image Mode with the “Write Cache on Target Hard Disk” Option
Troubleshooting App-V 5
Citrix EDocs on App-V XenApp 6.5 Publishing: Note that they redirect you to how to publish App-V 5 apps with Server 2012 RDS:
Citrix EDocs on App-V 5 XenDesktop 7.1 Studio Publishing Integration:
App-V 5 and Citrix Integration
Microsoft-Citrix Virtual Desktop Infrastructure Technical Whitepaper
App-V: A Configuration Template for Deploying to Stateless RDS Clients on Citrix Published Desktops with Citrix UPM for Profile Management
Last year, I wrote a blog post on registry staging in App-V and how it can affect initial publishing times – particularly on VDI (http://blogs.technet.com/b/gladiatormsft/archive/2013/09/25/app-v-on-registry-staging-and-how-it-can-affect-vdi-environments.aspx) and many people wrote me to tell me it was very helpful in reducing publishing times. This was especially important especially for those non-persistent VDI and RDS/XenApp environments.
A colleague at Microsoft recently reminded me of an alleged “controversy” regarding our registry staging configuration recommendations within current recommended practices that has grown out there in the webosphere. As App-V 5 has changed a lot with service releases and hotfixes over the last two years, have my recommendations changed? Well . . . it depends.
After Service Pack 2 and definitely after Hotfix 4 for Service Pack 2, App-V 5 has improved in terms of publishing time and has been adjusted to work better with user environment management solutions and non-persistent environments.
When questioned about whether the previous blog article is valid or not still post App-V 5 SP2 HF4, customers refer to the TechEd 2014 presentation by Login VSI (https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/WIN-B362#fbid=) on App-V 5 performance in VDI environments. [This was an excellent presentation by Login VSI and prior to the presentation, Ment van der Plas and I discussed the findings prior to the presentation.] Customers are basically asking me, “Are they right or are you right?”
We are both right – within the right context. My article discussed how disabling background registry staging would reduce the time to complete publishing. The net effect of this means that registry staging would be shifted to on-demand which means the staging begins upon first launch. In essence, we are punting – to use an American football analogy. However, there are no free lunches in nature – and that includes computer science. So to decrease the publishing time, we are moving the burden to the application’s first launch. Could this cause a performance hit on launch? Yes – especially for applications with large registries. Turning back on background registry staging will allow the registry staging to occur prior to first launch which reduces overhead on the application initial launch. This is why Login VSI is right to say this value has a negative effect on first launch.
Am I wrong in the sense that I should have specifically pointed this out more clearly in my article? I will concede that. 😉
We had quite a few breakout sessions on App-V at TechEd North America this year! If you were there and were not able to attend all of them or missed TechEd altogether, you can view the recorded sessions here on Channel 9:
My Presentation 🙂
Sizing App-V 5.0: Planning and Designing a Highly Available, Scalable, and Resilient Management and Delivery System
Then we have an excellent presentation by Briton Zircher on deploying Office 2013 with App-V 5:
Everything You Need to Know for a Successful Microsoft Office 2013 App-V Deployment
You also will want to see Project VRC's presentation on their independent performance analysis of App-V 5.
Project Virtual Reality Check: Microsoft App-V 5.0 Performance, Tuning, and Optimization (App-V PTO)
Are you thinking about or planning to deploy App-V 5 with Citrix XenDesktop and studio integration? You will want to see this:
Deploying Microsoft App-V 5.0 and Citrix XenDesktop 7
New to Intune? Want to understand how applications are managed with Intune? Want to know your App-V options with Intune, check out this presentation:
Application Management with Microsoft System Center Configuration Manager and Windows Intune
Finally, my favorite of the event – done by the Virtual Vibe guy himself -Thamim Karim:
The Circle of Life for an App-V 5.0 Package: From Sequence to Termination
Ever since the summer (TechEd) I have been promising customers we would have a white paper coming on this. Well, we have just published a new App-V 5.0 and Citrix
integration overview white paper.
Whitepaper Title: App-V 5.0 and Citrix Integration overview
Abstract: This whitepaper is designed to provide administrators with guidance for combining Microsoft’s App-V 5.0 and Citrix solutions. It discusses the benefits of an App-V 5.0 and Citrix combined solution, and includes recommendations for Citrix images, App-V cache management, App-V management with Citrix, and other factors that impact user experience and administrative effort. Whether you are using XenApp or XenDesktop, this paper will be a must read!
It is available to download here
UPDATE: PLEASE READ THIS AFTER READING THIS ARTICLE: http://blogs.technet.com/b/gladiatormsft/archive/2014/08/22/app-v-5-revisiting-registry-staging.aspx
The App-V 5.0 Virtual Registry is isolated for each application (or virtual environment when using Connection Groups.) With this release, there is a better view into the Virtual Registry subsystem. In fact, the App-V 5 virtual registry is divided into two main parts: The Virtual Registry itself (VREG) and the registry staging subsystem.
The APPV package file is a human-readable set of assets. As many of you may have already figured out, you can simply rename the file to a ZIP extension and browse it from within Explorer. Some of you have discovered the hard ay that you destroy the package once you try to modify it this way. Yes – it is a mechanism for VIEWING ONLY. If you have had a chance to do this, you have probably noticed that each APPV package contains its own registry hive file (.DAT)
This is where all of the registry assets captured during sequencing reside. When a package is being published, part of the overall package publishing includes the staging of the registry. Both registry machine data and user data will occur. The staging allows the virtual registry not just to be made available, but to also set up the opacity configuration and other important relationships with the native registry. This is to ensure that the applications have a consistent view of both. If you launch REGEDIT.EXE inside one of the App-V bubbles, you will see this converged registry.
If you are using a traditional App-V 5 server-based infrastructure, you might find yourself in an interesting situation. When synchronizing with a publishing server for the first time, all of the publishing blocks for all of the applications targeted to that machine or user will be passed down and each application will be published on the App-V client either to the user or globally depending on the target methodology. In addition to shortcuts, file type associations, and other extension point registrations, there will also be the staging of the virtual registry occurring in the background. This staging can produce some significant overhead during these sync and on first launch – and when many applications are being used (as well as applications with thick registries) this overhead can delay availability of those applications. This can be especially critical when using pooled VDI scenarios incorporating SCS (Shared Content Store) because you also have the additional overhead of sparse file creation.
Registry staging occurs upon the initial launching of a package if it has not been completed. It extracts the .DAT file from the APPV Package Root (which was copied from the APPV file) and then copies it again over to %PROGRAMDATA%MicrosoftAppVClientVREG. It will then mount the hive file through a background thread and recreate it in the package registry location inside the native registry. Registry staging will occur for both individual packages and connection groups. The time it takes depends on several factors including the size of the hive.
The native registry locations where these are stored are:
Package Registry Staging: HKLMSoftwareMicrosoftAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKLMSoftwareMicrosoftAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
Package Registry Staging: HKCUSoftwareClassesAppVClientPackages<PACKAGE_GUID>Versions<VERSION_GUID>
Connection Group Registry Staging: HKCUSoftwareClassesAppVClientPackageGroups<CG_GUID>Versions<VERSION_GUID>
You will also be able to tell if the registry staging for a specific application has been completed as there will be an additional key called RegistryStagingFinished (beneath the <VERSION_GUID> entry.) Registry staging can occur in the background or on-demand. In VDI environments, we are seeing heavy CPU utilization with background staging in some circumstances. You can gain significant improvement by switching to on-demand staging. You can do this by adding the following registry value in the HKEY_LOCAL_MACHINESoftwareMicrosoftAppVSubsystem key
Data Type: DWORD
This is showing to improve first launch experiences in App-V 5 VDI environments.