Sharing the ideas and feature requests put forth during the packaging workshop. First idea relates to enabling of Process Isolation as an optional feature for enterprise for a limited period and phase out the same once MSIX adaptation grows widely. Consider a scenario where in the organization would like to upgrade to version 2.0 of an application Sample_app for a new feature it introduced; However, a modification package Sample_mod of version 1.0 is not compatible with latest version of the application It will be very helpful to have Process Isolation enabled for the version 2.0 of Sample_app for a limited period of time until there is an upgraded version 2.0 of the modification package Sample_mod is made available with all fixes This would enable execution of two executables (Processes) with same name (but different version) Second idea, which is also a request, is to introduce capability to run Post-Install script. There could be scenarios such as – an application INI file contains Localhost address which is dynamically written at the time of application deployment Understanding the purpose of MSIX, which is to eliminate the necessity to have custom actions, scenarios such as above turn out to be challenging without installation time actions Having Post-Install script execution supported in MSIX will ease its adaptation for minority of applications as well which required such customizations Last idea is more of a wish list item. For the Packaging engineers, it will be a much helpful part if an optional Debug Shortcut (preferably a Command Prompt shortcut) option be provided (by default within the tool) Engineers can use this option to debug and identify cause for issues using ProcMon, RegMon etc. Once the Fix is developed, build the Final MSIX packaging with Fix by unselecting the Debug Shortcut option and release the Final build for end users Will look forward for your response and support.
... View more
Per my post here, MSIX packages need to be able to pass command line arguments to executed apps. This is presently not possible. Without this capability, my ability to package legacy apps with MSIX is severely limited, and has forced me to stay with App-V.
... View more
There are times that two applications integrate together, but not using a "plugin" style integration. Both packages would contain executables and shortcuts, but the second app uses "stuff" from the first package.
The connection groups in Microsoft App-V are good for this situation of packaging separately and deploying as a single (layered) environment. Because vendors don't usually release in AppV format, we can also package both into a single package if we want.
If the primary app vendor releases in MSIX format, we never want to edit that package directly. So it would be preferred to package the secondary app up separately and reference the first. The Modification package doesn't work as it doesn't capture shortcuts (and probably other entry points). But even if it did I'm not sure launching a shortcut from the add-on package would cause layering to work correctly.
If you need examples of such apps, look no further than apps with EXEs that integrate office components like Word and Excel.
... View more
In order to easily debug packages, support for launching a non-package executable inside the package container is needed. In App-V there are two methods to do this, either of which could be adopted:
A PowerShell cmdlet like Start-AppVVirtualProcess
A command line switch like /appvve
PowerShell would be the preferred method. We could specify the package name to identify the container to run in.
This would allow us to debug in scenarios such as:
Launching a local PsfLauncherXX.exe with local config.json & tracefixup.dll to enable monitoring of a package without having to repackage. Similarly to test a potential fixup fixup dll prior to repackaging.
Launching a tool like Regedit so as to see the registry the same as what the application would see.
... View more
At the present time, MSIX is blocking access to TPM (for both Reading from TPM and Writing to TPM) Examples why access to TPM is required: 1. If you were to package a browser using MSIX and then need to authenticate to a corporate Web Site or SaaS application with a Virtual SmartCard (VSC)or X.509 certificate that is stored on TPM, authentication fails as MSIX application cannot read from TPM. 2. If a corporation provides a Win32 application to assist user in obtaining a X.509 Certificate / Virtual SmartCard (VSC) and packages with MSIX .... then when the application reaches the point to Write the certificate to TPM.
... View more
In an enterprise scenario, the data and settings associated with an application could be considered to fall into one of three camps:
Data/Settings delivered as part of the application from the vendor that nobody should mess with.
Data/Settings configured by IT and deployed as part of application and the end user shouldn't mess with it.
Data/Settings configured by IT as defaults, and deployed as part of the application but the end user should be able to modify as needed.
Ideally software vendors would write their products to support these scenarios, but when we are dealing with packaging older applications this isn't always the case. And I seriously doubt that we can get everything the way I want it to work, but we need to do better than what we have.
I view the current Microsoft proposed process that IT creates a modification package as generally addressing the only the third scenario. Quite possibly the software doesn't expose a setting so the impact might fit the other scenarios, but that is very application specific. But when it is exposed, it is unclear if there is a way for IT to easily lock it down. Possibly with files we can mark the file read-only (I'm not sure if this passes through or not), and in the registry I'm also unsure if permissions pass through.
But even if permissions flow through and will be respected, clearly, to me, the idea of IT configuring via a modification package does not allow for IT enforced changes because it is deployed as an add-on package and the end user can just decide to uninstall the add-on to get rid of IT customizations.
I am concerned that this leads to IT opening the package for edit instead of using the modification package, thus loosing the benefits of update. So we need a better way for scenario 2 to happen, and we still need to also allow scenario 3 where needed so it isn't simple.
I don't have a solution in mind, but maybe someone can propose something.
... View more
Welcome to the MSIX Tech Community. Connect, learn, and discuss topics on various aspects of MSIX. Build 2018 has some great sessions featured on MSIX. Stay tuned for links to these sessions, announcements, and availability of new features of MSIX.
Welcome to the MSIX Tech Community. Connect, learn, and discuss topics on various aspects of MSIX. We will keep you posted with events involving MSIX and stay tuned for links to sessions, announcements, and availability of new features of MSIX.