ulygray jasmina annibella
Salvador Baltimore
An .appx file is a package file format used by Microsoft Windows 8 and later versions of Windows to distribute and install applications. It is used for Universal Windows Platform (UWP) apps and can be used to package both Windows Runtime apps and Windows desktop applications.
With the introduction of Windows 8 and the Windows Store, Microsoft wanted to provide a way for users to easily discover, purchase, and install apps on their devices without having to rely on traditional installation methods such as .exe files.
Additionally, the .appx file format provides a more secure way to distribute apps because it includes a digital signature and encryption to ensure that the app has not been tampered with and comes from a trusted source.
To open an .appx file, you just need to double-click it. This action will initiate the installation wizard. It will display the application type, publisher, and version, as well as what capabilities are required for your application to work correctly. By clicking the Install button, the installation will start (no other actions are needed).
As MSIX is designed to be the successor to AppX and aims to provide a more modern and versatile packaging format for Windows apps, the key differences between the two made MSIX the preferred packaging solution for the Microsoft Store because:
MSIX is the recommended and preferred packaging format for Microsoft Store, it offers more benefits than the older AppX format, it's the format required for new apps and app updates for the Microsoft Store after September 2019, and it's the next generation of packaging format for Windows apps.
Technical Writer at Advanced Installer, Technical Engineer on various enterprise client projects. Experienced in Software Packaging, SCCM infrastructure and System Administrating. Tech enthusiast and music producer in his spare time.
I was looking for some way to check if the package was actually created as a msix package, or was just renamed from .appx to .msix, but could not find anything in the content which could help me check this.
What specifically would you like to determine if it was an .appx vs an MSIX package? From a functionality perspective all of .appx was inherited by MSIX. However, MSIX is not fully backward compatible to .appx.
As per the document, MSIX is supported on Win 10 1709 and above. However APPX was supported on versions earlier than 1709 as well. Now there is no option to the manual tool (makeappx.exe) that guides it to generate MSIX or APPX.
From a packaging perspective you don't really need to differentiate. The runtime will pick up currently based on the manifest declarations. It won't affected deployment since they share a common deployment stack. Think of a .appx as a really restrictive MSIX file. MSIX will light up new feature sets and includes out of band items like the package support framework.
John.
I think that given the design, the intent is that you would look directly at the MIN version and Max Test version associated with the package rather than directly looking at the question "is it appx or msix".
This might not meet all the situations (challenges like the new deployment possibilities to back rev OS come to mind), and I think checking the manifest for references to the msix schema would be the most reliable method for someone to determine. But in the end if it doesn't meet the min/max info above, the point might just be moot.
Rather than filename, one should look for the RunFullTrust capability in the AppXManifest file. This is the one thing that allows Win32 and .Net Framework code to be able to run inside the container. Yes, the MinVersion also needs to be at a given level, but even that level is now out of support, and AppX/UWP apps can use the latest minversion as well.
Yeah, that is what I am going to try next. I finally figured out how to mount the image, change a file (the StartMenuLayout.xml), and dismount the/saved the image. I then used ImgBurn to create a modified .iso that I am testing. If this works I will try using the remove-appxpackages powershell cmdlets and recreate the .iso again.
Ok. I finally got this working. Turns out my issue was with the version of PowerShell/DISM I was using. To get this to work I had to move to a Windows 10 system and I did the following. When I tried this same process on Windows 8.1 I constantly got the error that I had the wrong version of DISM.
I came across this post and found it very helpful as I was able to get the wim as per my needs but is there a script which we can run while capturing the wim where we can remove the App tiles for the removed apps as they are still getting displayed displayed in the start menu?
I followed these instructions and verified that that apps have been removed from the wim. However, after recreating the iso and running through install, I find that all of the apps are still installed. Tried installing both online and offline, with the same results. Windows 10 1803 VL iso.
I have figured out how to address using the specific Index number. If you use this command after running the Dismount-WindowsImage save command this will create your image using the specific Index number you choose.
My goal here is to be able to deploy this version of OneNote during imaging. We currently have it in Software Center as an available install but I've recently discovered that appx files are not supported during imaging.
When I test this in Software Center, it reports as installed but it doesn't actually install. If I launch that script from ccmcache through terminal, the app installs fine. Does anyone know of any reason as to why this won't work?
Dang, no it doesn't. I saw a post somewhere that says Appx files cannot be installed as system and must be installed to users. I guess I can force install the Software Center version to the devices I need it for. Unless you can think of a different idea? Thanks for the help so far anyhow!
So that worked for the deployment of the package for Software Center (thanks for that!) but didn't work during the OSD. I checked smsts.log and it reported as the install being successful. I'm starting to think that this is just not possible to deploy during OSD.
One thing to check is the execution context when your SCCM runs the script. It might be running under a different user context or permissions setting compared to when you manually run it through Terminal. That could explain why it reports as installed but doesn't actually work.
SignTool sign /fd SHA256 /a /f MyKey.pfx /p paswordXXX exportApp.appx
Done Adding Additional Store
SignTool Error: This file format cannot be signed because it is not recognized.
SignTool Error: An error occurred while attempting to sign: exportApp.appx
A while ago, I experimented with creating an AppX version. Certain things already work, but there are still a lot of things that aren't compatible with an AppX environment. For example, KeePass requires plugins to be stored in the application directory ('Plugins' folder), which is problematic with AppX (and storing plugins in a user-writable directory can be problematic from a security point of view).
The check will be removed when KeePass is fully compatible with AppX. Realizing this doesn't have top priority right now though, because I'm not planning to publish KeePass in the Microsoft Store in the near future.
Our usecase is leveraging msix app attach to deploy the application on a VDI/SBC environment.
We will not be leveraging plugins in such an environment, but I understand you want the application to be fully compatible.
The only thing I can hope for I guess, is have some sort of hidden setup parameter to allow keepass to run in an appx environment, knowing that it will not be supported and not fully functional.
or wait until the issue is resolved of course.
having gained more experience with msix. The application directory in such case is not user-writeable.
c:\program files\windowsapps is where the apps are stored.
msix actually adds additional security by signing the files and the package.
quote;
After deployment, package files are marked read-only and heavily locked down by the operating system. Windows prevents apps from launching if these files are tampered with.
I know this is an old post, but I just want to see if there are any plans in the near future to make KeePass work as an MSIX package. I want to do the same as Sander mentioned, to use MSIX as App Attach in a VDI environment.
Dominik, is there also a reference about the compatibility issues encountered, beside the one that you already mentioned?
Previous research on malicious Windows Apps focused on concrete system infections involving particular instances of such Apps. This article complements previous research by taking a generic perspective. I take an APPX package that malicious actors have used to deploy malware as a running example and provide:
For Windows to install an APPX package, whether malicious or not, the system first has to establish trust in the package. Microsoft provides the Microsoft Store to Windows users as a library of certified packaged Windows Apps. These packages are digitally counter-signed by Microsoft. Windows trusts by default APPX packages that originate from the Windows Store. However, when the Windows App sideloading feature is enabled, users can install APPX packages that do not originate from the Microsoft Store as well, that is, packages that are not counter-signed by Microsoft. Such are the majority of the malicious APPX packages that the security community has observed in attacks.
c01484d022