icrosoft announced what they are going to do about Services and MSIX at AppManageEvent in Utrecht in October 2019, but we were able to get more details about them at Microsoft Ignite in November. The following are taken my notes from the events.
Given Microsoft’s stance on keeping things inside the container, we were surprised to hear that the implementation for Windows Services delivered with MSIX packages will not be running in the container. This is quite different than services delivered in App-V packages, which virtualizes the services within its virtualized environment.
Of course, bear in mind that all dates mentioned in this article are current publicly announced plans which are subject to change by Microsoft.
Services in MSIX will be included in the MSIX package, but will be natively installed into the operating system when the package is first added. Here are a few of the details:
- Support for MSIX apps with Windows Services will require OS changes to the AppInstaller. This is currently scheduled for the 20H1 version of the OS next spring. We will see this sooner via the Windows Insider builds. But the bottom line for any companies that skip the 1H releases is that they will need to wait for the 20H2 OS release. Which might take you until 2021 to implement in production.
- Support for building the packages will come sooner in the MSIX Packaging Tool. It should appear in a version expected to be released in January, and might be available now if you sign up for the MSIX Packaging Tool Insiders builds.
- Support for adding Although normal MSIX packages may be installed without elevated rights, MSIX packages with one or more services will require elevation. This elevation shouldn’t interfere with most deployment techniques, but affects manual and possibly scripted installations.
- The elevation is triggered by a new package Capabilities declaration that the package must have.
- We will have to do some testing, but it might be also possible to trigger admin elevation on all MSIX packages, even those without services by setting the new Capabilities declaration. This might be interesting to companies that are concerned with standard users being able to find and manually install MSIX packages that were not assigned to them without admin credentials.
- No word on what happens on a multi-user OS when the second user has the same app installed when it has services. Presumably a second installation would not be attempted. This will require testing.
- The service installation will be uninstalled when the package is uninstalled. Again, I assume this means only when the last user uninstall happens.
- No word on what happens if the MSIX package is pre-provisioned, I could be that the service is installed either when pre-provisioned, or it could happen when the package is installed to the first user. (Note: MSIX does not have a concept of an install for all users; you can pre-provision to the OS but then the package is “installed” to users when they log in. All of the AppX and MSIX apps built into the OS also work this way).
- It is unclear at this time what types of services will be supported, but, presumably since the service isn’t virtualized all types of services will be supported. We may find that some of these services don’t work because they depend on things lie registry settings outside of the service installation/start/stop settings that won’t be available outside of the container, or require a special logon account.
So while I would have preferred to have had the services virtualized similar to how they were done in App-V, I think we can probably live with this. (Note: I had written a description of the functionality that I wanted in the Ideas section of the MSIX Community Portal, which was a lot like what App-V does plus a bonus of virtualizing the service names to avoid service name conflicts).
In particular we will have to figure out what to do in situations where more than one package with the same service. An example of this is having two apps that both use FlexNet licensing.
The approach is counter to how many Enterprises prefer to deploy applications with dependencies. If the service is to run outside of the container, I expect most would have preferred to keep the service completely outside of the package and deploy separately.
For those thinking that the recently added PSF scripting for MSIX might be a way to deploy the service, this only works in scenarios where the package is installed from an already elevated process (or one running in the local system context), as you don’t want the end-user getting a UAC prompt.
It is also curious that device drivers don’t work like this at all. Device drivers are referenced in the package, but remain outside. A mechanism is included in AppInstaller to detect the reference and have it cause a driver installation via Windows Update or WSUS.
Finally, I’ll note that my friend Jason Samuel noted that MSIX App Attach, a deployment option for Windows Virtual Desktops, has indicated that they are not supporting the new MSIX services as it doesn’t really work with that technology.
NOTE: Please take the MSIX Community Survey on our sister site M6Conf.com and let Microsoft know what you think about MSIX.
