Flexera recently brought together three industry experts — Bob Kelly, Tim Mangan, and Rod Trent — to discuss everything MSIX, including how it fits into the current tech environment as well as how to ease the transition to modern application customization and deployment.
This post is a compilation of some of the great questions that were raised during the webinar series. I want to thank those of you that submitted questions.
Q. Do you know if App-V is going away?
A. Mangan: No, App-V is not going away. At least not for a long time. That’s part of it being built into the OS. MSIX is a work in progress and will take a while to know what it can really do. Ultimately, the MSIX container is built to protect the OS. App-V was built to protect the app and remediate older behaviors that need help in newer deployments. MSIX is trying to pick up some of that remediation behavior, but it will be incomplete. There is no single way to deploy all of the apps an Enterprise wants to deploy, and you will use multiple methods. You can use App-V for most and MSIX for some newer things that work, or you can focus on MSIX and use App-V for the ones that won’t work there. You decide!
Q. Do you know if there are plans to have a streaming capability for MSIX packages for App-V customers?
A. Mangan: No streaming, but the differential download does what you want. Non-persistent scenario support is still largely in the works, so stay tuned.
Q. Does MSIX support Windows-7 and Windows Server 2008?
A. Kelly: MSIX is native in Windows 10 1809 and above. There is a download to add it to 1803 and 1709 which is the equivalent. For Win 7 (and potentially other Windows OSs) Microsoft has announced but not delivered a solution. Details are sketchy, but I’d bet it ends up natively installing the MSIX package like it was an MSI. So, no MSIX Runtime, no PSF, no integration into modern things.
Q. In the enterprise, will each app packager need a certificate, or will an app packaging team be able to use one enterprise certificate?
A. Mangan: Just started working on that. I think you can do either way. If you trust all of your packagers, you can have one trusted code-signing cert for everyone. Please password protect it, though! Otherwise, you have less trusted packagers use a self-signed test code signing cert with a limited lifespan. A gatekeeper owns the production cert and resigns the package for production. Production machines only trust that cert. The key is that the subject name (a string like CN=company) has to match.
Q. Does MSIX uses any client on the machine to run like Windows Installer or App-V Client?
A. Mangan: Everything is built in. The installation uses a component called AppxInstaller.
Q. How to handle plugins in MSIX (e.g. Office plugins, IE plugins)? Should it always be bundled with the core package?
A. Kelly: Right now, only .exe files inside a package can run. So, having a plug-in package that calls out to a native .exe (or .exe in another package) doesn’t fly. Microsoft understands the problem with that and should be doing something about it. Stay tuned.
Q. Does MISX support an All Users\Per Machine install or are all installs Per User? If MSIX doesn’t support “per machine” installs is that feature coming?
A. Mangan: Installs are always per user (but with Single Instance Storage). There is a pre-install capability that you can use to but the bits into an image and then have fast user-based publishing.
Q. Please discuss the difference between being a software company and packaging vs a corporate enterprise and packaging for internal distribution.
A. Kelly: ISVs will generally use developer tools, like InstallShield in Visual Studio, to produce MSIX packages. Enterprises will use repackaging tools, like Admin Studio to repackage existing installers without access to source files.