App-V 5: On Java Virtualization Strategies

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.

Historical Strategies

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.

Methods

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.

RunVirtual

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:

IE Options	Pros	Cons
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
Packaged Shortcut	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.)

 

App-V 5: The Case of the RunVirtual Collision

I've discussed running native applications within virtual environments and the many ways we can bring applications like Internet Explorer into the bubble. One of the many reasons we would need to bring IE into the virtual environment is for web applications that use different versions of Java. When you virtualize different versions of Java, the shortcuts that are created will launch inside the bubble (and also through the /appvve switch.) For example, in the figure below, I have two specific Java packages deployed – each with its own Internet Explorer shortcut configured to run inside a separate Java bubble. I use the URL javatester.org to verify the version.

I can also view the java processes from the sysinternals utility Process Explorer running successfully launched from their own respective immutable package directory locations.

I can use another Sysinternals utility ListDLLS.exe to show that the App-V hook DLL has been injected into the Internet Explorer and Java processes.

You will also notice that if you configure RDS RunVirtual (where you use the AppV RunVirtual registry key to allow Internet Explorer to run inside a virtual package) to load Java into Internet Explorer, that you can see the Java application spawned by the IEXPLORE.EXE process inside of Process Explorer.

Differences from Dynamic Virtualization in SP2

You may notice in SP2 (as I believed I also mentioned in my last blog post) that when you launch Explorer and Internet Explorer, you will find that these also contain the injected AppVEntSubsystems32.dll due to the default dynamic virtualization configuration – however – just because you see EXPLORER.EXE and IEXPLORE.EXE hooked with LISTDLLS does not mean they will automatically behave the same way as if the application where configured for Run Virtual. App-V 5.0 SP2 introduced this feature as response to the historical desire for the virtualization of shell extensions. Actually shell extension virtualization is just one of the side benefits of JITV (Just-in-Time Virtualization – or “Dynamic Virtualization” as it is officially called.) Beginning with Office 2013, there was the capability of virtualization within a process being dynamically activated and de-activated on a per-thread process.

With SP2, this feature was extended to shell extensions AND ActiveX controls implemented as an in-proc COM object. This is why you will see injections of the App-V Hook DLL into Explorer or Internet Explorer even when no virtualized package is in use. This leads to an important statement: Just because the application is hooked, doesn’t always mean it is running virtualized if it appears as a process under the ProcessesUsingVirtualComponents registry value. This will be done at the thread level.

When an ActiveX OCX or a DLL that implements a shell extension is loaded from a native process or a process from another virtual application, App-V generates an additional virtual environment on demand linking the package containing the OCX or DLL with the process. Then dynamic virtualization is turned on for that particular thread. Once the thread exits, dynamic virtualization is turned off. If the said thread with dynamic virtualization spawns another thread, that thread too will be virtualized. This also helps to prevent RunVirtual collisions.

RunVirtual Collisions

When a single native process attempts to launch within more than one primary virtual environment without connection groups, you have colliding virtual environments – and it is not pretty.

In the context of Internet Explorer, they look like this:

Often this will be accompanied by the illustrious “spinning donut!”

How to tell if you have a RunVirtual Collision:

1. The native application is immediately unresponsive upon launch and it remains unresponsive.

2. The launch of the native applications spawns multiple packages in use when no connection groups are configured. These are the collisions.
   
   
3. The CPU will be completely pegged:

   
   

And the battle waging will be the native processes – usually at least one per package involved in the collision.

  

Finally, the smoking gun will be running LISTDLLS or Process Explorer against it looking for the actual executable for the virtual package. You will notice that while the native app is hooked, no virtual processes are able to start and get hooked (in this particular example, Java)

The Cause

The cause will most likely be launching the application through a run virtual command (ie Process.exe /appve:<GUID>_<GUID>) configured to run inside one particular virtual environment – while at the same time – that same native application is configured to run virtual inside another virtual application environment using the RDS RunVirtual registry key.

