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.
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: http://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:
For user targeted (user published) packages, they will begin with:
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.
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 . . . 🙂
With the release of Azure RemoteApp, Enterprise customers can now move their non-persistent RDS session-hosted applications from the on-premises data centers into a hosted cloud – with the Azure platform providing all of the necessary image provisioning and updating services. With Azure RemoteApp, you can use gallery templates or your own custom image. In addition to your own custom image, you can leverage virtual applications using App-V. With App-V, you can reduce the size of your custom image uploads by streaming the content on-demand.
Right now, App-V support in Azure RemoteApp is limited and licensed to only hybrid collection deployments. This is due to the current licensing requirement of App-V needing to be on domain-joined computers. While you could use a cloud collection to test a virtual application, in order to take advantage of the image reduction features of App-V with Azure RemoteApp – and to have full supportability and license compliance, the implementation within Azure RemoteApp would need to be joined to a domain within a hybrid collection deployment using a Site-to-Site VPN.
Setting Up Azure RemoteApp Images
Before you set up your image for Azure RemoteApp, you will need to first set up your Azure RemoteApp Subscription at https://www.remoteapp.windowsazure.com/. In addition, you will need to set up Azure PowerShell on the machine where you will be uploading the image. You can download Azure PowerShell here at the following link:
There is also existing guidance for configuring a custom RemoteApp image for uploading:
Make sure you follow everything specified in the documentation and no steps are missing when configuring the VHD including disabling encryption and ensuring the partitions are MBR-based. For App-V considerations there are some additional steps that you will need to ensure are included with regards to configuring and preparing the image.
Configuring App-V Client and Pre-requisites
- In Server Manager, make sure .NET 3.5 and 4.5 Services are configured as features for Windows Server 2012 R2.
- Install the most recent App-V 5 Client.
- Install the App-V Client pre-requisites here: https://technet.microsoft.com/en-us/library/jj713458.aspx
- Configure the App-V Client as required (script enablement, etc.)
After the App-V Client has been configured, you will need to add and globally publish your virtual applications using PowerShell. You can do this using the built-in App-V PowerShell Cmdlets referenced here: http://technet.microsoft.com/en-us/library/dn508409.aspx. Whether you are using hybrid or cloud deployments, only globally published applications will fully survive the generalization (as well as picked up by the RemoteApp provisioning) so it is currently a hard requirement.
Testing and Final Preparation
You should test and verify your applications within the image prior to uploading your image. Finally, before generalizing your image with the SysPrep tool, you will need to perform a current workaround that involves an issue with App-V and SysPrep. You will need to stop the AppV Client Service and delete the local VFS Folder under Local AppData (%LOCALAPPDATA%MicrosoftAppVClientVFS.)
Also remember, if the image you are uploading is drastically behind in operating system updates, it will further delay provisioning after uploading.
The last thing you will need to do is generalize the image using the command line:
C:WindowsSystem32SysprepSysprep.exe /generalize /oobe /shutdown
Creating the Collection
You will need to create an Azure RemoteApp collection to house the image and published applications from that image. You can use this quick reference for the details: http://azure.microsoft.com/en-us/documentation/articles/remoteapp-create-cloud-deployment/
In order to upload your custom image containing your virtual applications, in the collection dialog, you will need to click “Template Images.” You will then specify to upload a RemoteApp template image:
After you have given the name and location, it will take you to the next screen where you will download a PowerShell script that you will use to upload your VHD to the correct Blob.
Once you download and run the command from an elevated Azure PowerShell session, it will mount, validate, and fixup the image and then proceed to thoroughly check the integrity and then finally uploading to Azure.
While the image is uploading, the status will remain “Upload pending.”
Once the upload is complete, you can then apply the template image to a collection.
Once the image is associated with a collection, the provisioning will begin. This may take a while. It will show a status of “Provisioning” until it is finished fully prepping the image and parsing for applications.
Once the applications become available in the “Publish RemoteApp Programs” screen, you will see that the AppV programs will show alongside the native applications. These application were queried upon the provisioning that occurred after the collection was created. The AppV applications will be the ones originating from the AppV Client’s PackageInstallationRoot (which by default is C:ProgramDataAppV.) Once the applications have been published and user access has been configured, you can then download the Azure RemoteApp RDP client from:
Once you download the ClickOnce application, you will be prompted with a wizard upon first launch:
The first item you will need to do is supply the appropriate credentials. You will need to supply a corporate account or an MSA.
After you have been authenticated, you will see your published applications (both native and virtual applications) assigned and published to the user. You can then begin to test virtual application behavior in Azure RemoteApp.
In App-V in general, the Content Store (also referred to as the package source or streaming source) is the most critical in both traditional streaming (stream-to-disk) scenarios and Shared Content Store mode clients (stream-to-memory.) Traditionally, Microsoft recommends placing Content Stores as close as possible to end user devices when possible leveraging on-premise technologies such as DFS-R to for replication and location. But what about those customers who are looking to leverage cloud services for App-V content for either:
Disaster Recovery/Business Continuity solutions
Part of an overall strategy to migrate from on-premises resources to hosted cloud services.
When looking to deploy Content Servers in Azure for application streaming, it is important to plan for regional proximity with a mechanism for replicating uniform copies of the App-V content just as you would have done in an on-premises environment.
Why Azure Web Roles can work for App-V Streaming
The App-V Content Server in the cloud is simply a hosted web server virtual machine with attached storage configuration and a corresponding set of cloud services configured to allow downloading of APPV package content via HTTP or HTTPs. This package source requires no additional management (other than security and MIME configuration for .APPV files) of the static package content and is simple to deploy and scale out as needed.
Cloud Services and Endpoints
Assuming you have established an Azure subscription, setting up the necessary services is essential however, a lot of the minor configuration will vary depending on how these cloud resources are integrated within your existing App-V infrastructure. For the sake of example, I will use the scenario of deploying a Content Server to the cloud for the purposes of providing cloud-based content.
In most cases, the order will be to:
Create the Cloud Service – to allow access to hosted Content VM's over the Internet
Create the Storage Account to store the VHDs.
If you want to learn more about Storage Accounts, the reference “What is a Storage Account?” http://azure.microsoft.com/en-us/documentation/articles/storage-whatis-account/ is a good start especially when understanding storage redundancy options.
Create the Virtual Networks
In addition, you will be leveraging external-facing Virtual IP’s (Public IP) an internal DIP, and an Azure Traffic Manager resource
Why do I need a Cloud Service, Virtual Network, VIP and DIP?
If you want to learn more about Cloud Service, Virtual Network, VIPs and DIPs, I highly recommend Young Chou’s (My buddy in DPE from Charlotte, NC) article on Windows Azure Infrastructure Services IP Address Management – at: http://blogs.technet.com/b/yungchou/archive/2014/03/17/windows_2d00_azure_2d00_infrastructure_2d00_services_2d00_ip_2d00_address_2d00_management_2d00_part_2d00_1_2d00_of_2d00_2.aspx
In addition, the following tutorials can walk you through the process:
How to Deploy a Cloud Service: http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/
Content Management and Upload: http://azure.microsoft.com/en-us/documentation/articles/web-sites-deploy/
VM Creation and Sizing
Content Servers in Azure can be any operating system supported for web services. In the case of Azure, it will be Windows Server 2008 R2, 2012, and 2012 R2 SKUs.
For Virtual Machine sizing purposes, it is recommended to align and plan capacity for Azure VM’s using the same guidelines for on-premises using the official App-V Sizing document: https://technet.microsoft.com/en-us/library/dn595131.aspx
I have found in my early testing with customers and myself, it is economical to scale out Standard Tiers using A1 or A2 series VM’s and load-balance as needed since we are only serving up web content essentially. I’ll also explain another reason when diving into the streaming protocol selection.
Internet Facing Scenarios
For App-V client retrieving content from cloud-based servers, there are three important factors to consider:
For Azure Web Services, streaming APPV package content from the cloud is quicker using HTTP although the tradeoff of non-secure transmission may not meet all security requirements of some organizations. For those organizations, additional security of the cloud services for HTTPS communications will be required. Also you will need to flip the App-V clients to use single-range HTTP communication as opposed to multi-range.
BranchCache is Your Friend
To ensure fast, optimal delivery for on-premises App-V clients, and to provide the best experience possible for devices that may use the stream-to-disk scenario with clients – it is recommended to have the clients configured for BranchCache in either hosted mode or distributed mode. In addition, it is NOT recommend the use of Shared Content Store mode for on-premise clients due to limitations of offline access and heavy latency with the single-range HTTP protocol. Potential latency that may come with Single-range protocols would be offset and optimized by use of the BranchCache protocol. In addition, BrancheCache can reduce traffic overall to the cloud.
In addition to security content transmission, you will want to secure access between your on-premises clients and the Azure-hosted cloud services. If the on-premises domain for which the App-V Client’s belong is federated with an Azure AD domain, you can secure access through individual users. Otherwise, you will need to leverage an alternative solution for restricting access.
Whitelisting IP Address Access
You can restrict access by IP address range in at least two ways. You can leverage the existing IP and Domain Restrictions feature in IIS. This will also work to secure Azure App-V Content servers to only allow access to IP addresses and domains that you have specified in a whitelist. https://technet.microsoft.com/en-us/library/cc731598%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
You can also secure access to the cloud endpoints using ACLS. http://azure.microsoft.com/en-us/documentation/articles/virtual-machines-set-up-endpoints/
Regardless of how the web service is secured on the back end. For streaming seamlessly, it is also recommended to add the URLs of the resources to the App-V Client’s Intranet Zone policy.
UPDATE: 10/21/2014: The MVMC 3.0 is now released with P2V functionality restored.
The Microsoft Virtual Machine Converter 2.0 is available! The Microsoft Virtual Machine Converter provides a supported, freely available, stand-alone solution for converting VMware-based virtual machines and virtual disks to Hyper-V-based virtual machines and virtual hard disks (VHDs).
There is also a release of an update to the Migration Automation Toolkit (MAT). This is a collection of PowerShell scripts that will automate conversions using MVMC. You can use it to convert several machines at once, on a single server – or scale it out and execute conversions on many servers at the same time.
With the release, you will be able to access many new features including:
- On-premises VM to Azure VM conversion
- PowerShell interface for scripting and automation support
- Added support for vCenter & ESX(i) 4.1, 5.0 and now 5.5
- VMware virtual hardware version 4 – 10 support
- Linux Guest OS support including CentOS, Debian, Oracle, Red Hat Enterprise, SuSE enterprise and Ubuntu.
- Migration Automation Toolkit support for MVMC 2.0
Migration Automation Toolkit (MAT)
MVMC Converter Download
Normally I do not use this space to advertise books except in the case of two exceptions: If it is a free e-book and is relevant, I will definitely recommend it – otherwise – it had better be good. After reading his first book on the Windows Azure platform, I was very happy to hear that Tejaswi Redkar has come out with a book on rapidly ramping on and deploying Windows Azure Websites – especially given the fact that this is one of the top use cases for moving to the cloud with Windows Azure. Yes, I am using this space to give a shameless plug for this fantastic book.
Do you want to know everything about the fastest growing service in Windows Azure? Do you want to build your own websites in minutes in literally automate EVERYTHING! Are you building a mobile application and need to ensure availability and reliability by implementing an always-on web service? Is your organization working on a cloud strategy?
The book is available in both 21st (e-book) and 20th century (paper) formats!
I first met Tejaswi during the Fall of 2010. He was an Architect and I was a Support Escalation Engineer. I was wading through future private cloud scenarios and he was educating us all on public cloud scenarios. We were both at an internal Microsoft conference up in Bellevue and he was taking me to school left and right on Microsoft Cloud technologies as he was already deep inside many things that neither of us could talk publicly about at the time. As more of a user of Azure (for my personal and day-to-day operations) I find myself on the end of many questions relating to Azure where I can shed light on my personal experiences, but not actually claim to be an expert. I reference Tejaswi's books often as great starting points.
Barnes and Noble Link: http://www.barnesandnoble.com/w/windows-azure-web-sites-tejaswi-redkar/1117494730