Udostępnij za pośrednictwem

App-V: Current Recommended Practices for using App-V with Azure RemoteApp

  • Artykuł

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%\Microsoft\AppV\Client\Integration\<GUID>\Root\<EXE>)
  • Machine Paths (%SYSTEMDRIVE%\ProgramData\Microsoft\AppV\Client\Integration\<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.