App-V: On Targeting Azure RemoteApp Images with the App-V Management & Publishing Server
There are two types of Collections with Azure RemoteApp: A Cloud Collection and a Hybrid Collection. App-V requires that the client must exist on domain-joined machines in order to be supported. Azure RemoteApp Custom Images can be part of a Hybrid RemoteApp collection where the images are joined to the local domain. This now entails App-V and Azure RemoteApp the possibility of integration with the App-V Management & Publishing Server using a cloud-based or on-premises App-V Infrastructure scenario:
Cloud-based App-V Infrastructure: This is where the App-V Management, Publishing, and Content Sources are based in Azure IaaS (with the content being also available with extended Azure PaaS services as well.) In this scenario the Hybrid Collection must be associated with an existing VNET that also contains the App-V back-end resources. This scenario also requires that the Azure RemoteApp clients and the App-V infrastructure are joined to the same local domain either hosted in Azure IaaS or via the forthcoming Azure AD Domain Services (In preview - https://azure.microsoft.com/en-us/services/active-directory-ds/) The Azure RemoteApp images are pre-configured for the Publishing Server or controlled via GPO (group policy.)
The Cloud-based App-V Infrastructure can easily service both cloud-based resources (RDSH in Azure IaaS, Azure RemoteApp) as well as traditional on-premises clients (via the web, through Site-to-Site VPN’s, or ExpressRoute.)
On-Premises App-V Infrastructure: This is where the App-V Management and Publishing Servers are based in an on-premises network servicing primarily on-premises clients. In this scenario the Hybrid Collection must be associated with a VNET attached and routed to the on-premises App-V infrastructure through a site-to-site VPN or ExpressRoute. The Azure RemoteApp images are joined to the local domain and pointed to the Publishing Servers via pre-configuration or GPO. In this scenario, it is recommended to still leverage Azure-based content sources for content even though streaming over the on-premises connection would be possible – but not recommended.
Walking Through the Process:
For the sake of this conversation, we will assume that an existing App-V 5.1 infrastructure has already been provisioned, be it cloud-based or on-premises. Obviously, before you would start the process of setting up a custom image, you will want to make sure you have this in place.
1.) Create a custom operating system image that has the App-V RDS 5.1 Client installed - then import image into Azure RemoteApp. This is an oversimplification of a process that is further outlined in a previous blog post on configuring and preparing an image for use with App-V and Azure RemoteApp: https://blogs.technet.com/b/gladiatormsft/archive/2015/04/29/app-v-on-app-v-applications-hosted-in-azure-remoteapp.aspx.) You can pre-configure the client and even pre-publish some applications prior to upload. I would advise skipping the client pre-configuration and instead, leverage AD GPO’s to configure the client.
2.) Create an Azure RemoteApp domain-joined (hybrid) collection and leverage the OS image as the template image for the collection. When you go to join the domain, you will want to join the domain to a specific OU (organizational unit) within your local domain. It will be much easier to administer and control the configuration of your ARA images if they are contained within a specific OU. NOTE: This step is massively simplified here in the explanation. More specific ARA information on joining Hybrid Collections can also be found here (https://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-hybrid-deployment/) 
3.) The image upload may take a while to provision. Once the image has been provisioned, the status will show as ready. 
4.) Once the images have been provisioned, you will start to see computer objects appearing in the OU you specified for the domain join. 
5.) At this point you can begin to configure a Group Policy Object and link it to the OU for the ARA images. 
Within the GPO, you can leverage the ADMX templates for App-V via the MDOP ADMX template download package (available here: https://www.microsoft.com/en-us/download/details.aspx?id=41183) to control the App-V 5 client settings including App-V Publishing server targets, shared content store mode, scripting configuration, etc.
6.) Now the interesting part begins: The App-V management console allows you to target packages to user AD (Active Directory) groups or machine AD groups. When it comes to targeting groups, GPO’s only allow you to control local group membership. As a result, the targeting options available for machine groups that affect ARA machines is pretty much the Domain Computers Group. However, if you wanted to target the ARA images for machine groups (global publishing) you can effectively use the Domain Computers group coupled with the OU configuration for the specialized publishing server. User Targeting is a more flexible option as there are no restrictions with regards to the non-persistent provisioning of the ARA images. 
In this example, I have targeted both the Domain Computers machine group as well as a custom user group within the App-V Management Console.
7.) Publish App-V apps in ARA (using path option or pre-published discovery.) Within ARA, you can publish applications by querying the Start Menu of the image or by using Path Publishing. App-V applications will not show up via a Start Menu query unless they have been pre-published globally in the image. For this reason, it is better recommended to Path Publish the App-V applications. This requires juuuuuuust a bit of a workaround. If you plan on publishing an App-V application by path, you will need to be able to know the actual integration path to the executable in advance.
For machine-targeted (globally published) packages, they will begin with:
%SYSTEMDRIVE%\ProgramData\Microsoft\App-V\Client\Integration\<Package_GUID>\Root
For user targeted (user published) packages, they will begin with:
%LOCALAPPDATA%\Microsoft\App-V\Client\Integration\<Package_GUID>\Root
If you do not know the package GUID from sequencing, you can easily retrieve it from the package details within the App-V management console.
Any additional path information beyond the root folder must also be obtained in order to complete the path. Since the APPV format is a ZIP format, you can easily view this information within the APPV package file itself.
8.) Once you have this information, you can proceed to publish the App-V applications n the Azure RemoteApp publishing console. 
9.) Upon logon using the ARA RDP client, you should then see your App-V applications appearing just like any other normal application. 
Comments
- Anonymous
March 25, 2016
Great blogpost. At the moment I'm also looking at the possibility to deliver our App-V5 applications with ARA, so I used one of your other blogposts to create a custom 2012RDS VHD with an AppV5 client and some apps which I delivered though ARA, works great.
We’ve got almost 95% virtualized (about 400 apps), and it would be great if we could distribute them to all kind of byo or cyo devices. We want also support our on premise clients of course. Currently we’ve got a full 5.1 infra on premise. If I understand correctly, we could create a reference VHD for ARA and point to our on premise infra. Although this would not be recommended (latency etc). So you say, build a 5.1 infra in Azure and let the reference VHD point to this backend (on the same VNET). Because those VHD’s can be max 130Gb or so, I presume configuring Shared Content Store Mode would be a good idea?
I’m just wandering, what about those LOB applications which need resources from the on premise network (let say an oracle database, or something on the network) which we cannot bring to the cloud? Would this cause an issue?
Another question, if we would like to use Remote desktop too, could this VHD point to the same app-v backend in the cloud too (all on the same VNET), or should I create a separate one on an other VNET?
One last question about this blogpost itself, what’s the use of targeting to users if you’re going to use ARA? You’re going to create collections, so all published apps will be available. Or are you already talking about the new user targeting feature in ARA which is coming soon?
Thanks for taking time to answer!