In the case of the above example, that was the exact cause. Internet Explorer was added as a process in the RunVirtual registry key and was configured to run in the Java 1.4 package. If you ran a normal instance of Internet Explorer, everything behaved properly. However, if you ran a shortcut to Internet Explorer configured to run inside a separate instance of Java using the /appvve switch, then the collision occurs.

App-V 5: On Run Virtual, RDS Run Virtual, Virtualizable Extensions, and Dynamic Virtualization

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

If you think that title is a handful, it simply a summary of most of the ways we allow local processes to interact with virtual environments in App-V 5. Whether or not you need to use these features will depend on factors such as targeting or if you want to take advantage of features introduced in App-V 5 SP2. Last year, I gave a primer in a blog on how to run a native process inside an App-V 5 package’s virtual environment. Well, recent question regarding internals as well as product developments have warranted a further discussion on the functionality of “running virtual: in App-V 5.

Run Virtual (RDS Run Virtual)

Designed really for RDS, I prefer to call this RDS Run Virtual as it was designed for RDSXenAppTerminal Servers. Why do I say that? Often application servers will be siloes for specific applications therefore they will likely be published globally. Through a simple registry key, you can have a local process interact with a specific virtual environment. As I mentioned in that blog from last year. You basically add process executable names as subkeys of the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientRunVirtual

For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>)

If the package is also in a connection group, the native process will be launched into the virtual environment (connection group) where that package belongs. NOTE: The connection group obviously has to be published globally as well. If the GUID pair is invalid or not found, the application will launch natively.

Run Virtual on Demand (using switches /appvve)

I have received feedback on the fact that only global publishing is supported with the RunVirtual registry key. If the application is user targeted and you want a “Run Virtual” equivalent for a native process, you can use the /appvve switch. This is a nice option because it allows an application be brought into the virtual environment regardless of publishing target type. Unlike the RunVirtual key in the registry, you will have to manage this on a per-application basis. Thanks to the VirtualizableExtensions option in the registry, if you simply call the native process through a shortcut extension in the package’s dynamic deployment configuration file, it will run virtual automatically.

Virtualizable Extensions

Speaking of Virtualizable Extensions: This is a special registry value which determines which application extensions will be treated with “Run Virtual” if configured as an application extension point within an App-V application. The extensions are registered under the following registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientIntegration

The value is VirtualizableExtensions and it consist of a REG_SZ data type where all of the supported extensions are listed separated by commas. For example, when you sequence an application like the IBM DB2 client, you may notice that some of the shortcuts are .BAT and .CMD files. In order for those applications to be treated as App-V applications that register properly as extension points, those extensions need to be registered under VirtualizableExtensions. The defaults are: exe, com, bat, cmd, vbs, ps1, cpl, jar, wsf, and wsh. You could add a .TXT extension, but given that a TXT file is not executable by FTA design in Windows, it would be pointless as the most it would do is open up Notepad in the bubble with this extension. But let's say your script interpreter of choice was something like Visual Cobol and you wanted to process a script using a .CBL file. You would have to add in this extension. If a Visual Cobol is locally installed when a CBL script is called through an extension point, it will run it virtually.

Dynamic Virtualization

This was introduced in App-V 5 SP2 in order to give us shell extension support and native interaction with virtualized ActiveX controls. The registry value that toggles this on or off is EnableDynamicVirtualization and it is located in HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientVirtualization

In addition, those processes that are specified for this feature are listed in the ProcessesUsingVirtualComponents registry value located in the same key. By default, Explorer.exe and Internet Explorer are listed there. You can see this in action by using a tool from SysInternals called LISTDLLS.EXE. For example, let’s say I’m on a client configured with the virtualization defaults for App-V 5 SP2 and I currently have one program launched: Notepad++ (yes, I admit it – I use it.)

When I run Get-AppVClientPackage from PowerShell, it shows I only have one application in use:

