MSIX Shared Package Container for normal user

Iron Contributor

As an administrator i tested the following which does work:

1 have an AppX package installed with PackageFamilyName

2 have an MSIX package installed with PackageFamilyName

3 Created an SPC and put in both PackageFamilyNames and add to system

After starting the AppX application i see the MSIX content is mergend an can be used in the AppX.
But above is for Administrator working...but how about a normal, non-admin user?

For a non-admin user actions 1 and 2 are working, but option 3 is not working since you require administrative rights.

Anymone who can replay and tell me how I can get a SPC work for a non-admin user?
Or is that not possible and Microsoft assumes everyone is Administrator?

12 Replies
Created a case for it. Seems like add-provisionedsharedpackagecontainer is a solution here.
But no detailed info is available for it at Microsoft.

Will update this thread when i have some news
I have an update...

add-provisionedsharedpackagecontainer is available in Powershell, but there is no documentation yet for it and can't be used according to Microsoft.

The Shared Package Container (SPC) can only be used for ADMINS !!!
The SPC can't be used for normal users and make it worthless for us and for all people i guess.

Microsoft still has some progress to made with MSIX to make us able to transfer our AppV packages to MSIX packages.
"The Shared Package Container (SPC) can only be used for ADMINS !!!
The SPC can't be used for normal users and make it worthless for us and for all people i guess."

I can't believe that I never noticed this. I thought that the requirement for Win11 was blocking enough, but it can't be used by standard users, WTF???

Yes WTF.
Shortly we will have a discussion with the product group. Let’s see what they think about that and when we can expect to be able to use it for ALL users.

Just come across this concept although have have yet to come across a requirement for it. I take it we are referring to this article.

https://learn.microsoft.com/en-us/windows/msix/manage/shared-package-container

If that is the case, I agree with the comments so far with it needing to be configured to allow a user launching the application to be able to communicate with other user installed MSIX packages.

It would also be worth noting that this sort of configuration feels like App-V virtual environments and there was an option in MECM to manage this by creating the relationships and it would process the xml configuration at the point of deployment. If this is intended to be an enterprise solution, it needs to be offereed in a way that it can be managed across the enterprise desktop estate.
Yes, like AppV we would like to combine two packages into one like a Connection Group (AppV).
If would be nice to combine an AppX with a MSIX package as well.
Example: AppX Power BI Desktop and an MSIX package with the middleware for the AppX package, like Oracle, Teradata etc connector drivers for Power BI Desktop
I've created this feedback option highlighting this requirement, please feel free to review and vote.
https://feedbackportal.microsoft.com/feedback/idea/fe236fdf-2f94-ee11-a81c-000d3a02ba69
@Pollewops The term "middleware" triggers me to mention this. In this sense, I interpret middleware as a apcakge with an exe (and other stuff) that is usually not exposed to the start menu, but used by other software by referencing the name of the exe.

Under App-V we tended to use Connection Groups with middleware. But that is mostly because we were dealing with middleware (like javaws.exe) that might be used by multiple applications and have backwards-compatibility issues with newer versions of the middleware that might be needed by other packaged apps.

Seeing less of this these days, rather than resorting to SPC, I find it possible to package the middleware using an ApplicationAlias inside the middleware package, which works more like the App-V RunVirtual key but has the advantage of being directly part of the Middleware package.
Hi Tim, was thinking about your ApplicationAlias option. Could you explain more how this will work? Would like to try this out.
I am still searching for a possible replacement for RunVirtual add-ins with msix.

@Pollewops 

 

An AppExecutionAlias is an application level extension that may be added to an application in an AppXManifest file. When that package is installed, it allows anything that wants to request the shell to launch that name to get the exe to start-up. The exe will start in the context of the container that the aliased command lives in. This is often used to help other software find that exe without having to know the path to it, but the name of the alias doesn't have to match the name of the target exe.

 

For example, in my TMEditX MSIX package, I have a secondary application called "MSIXDeploy.exe".  Originally it was named "TMMsixDeploy.exe", but at one point the name was shortened. So I added an AppExecutionAlias for the application so that a third party tool that called it wouldn't have to be changed.  Here is the relevant entry in the AppXManifest file:

 

<uap5:Extension Category="windows.appExecutionAlias" Executable="MSIXDeploy.exe" EntryPoint="Windows.FullTrustApplication">
<uap5:AppExecutionAlias>
<uap8:ExecutionAlias Alias="TMMSIXDeploy.exe"/>
</uap5:AppExecutionAlias>
</uap5:Extension>
 


This could maybe help when added to the middleware package so that primary packages don't need to know where middleware.exe is, or that it is containerized. I'm not saying this will help your situation, but this is how it might be used. It is only OK for cases where it is OK that the middleware is then run in its separate container from the caller (or SPC in use).  So if the middleware must be passed a file, it needs to get the full file path. And if that the primary app tries to be smart and figure out where the middleware is to launch it full path it will probably mess up.  

 

By the way, traditional windows apps did this using the "App Paths" key in the Windows Registry (something that doesn't work for MSIX packages), but this is the modern app replacement. App-V supported virtual "App Paths" registrations, but MSIX ignores them in the package.

 

For an example of the "traditional App Paths" case, just go to a command prompt and type "write". This is a traditional App Paths registered to Wordpad.exe. Just look in the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WRITE.EXE
There is a (possibly true) story behind that alias that goes back to the old DOS days when Microsoft and IBM weren't getting along too well and wanted users to switch from IBM Write to their new "notepad.exe" program.

@TIMOTHY_MANGAN thanks for the nice explaination. But looking at it I could no see a way to get this used for replacing RunVirtual, e.g. add-ins (created MSIX format) started and included in e.g. Word, Excel when those are started.
If Word, Excel was MSIX, then I guess a Modification Package would work. Since then the add-in binaries and the registry key to start the add-in would be merged in the Word, Excel MSIX package.

But since that is not the case I guess we have to wait for Microsoft to create a possible solution for it. (If it ever will be there). Up until then I guess we need to install Office add-ins just as local applications. I guess that is the only way I see now.

@Pollewops Thank you for finally drinking the Kool-Aid :smile: