Udostępnij za pośrednictwem

App-V 5: On Java Virtualization Strategies

  • Artykuł

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: https://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.)