Productive virtual application debugging requires an understanding of the basic fundamentals of debugging compiled software code. For this part of my series on debugging virtual applications, I will be focusing exclusively on these fundamentals. If you are already familiar with these concepts, please allow me to quickly recap these to those readers which may be either not familiar, or only somewhat and looking to solidify these concepts.
Types of Debugging
There are several categories of debugging and the descriptions will vary by vendor, publication, and academic degrees of description. There is almost a guaranteed point of view when it comes to applying it to a specific product or series of products. Being that my discussion primarily revolves around products that run on top of the Windows operating system, my point of view, or slant, is obviously geared towards the types and toolsets that come with Windows.
Live debugging refers to the mechanism of attaching to a running program or process either invasively or non-invasively. A debugger may attach to a process and wait for exceptions or set a specific breakpoint. The debugger can insert those breakpoints in once attached to the process. The easiest way to think of a breakpoint is to understand its most basic definition: a breakpoint is a place or time at which an interruption or change is made. More information on breakpoints and different breakpoint types within the Windows context can be found here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff538928(v=vs.85).aspx. In addition, live debugging is also commonly used to troubleshoot and analyze code within the developer environment. In those situations the types of breakpoints will vary. For example, you can refer to the examples of breakpoints that are available within the Visual Studio development environment here: https://msdn.microsoft.com/en-us/library/bb161312.aspx. Once attached to the process, a debugger can then step through threads and functions as the application is live.
Print or Trace Debugging
This is the most common method for troubleshooting software applications and operating systems as technically, this can cover a wide scope of methods. An application can run at specific diagnostic levels generating additional output and information that can be collected into a file or database that can be used to isolate and issue. Event traces, log files, debug output all fall into this category. Strictly speaking within Windows, applications can leverage the OutputDebugString or ODS to have an application, service, or operating system component generate what is referred to as “debug spew” and you can use various tools to collect or view this debug trace information. The most popular tool for viewing ODS traces is the Debug View utility (DBGVIEW) from the Sysinternals suite (https://technet.microsoft.com/en-us/sysinternals/debugview.aspx) although this is not the only one. More information on the OutPutDebugString can be found here (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363362(v=vs.85).aspx.)
In addition, there are tools that can hook into the Windows operating system to capture Win32 API and other application functions through the use of a simple user mode monitor (like the API Monitor tool) are even deeper through the use of a kernel-level filter driver (Like Process Monitor.) Literally troubleshooting outside the box and on to the wire – you can use network trafficprotocol analysis tools like Wireshark or Message Monitor (https://www.microsoft.com/en-us/download/details.aspx?id=44226) to capture network traces. These are all forms of trace debugging.
Windows Integrated Tracing and Instrumentation
Prior to Windows Vista, there were Event Logs, ODS tracing, text-based log files, etc. all within Windows each requiring their own tools and APIs. Starting with Windows 2000, Microsoft began incorporating Event Tracing for Windows (ETW) into the operating system and soon, applications and windows components were using this common engine for enabling diagnostics and collecting detailed debug tracing. Viewing of these traces was soon integrated into the Windows Event Viewer and users of App-V 5 are able to often resolve issues using this very mechanism.
The instrumentation mechanism is discussed here ( https://msdn.microsoft.com/en-us/library/zs6s4h68(v=vs.110).aspx) and probably the greatest technical reference on ETW can be found here (https://msdn.microsoft.com/en-us/library/windows/desktop/bb968803(v=vs.85).aspx)
Remote Debugging is a form of live debugging where the process of debugging occurs on a system that is different from the debugger. In most Windows cases, this is where there is an issue that needs to be debugged at the kernel mode level prior to the completion of an operating system boot or a system level crash. To start remote debugging, a debugger connects to a remote computer over a network or via a serial cable. The debugger can then control the execution of the program on the remote system and retrieve information about its state. In Windows, this is often done serially or via Firewire.
Post Mortem Debugging
Post Mortem debugging is a very common method of troubleshooting problems within software because it involves viewing a historical point-in-time snapshot of a hang, system, or application crash. This is where a debugger will read in a snapshot of debugging data called a “dump file” which contains existing memory and instruction pointers. The degrees of debugging depend on how much data is collected in the dump file as dump files can vary in what they collect. When it comes to application and system dumps, these can be controlled by the operating system’s default handlers (once called Dr. Watson for user mode applications) as to what information is collected in the dump file.
I was first introduced to the concept of post-mortem debugging reading an article by Matt Pietrek way back in 1992 in Dr. Dobbs Journal. Matt historically is one of the earliest writers on the subject of Windows debugging going back nearly three decades. The amazing thing is you can still read this article I am citing as it is available online: http://www.drdobbs.com/tools/postmortem-debugging/184408832
Execution Modes of Debugging in Windows
When we are speaking of execution modes in Windows, were talking about code that runs either in user mode or kernel mode. The execution mode affects the methodologies and tools you will leverage in order to properly debug the issue. Software is ultimately driven by the processor (CPU.) For a computer running Windows, the CPU runs in two different modes – user mode and kernel mode. The CPU switches between the two depending on the code.
The kernel and other operating system components run in kernel mode, hence the term. Rather than a macrokernel like other operating systems, Windows runs a smaller microkernel that runs as process SYSTEM. Like an application loads and uses DLL (dynamically linked libraries) the kernel also loads special modules called executive components and/or filter drivers alongside device drivers. There is essentially only one process running and that is what shows up in the Windows task Manager as “System” and if this application crashes . . . well . . . so does the entire computer. With debugging, when we are debugging in kernel mode, we are essentially debugging this process – however, it also serves as the governor of all of the other processes running on the system in user mode. All code that runs in kernel mode runs in a single virtual address space. This means that a faulty kernel-mode driver is not isolated from other drivers and the operating system itself.
Regular applications, middleware, plug-ins, and most services run in user mode. When you start a user-mode application, Windows creates a process for the application. This process will execute one or more threads. I use the description of the process itself being innate in nature. It just owns a private virtual address space, a private handle table, and contains at least one primary thread for execution. This description of a process comes from Jeffrey Richter who has written many books on Win32 programming. Because these processes are isolated from each other, an application is unable to screw up the operation of another separated process if it crashes. Other applications and the operating system are not affected by the crash. Data can be exchanged between these processes through interprocess communication mechanisms but they cannot directly write to address spaces directly. Limiting the virtual address space of a user-mode application prevents the application from altering, and possibly damaging, critical operating system data.
The App-V product is especially complex when using it as an example because it contains code at both kernel and user mode. The App-V client engine consist of kernel level drivers, a primary service, and user-mode DLL’s that are injected into the processes of virtualized applications.
Next Up: Debugging Misbehaving Application Scenarios
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 . . . 🙂
When software malfunctions, product support teams attempt to narrow the issue down to user error, configuration, or code. If the software attempts to perform a function where a specific result is expected and the actual results are different, we classify that as a bug. Of course, there is great debate on what is perceived as a bug, or is simply “by design” meaning the software was doing exactly what it was programmed to do – it just may be completely different from what the end user expected.
Let’s assume we are not having the “by design” vs. “bug” debate. When a bug confirmed, the next common item that is measured is the impact of that bug – impact within the specific customer’s environment, the frequency and likelihood of the bug occurrence. Bugs that have only occurred one or two times where the impact is minimal is usually referred to as an “outlier bug.”
Outlier bugs can be tricky – especially if there is not a known workaround. Software vendors have to weigh the risk and cost of implementing bug fixes via current version patches (as opposed to correcting the code for the next release.)
A while back I encountered one of those outlier bugs in which this bug only affected one customer (at the time) and it only revolved around one specific App-V package. It involved the App-V Client Reporting Agent failing to upload reporting XML data. The following issue was occurring.
Client machines were failing to upload reporting data. Upon a manual test using the Send-AppVClientReport cmdlet, it would yield the following error:
PS C:Windowssystem32> Send-AppvClientReport
Send-AppvClientReport : No reporting data has been sent to the specified URL. Verify the URL and try again.
Operation attempted: Send reporting data to reporting server.
AppV Error Code: 1300000013.
Please consult AppV Client Event Log for more details.
At line:1 char:1
+ CategoryInfo : InvalidResult: (:) [Send-AppvClientReport], ClientException
+ FullyQualifiedErrorId : SendReportError,Microsoft.AppV.AppvClientPowerShell.SendAppvClientReport
This issue was NOT occurring on all of the clients, so the first major step was to find the common denominator. Eventually we found the common denominator was a specific package. In addition, we actually got quite lucky. In many cases, the machines getting this issue only had one specific package deployed to them.
So we grabbed the XML file (C:ProgramDataMicrosoftAppVClientReportingdd6c24e-be93-48f7-b531-4eaa007128ec.xml) to view the Reporting cache and eventually narrowed it down to only occurring when the specific application was published.
What makes this issue an outlier is that the element that was causing the issue involved a package where the primary application had a version field that was greater than 16 characters. On a lark, we started modifying the XML data manually and found that if the reporting XML file was manually edited, and enough digits were removed from the version field, the upload worked. For some reason, only 16 characters were allowed in the version field. All of the fields were supposed to allow for 32.
Once root cause was narrowed down, the time came to assess the impact of the bug. It was definitely viewed as an outlier bug due to the fact there was only one known occurrence (again – at the time.) The assessment of how likely this would reoccur soon became a moot point as the good news here as the issue was within the database itself. The App-V 5 reporting service is stateless and writes directly to the temporary tables in the AppVReporting database. So we were able to fix the issue for the customer without cracking open binaries for patching.
If you are interested in the database script, it was published out on the TechNet Gallery here:
This fix was included in the App-V 5.1 release.
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.
Throughout the past 15 years, from its origins in Softricity, one of App-V’s primary use cases has been addressing complex version-dependent Java run-time ecosystems. The “Application-to-Application Isolation model” of App-V – particularly using JRE runtimes as a test case – proved much success for those applications and enterprise websites that were married to a specific runtime – and needed to be used by the same user and/or multiple users on the same machine. As Softgrid became App-V, the client engine developed more and more methods of further, optional integration into the operating system via advanced extension points as well as dynamic virtualization (or just-in-time virtualization.)
Fast-forward to today: While the many of the old traditional issues that came with DLL Hell (such as DLL stomping) were rectified via registry-free assemblies and WinSxS, managing multiple JRE runtimes still requires intervention – especially when deployed to pooled session and virtual desktop environments (i.e. Citrix XenApp, MS RDSH/RDVH, etc.) As “JAR hell” as it is often called – appears to be here to stay for a while, JRE isolation is still one of the top use cases for App-V as a result.
In the world of Softgrid up until Softgrid 4.1, the strategy choices were simple:
- Single JRE (Virtualize None): The most desired scenario. This simplified deployments and allowed for JRE to be included in base operating system deployment images.
- Virtualize All JRE’s: No native JRE images in the base image. All versions are isolated using App-V.
- Virtualize all but One JRE: In this scenario
In addition, the versions of Java had to be sequenced within the same virtual environment as the parent application. This would eventually start to change with App-V 4.5. In that particular release, DSC (Dynamic Suite Composition) was introduced allowing applications dependent upon Java to be sequenced separately from Java and linked together.
With the release of App-V 5 and its subsequent iterations, the options for Java have become more flexible. However, since the primary reason for virtualizing Java is to be able to deploy multiple versions of the run-time module to same virtual or physical machine, all options for virtualizing Java are not necessarily on the table. Each option must be assessed on its own merit. The potential strategies for Java are as follows:
Packaged with Application or Browser
This is where the specific JRE middleware is installed alongside an application within the same App-V package. Not a very common solution as it requires the master application to be updated as the runtime needs to be updated. Because of the many issues that come with this, Dynamic Suite Composition was introduced in version 4.5. This was later improved with Connection Groups in V5.
Connection Groups and Challenges
Connection Groups are where two or more applications are sequenced separately and brought into the same virtual environment (essentially a meta-bubble.) This was introduced first in App-V 5 and then drastically improved for 5.0 SP3. This allows for the capability of updating applications and pre-requisite JRE packages independently. Connection Groups for Java run-times can be challenging – especially on RDS systems where many different users are running multiple applications dependent upon the same version of Java. Once a Java Package was initialized, it can only run within one Connection Group at a time. This requires proper planning and potential silo-ing for RDS scenarios.
This is where a designated native application is linked to a virtual environment. RunVirtual (in its many forms) tells a native application to run within the virtual environment of the assigned application (as well as its connection group if the application belongs to one.) RunVirtual is a great solution for those natively installed applications to take advantage of interoperability with a virtual application. The ways you can configure a native application to “Run Virtually” are as follows:
- The RunVirtual Registry Key: This works great as it is tied to the processes’ executable name. Can be configured per-machine or per-user starting with App-V 5.0 SP3.
- Configured Package Shortcut: This is a good solution as it travels with the package.
- Out-of-Band RunVirtual: Where a Shortcut or Command Line contains the /AppVVE or /AppVPID switch or uses PowerShell to run a native process within the virtual environment of specific package.
All of the possible options for launching a native process into a virtual package’s environment (bubble) are found here: http://blogs.technet.com/b/gladiatormsft/archive/2013/04/24/app-v-5-0-launching-native-local-processes-within-the-virtual-environment.aspx
Internet Explorer – A Worthy Separate Discussion
Internet Explorer warrants its own discussion primarily for two reasons:
- Internet Explorer cannot be packaged and isolated from the native operating system.
- Internet Explorer, like Explorer, is eligible for supporting primary and secondary virtualization environments through dynamic virtualization.
For those reasons, I segment my Internet Explorer and Java discussions from all other applications when discussing application virtualization strategies with customers.
Internet Explorer, Java, and RunVirtual
Configuring RunVirtual to bring the local Internet Explorer into the Java packages’ virtual environment is a simple way to allow for interoperability – but it can lead to its own issues:
- RunVirtual via Registry Key: Whether it is per-user or per-machine – this methodology forces IE to only interact with one Java package (or else yield potential issues with RunVirtual collisions. Use this solution if only one Java package will be needed virtually with Internet Explorer for the user (or the machine if configured for the machine.)
- RunVirtual using command line switches (AppVVE, etc.): This requires a lot of out-of-band shortcut management – but it does give flexibility so long as all other instances of Internet Explorer are configured for RunVirtual in either this manner or though packaged shortcuts.
- Packaged Shortcuts: Using shortcuts to the local Internet Explorer – either captured via sequencing into the package manifest or configured via dynamic configuration. This method will create a special shortcut that essentially runs virtual for the native Internet Explorer. It also travels with the package and as long as the naming is unique, it will not create two much confusion although it does mean that Internet Explorer must be launched using this specific shortcut to ensure it runs within the specified virtual packages.
When you weigh out the “perceived” complicated options for bringing IE into an App-V Java package by Pros and Cons, you can simplify it using the table below:
RunVirtual through Registry Key (Global)
Simple to Deploy.
Does not Travel with package. One Java per IE per Machine.
RunVirtual through Registry Key (User)
Simple to Deploy.
Does not Travel with package. One Java per IE per User
Travels with package. Allows for multiple Java packages.
Creates Multiple Internet Explorer Shortcuts.
Out-of-Band RunVirtual (/AppVVE, etc.)
Allows for Multiple Java Packages.
Does not Travel with package. Creates Multiple Internet Explorer Shortcuts.
Connection Group with EBIS (Empty Bubble w/ IE Shortcut)
This is where Internet Explorer is treated as a separate package though the creation of an “empty” virtual package containing only an Internet Explorer shortcut. That empty package is then linked to a virtual Java package using Connection Groups. If you want to use Connection Groups to link Internet Explorer with virtual Java packages instead of RunVirtual solutions, this may be the better solution – especially if you will be running both native and virtual Java on the same machine or device.
IE Native w/ JITV of Plug-In – Dynamic Virtualization Only
I have been starting to see this on App-V test matrices and I am a little bit concerned as it adds unnecessary testing variables that can further delay a package’s movement through common UAT (User Acceptance Testing) scenarios. That is not the case.
Dynamic Virtualization (also referred to as JITV – or Just-in-Time Virtualization) allows for virtualization of shell extensions, browser plug-ins, and ActiveX controls for a virtual package within the native processes that are hosting the COM objects. They key item being COM OBJECTS. They all need dynamic virtualization of COM in-process objects. There are some exceptions to some browser plugins that only use HTML scripts. They use an object model completely separate from COM. Not all browser plugins require COM in-proc virtualization. Do you get where I am going here?
Adding One Final (yet significant Variable) – the Legacy 4.6 Client
Running virtual packages containing Internet Explorer in 5.0 side-by-side with Legacy 4.6 packages running Internet Explorer running side-by-side with the App-V 5 client is supported. They did, however, had some initial issues when ran with Internet Explorer 10 and 11 due to issues with Enhanced Protection Mode and some double-hooking issues that were rectified by Hotfix Package 1 for 4.6 Service Pack 3 (https://support.microsoft.com/en-us/kb/2897394.)