Isolating JRE within an MSIX container.

[SajidRavat]

I have packaged a legacy version of Java (1.6.27) for a browser application that requires a specific version.
The MSIX package works using Edge in Internet Explorer mode.

However if there is a locally installed version of Java which is a later version, the packaged version no longer works, Edge launches the locally installed Java instead.  I have tried using Tim Mangan's JREBlock, but that has not worked either.

Could this be due to MSIX not having merge/override settings that App-V does?

Any ideas?

[#2]

You mis-characterized the cause, but yeah. When looking for the version of Java to use, it enumerates the Classes keys for java (which are version encoded numbers, not "real GUIDS").

Under App-V, we used JREBlock in the capture to cause deletion markers inside the package virtual registry. So the deletion marker was a merge overlay hiding the local value (not override in the traditional App-V sense) but those hide the local registry entries.

The MSIX virtual registry does not have a similar deletion marker strategy in the virtual registry. But there is a new capability available in the AppXManifest file that allows for the specification of deleted registry items there.

At this time there is no automated way to create those entries, and I'm sure that you've seen how many that can be; more than you'd want to manually add (in the hundreds).

Your best option today may be to get rid of the native install of Java. Does it really need to be in the image any more?

[#3]

Oh that's interesting... Have you an example of using the deletion marker strategy in the AppXManifest? Could try to specifically set the markers for only the version we have installed.

And no, getting rid of Java is a no go at this point for our client.

[#4]

@SajidRavat

There's no such setting or an option to do that yet. However, you can submit this as an idea on MSIX feedback - Microsoft Community Hub.

Meanwhile, if you can share the installer for your app, we can check if there's a workaround available.

[#5]

I did have an idea, but it is more work for YOU. When you packaged Java in App-V you probably used JavaBlock to create the deletion markers in the registry. As I mentioned, Microsoft did not bring along virtual registry deletion markers to MSIX. But it should be possible to create all of the additional CLSID keys for future Java versions, but point them to the Java in your package.

So rather than run JavaBlock with the addkeys option prior to packaging and then run again with the delete keys while packaging, but before you install crusty java version, you do the following:
1) Edit a version of JavaBlock for the add keys case that looks for existing keys and adds future keys with the content you find in your last found key.
2) No pre-package script needed.
3) While packaging, install crusty java first, then run that script to add in the future keys.

As I said, Java should die, so I'm not planning a script update myself. Good luck!

[#6]

Hi @SajidRavat 

Please share the JRE packaged application on this thread using the drag and drop feature and we will investigate into it further. 

Thanks,
Fiza Azmi
PM, MSIX Team 

[#7]

Hi @Fiza_Azmi 

There is no application.  The JRE is required in Edge within a session running in Internet Explorer mode.

[#8]

Hi @SajidRavat 

Which is the MSIX package in question in this case?

Thanks,
Fiza Azmi
PM, MSIX

[#9]

Hi @Fiza_Azmi 

The MSIX package contains the JRE only. Version is 1.6.27.

Thanks

[#10]

@SajidRavat 

It occurred to me to ask if the Java package has ExectionAlias extension, and is this for Windows 11, and is there a shared package container.

Tim

[#11]

I think I did try ExecutionAlias... It is for Windows 10 for now and we are attempting as a standalone package.

[#12]

@SajidRavat Yes, Execution alias needs only Win 10 1703. It is Shared Package Container that needs Win 11. The idea here is that Edge needs the shated container since it is also running in a container. This might not also work, but is the best idea that I have.

[#13]

That makes sense... I'll give that a go on Windows 11 when I get an opportunity.
Thanks

[#14]

@SajidRavat 

There has been a new release of PSF (version 1.0.231110.2) with a way to support Deletion Markers for registries which allows hiding of specific registry keys or registry values in the virtual environment. Please try using that and let us know if that works for you. 

[#15]

I took a look at the hiding registry key fixup rule in the Microsoft branch. Technically, it should be able to do the job, but it will require a lot of manual effort to add all of the keys necessary by hand into the Json file. For a package with Java 1.6 it would be about 40 keys to type in.

[#16]

@TIMOTHY_MANGAN 

MSIX Packaging Tool allows you to give a regex string for registry keys and values to avoid the overhead of adding too many entries and manually generating config.json for PSF.
@SajidRavat you can use regex like ^MACHINE\\Software\\Classes\\(?!JAVAPLUGIN\.10627$)[^\\]+$ .   <modify path according to your use case>

Let us know if you have questions. 

[#17]

@mridulgupta 

It is interesting the area of the registry that @mridulgupta is targeting in the prior reply. Traditionally we attack a subset of the Classes\{CAFFEEFAC- to solve the Java problem.  

Over the holidays I have worked on a different json approach, specifically for the java problem in my PSF fork that is in final testing.

That approach adds a different rule (JavaBlocker) that just lists the java version required, which will be simpler for customers to use.  Parameters are majorVersion, minorVerson, and updateVersion and hives and regex patterns not required.  As Java seems to be the primary need for registry blocking, this would be easier for people to understand how to use.  It just takes care of issues like whether the install was the 64- or 32- bit, or user or machine install, without having to embed that in the json.

I've also ported the DeletionMarker rule into my fork for consistency, although I really wish it didn't have a base hive and key and list of values, but a simpler list of values.  For general purpose use, I find the single hive/key implementation of this rule limiting.  I considered modifying this in my fork version, but opted to implement the same rule as used in the Microsoft fork for consistency.

I expect to release this to my GitHub fork soon, and in the next version of PsfLauncher/TMEditX shortly after that.

[#18]

@mridulgupta 

I looked into your proposed fix.  The deletion marker you propose would block any java from running inside the container.  I do not believe this is what the requester wanted.

I believe that the requester wants to package up a version of java that will work inside the package, but to block the packaged app from access to any newer version of java that is locally deployed.  This is often necessary because newer versions of Java are not always backwards compatible, and the customer cannot get an updated application (and yet wants to prevent general use of an older and unsafer version of java).

This is why we target the deletion markers to all future keys of the Classes\{CAFFEEFAC- pattern, which encode the version of java into the key name.  So if the package includes up to {CCAFEEFAC-0017-0000-0045-ABCDEFFEDCBA}, which is java 1.7U45, we need to block classes keys above the 45, but also 18 and 19 ranges. 

Spoiler

Update: v2023.01.02 of the TimMangan fork has been released with the JavaBlocker rule for RegLegacy.

[#19]

@TIMOTHY_MANGAN 

We can simply use this regex  ^SOFTWARE\\Classes\\CLSID\\(?!{CCAFEEFAC-0017-0000-0045-ABCDEFFEDCBA}) to hide all java versions except java 1.7.0.45
We can be more specific in the regex for custom use cases.