Nov 11 2020 06:33 AM - edited Nov 11 2020 06:34 AM
I verified that the changes in registry under HKCU are contained in MSIX package.
When installing and launching the msix package the changes that should be there are not. It reverts to the application default. This was on a clean VM. No residual registry data for the msix package to merge with.
Manually mounting and browsing the User.dat from the msix package confirms that the data is indeed in the package. Any ideas or pointers?
W10 v1909
Latest MSIX Packaging Tool
PsfTooling v4.5
Nov 12 2020 12:30 PM
@pysjkrig It all depends on how the app accesses HKCU.
First of all, when you get to the 2004 or 20H2 version of the OS for deployments, the basic MSIX runtime treats HKCU access better than prior versions. This could be enough to solve the issue if the app wants to open the HKCU keys and items for read/write alone.
But some apps blindly ask for additional permissions that they don't need. The app always worked when natively installed or under App-V, as the app could do anything it wanted under HKCU. MSIX, even under OS2004, does not.
It may be possible to use process monitor against the packaged app and look for access permission issues in HKCU. Some of those may be addressed using PsfTooling and the RegLegacyFixup.
Feb 24 2022 08:39 AM
Feb 25 2022 06:14 AM - edited Feb 25 2022 06:16 AM
You didn't mention specific tools used, but I assume the Microsoft MSIX Packaging Tool is used to create a MSIX package, and then a second tool is used to convert into either VHD or CIM and MSIX App Attach is used.
Given the above, I would first break the problem into two parts. During the initial capture, the HKCU keys should be captured in the package. This could be verified by installing/running the package, however there may be issues with the vendor software in how they access those keys. To determine if the registry values were captured, you would break into the package to extract the Registry.Dat file, go to RegEdit, create a dummy key somewhere, right click on that dummy key and import the Dat file. It sounds like you have done that (using the User.Dat file which is OK).
Assuming the registry was captured (which I suspect is the case), I would then repackage using the Package Support Framework (PSF). Last year I created a fixup there called RegLegacyFixup that can solve the most common issues we see in how the app might try to access the HKCU keys/values that you captured.
Once you have a working package in MSIX form, then migrate it to CIM and MSIX App Attach. I don't think the second part should break the registry, but at least we'd know where the problem is.
Feb 25 2022 06:27 AM
Feb 26 2022 06:19 AM
@Nick-S After selecting the RegLegacyFixup, you need to add rules that the app needs. I usually start with a default set of three rules. I'll attach a screenshot.
Older applications will sometimes assume the ability to do whatever they want under HKLM. Inside the container, they are not allowed to request certain permissions, so calls that previously would have worked now fail (even if they don't try to actually use those permissions). So this fixup intercepts those calls and gives them the subset that are supported, or just fake out that it worked even when it doesn't. It isn't perfect, but these three rules seem to be solving every case I've seen to date (for HKCU).