In recent blogs posts, I’ve been discussing the topics of how to leverage App-V for software delivery and management to custom Azure RemoteApp images joined to a hybrid collection. I’ve discussed what is supported and demonstrated a few walk-throughs regarding image setup and targeting. While there are many particular variances for each facet of configuration, I would like to shed some light on some recommended practices that we have found in the early stages of testing and implementing these scenarios.
Isolate ARA App-V Publishing Servers to ARA OU
Azure RemoteApp is a PaaS (Platform as a Solution) in the Azure cloud for non-persistent session-based applications. Like any other implementation of non-persistent session and VDI solutions, there will be provisioning and de-provisioning of Azure VMs depending on the amount of connected users combined with the particular subscription plan. Since the collection number will vary in size (as well as potential App-V client configuration changes) it is recommended that you create a specific OU (organizational unit) for the ARA images as it will allow you to control targeting and configuration more easily through GPO (Group Policy Objects) and GPP (Group Policy Preferences.)
When Possible, Leverage GPO’s for App-V Client Configuration
The App-V 5.1 client can have the vast majority of the client configuration controlled and modified through group policy. Controlling images via GPO allows for the extra insurance that newly provisioned ARA images will inherit the same client configuration the existing images also have. Group policy also ensures that changes in Publishing servers or Reporting servers will also properly propagate to the images.
Path Publishing Gives More Flexibility – Path Publishing Requires Integration Path
If the applications are not pre-published within the image, then advanced knowledge of the App-V integrated path to the application executable must be known in advance. This also means package information (Package GUID) must be known prior to targeting.
User Paths (%LOCALAPPDATA%MicrosoftAppVClientIntegration<GUID>Root<EXE>)
Machine Paths (%SYSTEMDRIVE%ProgramDataMicrosoftAppVClientIntegration<GUID>Root<EXE>)
As with other VDI scenarios, you could consider devising a custom launcher and pre-install that within the image.
Preserve Package Lineage (Sequencing) to Prevent OS Image Updates
One of the primary use cases for App-V streaming with ARA (be it pre-publishing or management server targeting) is the capabilities of streaming package updates for applications. This prevents the need to re-upload custom OS images when the application is updated. In order to take advantage of this feature, it is necessary to preserve the package lineage where the base package GUID always remains constant as packages are updated. In order to do this, you must always open the package for editing or upgrade in the App-V Sequencer as oppose to just simply re-sequencing a new version or “saving as new package.”
Use an App-V Reporting Server with Frequent Agent Upload Intervals
One of the most convenient features of the App-V infrastructure is the capability of configuring the client’s reporting agent to upload application usage data per user to a reporting service. This has been especially helpful for tracking package and application usage history in on-premises non-persistent environments and is just as valuable with Azure RemoteApp. It is recommended to customize reporting configuration on the images via GPO.
Have an RSDH Host in Azure IaaS for Testing Publishing and Targeting prior to ARA deployment
Prior to joining your ARA images to the existing VNET and domain, it is a great idea to have an RSH VM within Azure on the same VNET in order to test publishing and targeting in advance. That way you can confirm things are working right with regard to the entitlement and publishing of applications – especially if the App-V infrastructure is based in Azure IaaS.
As mentioned, these are CURRENT recommended practices. As App-V and ARA evolve (and they have,) so may these.
Last April, we gave a little bit of information on the limited use of App-V applications with Azure RemoteApp (http://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) This piqued the curiosity of many and over the past several months, we have been validating several scenarios involving the integration of App-V with Azure RemoteApp images within hybrid collections.
As you might have heard, Eric Orman – the Program Manager for Azure RemoteApp, announced at Ignite Australia that App-V *IS* supported with Azure RemoteApp within specific scopes. (https://channel9.msdn.com/Events/Ignite/Australia-2015/WIN336.) This is a significant development for companies that want more options for bringing their desktop applications to Azure as well as the birth of another chapter in the story of App-V in Azure. In the three months since that announcement, one of the most common question I have been getting is “Why? How is this significant?”
Why App-V for Azure RemoteApp?
I would say the three most important aspects about being able to use App-V with Azure RemoteApp are the following:
Keeps Custom Images Thin: Custom Images with Azure Remote App have to remain beneath the 127GB maximum for VHDs. In addition, the more applications pre-installed to ARA images translates to a longer upload time. Customers embracing App-V will have the ability to quickly bake an image for upload with minimal pre-publishing (or NO pre-publishing if leveraging path publishing the with the App-V Publishing Server or Configuration Manager.) In addition, App-V clients baked into Azure RemoteApp images can have those applications stream to memory using the App-V Shared Content Store rather than to disk also preserving permanent storage consumption on the ARA images. It is important to note that Premium Plus subscriptions coupled with a high-end storage back end (Azure Files) would be recommended for Shared Content Store use in ARA.
Allows for Streamed Application Updates: When a company decides they would like to move a LOB application to the Azure cloud using ARA, it involves an image upload. Periodically, the application may require maintenance and patching. Without a demand technology such as App-V, this would require re-uploading and re-provisioning of ARA images. With App-V, applications that have been sequenced for streaming can be dynamically updated to the ARA images without the need to re-upload any new custom images.
On-Premises, Azure IaaS, and Azure RemoteApp resources can share application Content Sources: If your organization is currently leveraging App-V and streaming content from content stores – be it on-premises or in Azure IaaS, these same resources can also be leveraged by your ARA-provisioned images as well.
Scenarios for App-V with Azure Remote App
When designing a strategy for delivering App-V applications with Azure RemoteApp, you will pretty much follow along the same lines as you would when you are designing App-V for any other target. The exceptions in the world of App-V involve the current existing gaps between the App-V IaaS (Infrastructure as a Service) and the Azure RemoteApp PaaS (Platform as a Service.)
The following table outlines the pros and cons of the different options for App-V delivery, application storage, and publishing and targeting with Azure Remote App:
Streaming (on demand from content server)
Application is always the latest and fresh
Possible first time latency upon initial application launch
Mounted (Pre-cached into the ARA image.)
Fastest 1st launch – all of the application assets are already present on the ARA virtual machine.
Potential Image Bloat – applications take up additional image space (remember the 127gb limit)
Primary Application location storage
Shared Content (Stream-to-memory)
App runs in memory of Azure RemoteApp instance
Eats memory and requires good connection to streaming (file) server where the app resides. Affects baseline.
Bloat – takes up image space (127gb limit)
*Requires full standalone App-V infrastructure or Configuration Manager 2012 R2 or later
Pre-publish or target using Publishing server
* In addition, User targeting also requires that the App-V application be pre-published via a path Publishing rule for the Azure RemoteApp collection.
More to come . . . 🙂
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. 😉
Last week, Chris Jackson appeared on RunAs Radio talking about about the benefits of Windows XP Migration (Yes, we still have customers who have not made the jump to a modern OS.) You can view the recording here: (http://www.runasradio.com/default.aspx?showNum=374)
It is an honor to be following my mentor and idol in this week's show where I talk with Richard Campbell on a variety of topics. Originally we were to discuss App-V, but as we dove into the VDI use cases, the conversation turned over to UE-V which is starting to take off!
Listen Here: http://www.runasradio.com/default.aspx?showNum=375
MDOP 2014 is now available:
In addition, Hotfix 4 for the App-V Client (no new server patches in this hotfix) is also available:
"Hotfix Package 4 for Microsoft Application Virtualization 5.0 SP2"
With this hotfix, we also recommend that you leverage new performance guidelines that was recently published on Technet:
"Performance Guidance for Application Virtualization 5.0"
My favorite two new features that has been added with this hotfix are the PreserveUserIntegrationsOnLogin and VFS Write Mode features! 🙂
Yes, it is time for another shameless plug. If you plan on attending TechEd North America this year (in warm Houston, Texas May 12-16) please make sure to clear your schedule on Thursday afternoon so you can see my presentation on App-V 5 Sizing: Planning and Designing a Highly Available, Scalable, and Resilient Management and Delivery System.
2:45 PM – Thursday May 15th
This presentation will discuss Microsoft Application Virtualization (App-V) 5.0 infrastructure design and lessons learned from a series of customer deployments. Topics will include
- Management and Reporting Server Design
- Shared Content Store Placement/Replication
- Publishing Server Placement
- Load Balancing Options
- Rapid Scale-Out Solutions
- Sizing Calculations
- Data Store Capacity Planning
Examples for using Windows PowerShell to automate and bridge product gaps are demonstrated. Use cases discussed include Published Desktops vs. Applications, VDI Density, and IOPS/Application Footprint Reduction.
The session will be recorded for Channel 9 but come on, don't you want to be there in person? Especially since we can head on over to the party afterwards! 🙂