However, when I run the LISTDLLS.EXE command to find out which processes have the AppVEntSubsystems32.dll injected (or AppVEntSubsystems64.dll for 64-bit processes) you will see both notepad++ and Explorer have been hooked.

And if I were to launch Internet Explorer, I would see the same thing. Do not confuse this interaction with RunVirtual. Dynamic Virtualization has a limited scope of interaction designed for features introduced in App-V Service Pack 2.

 

Update: 2/7/2014

While I rarely update my blog posts (except for resource pages) it appears that I need to expand further based upon the feedback and comments I have received. When you are virtualizing an application that uses shortcuts that point to BAT or CMD files, you configure these shortcuts just as you would any other application. I’ll use the example of the DB2 client. It sets up a perfect example.

Notice in the figure below we have captured some applications that are executables and some that are scripts.

 

The shortcut to Command Line Processor Plus (CLPPLUS.BAT) appears as it normally does in the shortcut dialog box.

 

And the Command Line Processor (which calls a batch file as an argument) appears as normal as well.

Now both of these will be captured into the manifest and dynamic configuration as such:

 Upon the publishing/configuring of the package the shortcuts will then get applied as shortcuts that run inside the virtual bubble. The EXE’s are published with the respective scripts as arguments:

 

But while EXE’s launch from the integration path and get directly hooked, you will notice that script extensions (BAT, CMD’s) get /appvve applied to it to ensure it launches in the correct bubble:

 

 The publishing components knew to do this because the extension was listed under the VirtualizableExtensions value inside the App-V registry.

Update 12/6/2014: With the release of App-V 5 Service Pack 3, there is a change that allows the RunVirtual key to be added to the user's profile (HKEY_CURRENT_USER) to affect user-targeted applications. More information on this improvement can be found here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_runvirtual_reg_key

App-V 5: To Virtualize or not to Virtualize! How App-V 5 Answers that Question when you Launch a Shortcut

Wow, that blog post title sounds like every formulaic business book title from the last twenty years. I should probably change it. I’ll worry about that later. For a change of pace, I am not going to write much on this subject because this is one subject that needs to be explained visually. So for the most part this blog post will be very little in the realm of text but hopefully a very ugly, yet hopefully very helpful picture.

 

In essence, AppV remains behinds the scenes. When the EXE is launched, the App-V virtualization manager receives a blocking callback function and triggers a series of verifications to determine if a process should be virtualized or not. This makes it very flexible especially considering you may be dealing with native EXE’s, EXE within the App-V VFS, potential co-existence with the 4.6 client. Hope this flowcharts helps to explain the process!

App-V: Still More on Those Office Add-ins

As you can tell, I have been obsessed with Office Add-ins lately. Shifting gears from troubleshooting, I would like to address the different approaches to virtualizing add-ins with App-V. While the last two articles on the subject could easily be applied to both App-V 4.x and 5.x, my focus today will be specifically on App-V 5 because it offers more options and flexibility in the virtualization of add-ins. As I discuss each method, I will give my thoughts on the advantages and disadvantages of each method.

The Most Obvious: Sequence the Application and Add-in Together

While this method may seem to be the easiest, this method is only viable from a servicing standpoint if you:

• Have only one deployment of the application.
• In the case of Office, everybody will use the same group of Office applications.
• Everybody needs and/or is allowed access to the included add-in(s).
• For App-V 5, all add-ins will use the same COM settings inside the dynamic configuration files.

With this method, we do not likely run into issues with user state data and we do not have to involve any complicated sequencing recipes (other than the ones you would be using anyway – as the case with Office.)

Local Office Brought into Virtual Add-in Package during Sequencing

In this scenario, the add-in is totally virtualized but the parent application (Office App) is native. During sequencing, shortcut extension points were added to the package (dynamic configuration and FB0) so these shortcuts will launch inside the same virtual environment as the add-in. This scenario works best when there is a desire to keep the parent application native to the operating system.

 

