App-V: More on App-V with Azure RemoteApp

Last April, we gave a little bit of information on the limited use of App-V applications with Azure RemoteApp (https://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:

 

Configuration options Pros Cons
Delivery method 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.
Disk (Cached)
  • Fast execution
  • App not dependent on availability of Content Source
Bloat – takes up image space (127gb limit)
Targeting User*

*Requires full standalone App-V infrastructure or Configuration Manager 2012 R2 or later

Global (machine) Pre-publish or target using Publishing server
  • Need to update your Azure image if you want to update the app.  (huge)
  • Takes up some space on image

* 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 . . . :)