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