The original files were downloaded from the store and have been working until I installed NTLite 2024.4.9910.
Appx integration not working with NTLite .9910 or .9916
- Thread starter ZilchGuy
- Start date
Hi,
tested this one with both NTLite 9880 and latest 9925, same result.
No shortcut to the app after install, but it's there deployed and works in:
Potentially it's the Firefox package that changed in the meantime?
tested this one with both NTLite 9880 and latest 9925, same result.
No shortcut to the app after install, but it's there deployed and works in:
Code:
C:\Program Files\WindowsApps\Mozilla.MozillaFirefox_125.0.2.0_x64__gmpnhwe7bv608\VFS\ProgramFiles\MozillaFirefox Package RootPotentially it's the Firefox package that changed in the meantime?
Hello Nuhi, thank you for looking into this issue.
I typically use the Mozilla apps from the Windows store acquired by using Garland's PowerShell GUI script. They have been working without issue up until NTLite .9910 and later. They still currently work fine with .9880.
I have just tried integrating the same two apps manually using PowerShell while the image is mounted in NTLite .9925. I then completed processing of all the other changes in NTLite. After installing on my test VM, the apps are installed and working normally including start menu shortcuts.
I typically use the Mozilla apps from the Windows store acquired by using Garland's PowerShell GUI script. They have been working without issue up until NTLite .9910 and later. They still currently work fine with .9880.
I have just tried integrating the same two apps manually using PowerShell while the image is mounted in NTLite .9925. I then completed processing of all the other changes in NTLite. After installing on my test VM, the apps are installed and working normally including start menu shortcuts.
Thank you for the feedback.
Can you link the exactly the MSIX you test with 9880 that works with shortcuts and all?
If I could have a different result, it would be easy to fix, but to me those two versions behaved identically.
Also which Windows version to use, so we are on the same page.
I am testing with windows 11 Pro 22631.3527 23H2. I am not sure how to link from the MS app store. I used the PowerShell script provided by Garland to download the Firefox and Thunderbird MSIX files.
The exact files names are:
Mozilla.Firefox_125.0.2.0_x64__n80bbvh6b1yt2.Msix
MozillaThunderbird.MZLA_115.9.0.0_x64__h5892qc0xkpca.Msix
The exact files names are:
Mozilla.Firefox_125.0.2.0_x64__n80bbvh6b1yt2.Msix
MozillaThunderbird.MZLA_115.9.0.0_x64__h5892qc0xkpca.Msix
Last edited:
Retested, integrated Firefox MSIX with NTLite build 9928, shortcut is in the start menu:
When that shortcut is ran, all good.
Tested with Powershell, identical result, no start menu results for "Firefox", but the same shortcut is there.
Then saw start search "Mozilla" works
if I saw that earlier I would see that NTLite integration worked, I was dismissing it when that returned no results.
Let me know if your findings are any different regarding the shortcuts, and did you have the internet and store app downloads enabled/default.
My internet was disabled to remove that variable.
(Uploaded the new version)
When that shortcut is ran, all good.
Tested with Powershell, identical result, no start menu results for "Firefox", but the same shortcut is there.
Then saw start search "Mozilla" works
if I saw that earlier I would see that NTLite integration worked, I was dismissing it when that returned no results.Let me know if your findings are any different regarding the shortcuts, and did you have the internet and store app downloads enabled/default.
My internet was disabled to remove that variable.
(Uploaded the new version)
Last edited:
I installed NTLite build .9929, created and installed a new image. Now the same two Mozilla apps (Firefox and Thunderbird) both have start menu shortcuts, but neither will launch the first time unless there is an internet connection. Is that expected? Store app downloads have not been disabled.
That's expected behavior. Every UWP (or Store) app requires a per-machine license to run. During post-install, the ClipSVC (Client License Service) runs in the background to acquire licenses for all your free installed apps. This process may take a few minutes.
When you use the Store App, it automatically acquires the same license(s) for you.
The exception being any OEM apps which included their own offline XML licenses. Where it gets confusing, your devs may release the same app in multiple installer formats, and they all behave differently. Most Store apps require a free license to run, but it's easier to allow WU to silently update them than worry about writing an app updater.
Thank you for the explanation. That makes perfect sense.
Well, then it would seem that build .9929 has fixed the issue I have been experiencing.