The extension point format in the Deployment_Config.XML points to the local instance using a tokenized path. In the example below, here is a local shortcut extension point for Excel 2010 that is labeled as “Contoso Processing” because it will launch inside the virtual environment of the virtualized Contoso Processing add-in.

        <Extension Category=”AppV.Shortcut”>

          <Shortcut>

            <File>[{Start Menu}]Microsoft OfficeExcel (ContosoProcessing).lnk</File>

            <Target>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe</Target>

            <Icon>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe.0.ico</Icon>

            <Arguments />

            <WorkingDirectory>[{ProgramFilesx86}]Microsoft OfficeOffice14</WorkingDirectory>

            <ApplicationId>[{ProgramFilesx86}]Microsoft OfficeOffice14excel.exe</ApplicationId>

          </Shortcut>

        </Extension>

 

The problem you may run into when using this deals with user workflow. This particular shortcut will launch this specific instance of Excel, but a regular shortcut to the local Excel will only launch the native Excel (with whatever native Excel customizations are in place.) You will not be able to share user state across the two instances of Excel unless you leverage UE-V or another user state solution.

 

Local Office Brought into Virtual Environment using “On-the-Fly” Shortcut

Yes, it’s a long name, but it was the best I could come up with! What happens here is very similar to the previous method where the local/native installation of Office is brought into the virtual environment but not using an embedded shortcut. Instead, we are using an “on-the-fly” shortcut solution where the shortcut leverages the following syntax:

 

<AppName.EXE /appve:<GUID>_<GUID>

This is convenient and quick way to link a local application with a virtual plug-in or add-in. Before you jump to this option, understand there are a few potential issues that could arise. The first will be the provisioning and management of these “out-of-band” shortcuts. Delivery of these shortcuts would have to come outside of the normal publishing block. You also will have to modify these shortcuts whenever a package version has changed. Also user state, registry opacity, and other configuration-relation issues could arise as you have similar issues with this method as you did with the previous one if you are moving back and forth between a local instance and one that has been brought into the virtual environment of the add-in.

Virtual Office Linked with Virtual Package using a Connection Group.

With the introduction of Connection Groups in App-V 5, we now have more flexibility in linking different packages together into a single virtual environment. The most common way of using connection groups to link Office applications with Add-ins is to create one that links Office as a virtual application with the virtual add-in applications.

Once you introduce connection groups into the mix, the order of packages in the connection group is important. This is regardless of how you are deploying these groups (publishing server, configuration manager, or stand-alone.) The connection group order specifies the order in which registry and file system data of individual packages are merged. What this means if Office is first in the connection group and the Add-in package is second, the Office application will take precedence in terms of registry opacity.

Local Office Application Brought into Virtual Package Using Empty package/Connection Group Solution

This is very similar to the above scenario except the assets for the local Office applications are local.

 

In this scenario, Office is installed locally/natively but there is an empty virtual package that contains local shortcuts to the Office applications. This virtual package is linked with the virtual add-in package through a connection group. The ramifications are combined in that you may encounter workflow issues for users. Connection group order will also be important in terms of user state and registry opacity.

Local Office application brought into the Virtual Add-in Package using “Run Virtual”

If you are working within RDS environments, and have a package that is published globally, you can also take advantage of the “Run Virtual” feature. You basically add process executable names as subkeys of the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftAppVClientRunVirtual

For example, if I have a locally installed application called MyApp.exe and I would like this application to run within the virtual environment, I would create a subkey called MyApp.exe (perhaps a helper application like Adobe Acrobat that may need to be called from a virtualized web application.) I would then put in as the default entry a REG_SZ value that contains the package GUID and the version GUID separated by an underscore (i.e. <GUID>_<GUID>.

If the package is a standalone package, the process will be launched in that package’s virtual environment. If the package is in a connection group, the process will be launched in the virtual environment of the connection group for which the package belongs.