MSIX Packaging Fundamentals Q&A Webinar Summary

Tim replied: “I think it's going to take a while for that to happen. I remember being on the Microsoft campus in 2001 when they announced .NET and it still took another six years before developers really largely releasing products in that new type of technology. It takes a while for that whole group to move over from what they have been doing to what they're going to do in the future. Particularly if they have to redo everything in the process.
Initially, with MSIX there was a lot of that -- even though Microsoft made a good story about how we could take the existing apps and bring them over. The PSF(Package Support Framework) wasn't quite up to snuff and that's been a work in progress and it's improving but it's still got a ways to go but it really required developers to go in and make some changes and about a year ago Microsoft announced some changes for developers that they're still in the process of releasing so this is all the .NET Core three stuff that ideally is coming out by the end of this year in a release format and that's really the signal that gives developers a chance to say okay I can base a product on this and that's a set of changes. That, at least in theory, allows them to do a much better job of mixing and matching old and new style programmings all within the same package. Now, exactly how great that is on day one it may be like a lot of the other stuff we've seen. With MSIX where it's going to be some good basic capabilities but there's still going to be the need to have some more things added so whether they're going to jump on board and we'll start seeing a lot of products come out in this way next year or if it's going to be the following year we don't really know yet but you know something that's going to come is going to take time and it's even when the capabilities are all fully there it's probably still going to take another you know five years for the vast majority of applications to be released by ISVs into this format but clearly is something that's coming everything Microsoft is doing that is new for the programmers is in the newer interfaces that will require them to go this route.”

Bogdan replied: "Let me start with addressing the elephant in the room.
Even though Windows 10 comes with a lot of built-in apps packaged as MSIX, everybody wants to see more MSIX apps delivered by Microsoft, and the number one app everyone wants to see is Office. But let's be honest, Office is not a simple elephant, it's a freaking mammoth, folks, so for those of you that have used the App-v version, I'm sure you remember it took a while for Microsoft to deliver it as an App-v package - it's not something easy, but we know they are working hard to make it happen. They've learned a lot from the previous experiences with application packaging and deployment, and we need to give them time and feedback to properly build the MSIX engine without forcing them to take shortcuts and give us custom actions or something wilder like we have for MSI's.
If you want to see a detailed list of what's on the MSIX roadmap and even add your own suggestions, we recommend going to the link. There you'll find the list with the most requested improvements where you can upvote them and also the backlog of the MSIX team from Microsoft.
So, there's no simple answer to what they should improve short term and long term. If you go to the Office package, obviously, once we'll have Office as an MSIX, we need to make sure that all the Office add-ins work properly, and that's probably the biggest challenge that Microsoft has right now with packaging it as an MSIX.
There are other app communication challenges that the MSIX team is facing, so we're pretty confident that we'll see major improvements in this chapter in the following years.
It's been only two years, I think since MSIX was officially announced, and already the platform is a long way ahead in adoption and capabilities. "

Bogdan replied: "This is a classic challenge that's hitting us every time we need to get out of our comfort zone. By us, I don't mean us as Advanced Installer, just us, as normal people, when you need to learn something new. Even at Advanced Installer, we had similar talks about our involvement in development resources for MSIX.
Some colleagues believed that we were investing way too much development time into MSIX with very few people using it. Two years ago, a fourth of our team was investing their full time on this, and even now, when we have even more resources on this, the MSI is still the main package delivered by our customers.
You have to start from somewhere; if you start, this will allow your packaging team and your deployment team to familiarize themselves with the technology stack, discover the most common problems, and establish mitigation protocols.
Every organization has a small set of non-critical applications that can be easily converted to MSIX and another set that requires a little bit more work to get things going.
Obviously, you should start with the easy one - this way, you learn to tooling, and then you also upgrade your skills along the way.
If you look back on deploying MSI's or App-v packages like ten or twenty years ago, it wasn't that straightforward as it is today.
All this technology also started in a hybrid adoption model, so you were still using the old script way of packaging, unzipping applications. Then you started easily packaging MSI's or repackaging all your applications and so on.
Any new technology requires a gradual adoption, and we must be patient with MSIX, too, but keep in mind this MSIX is here to stay. This is the future of application packaging, as stated by Microsoft. They are investing a lot in its development over the last two years.
As I said, they've been delivering major improvements, and they continue to do so. It's very important that, while you are starting to use MSIX, you will have problems or questions just like the ones that you're sharing with us today.
Remember - always share these questions on the MSIX community at the techcommunity.microsoft.com/msix.
This is the best way for MSIX to evolve - where you, as an end-user, come in with real questions or scenarios, and Microsoft, together with partners, can learn from your experience and improve the technology.
Otherwise, they would be just guessing from Microsoft's product management teams and not that much involvement in the development. But I'm sure that you guys have a lot of questions and a lot of scenarios that need to be covered, and so far, the engagement of the end-users and those community forums has been great. We've received a lot of good feedback to improve the tools and Microsoft's platform.

Tim replied: “MSIX uses a very similar format to the UWP format, it's also very similar to the App-v format in all cases. What we have is a basic zip compression with an internal manifest file. Unlike the traditional MSI style of installs, the installation doesn't necessarily drop things into various system registry locations and certain file locations. Still, the manifest is really the piece that defines how this application gets instantiated when you install it, how it gets integrated with the user in the operating system.
So all of them share that common style of doing it. This is the modern way of installing. The difference between the technologies is really what's in that manifest. And all of the manifests are built on a basic app x core in terms of the schema that's available. But App-v has an extension to the schema that is quite broad and covers a lot of different integrations, and MSIX has a today smaller integration set. It's a different set of extensions of how you describe the way that the application interfaces. And when MSIX first started came out a couple of years ago, that extension was a little bit smaller. Still, every six months, Microsoft is coming out with more and more extension schema to enhance the capabilities of how these applications integrate the idea.
As we start looking at things like RDMS, and you talk about App-v, one of the big reasons that customers use App-v in a multi-user scenario or VDI scenario is to get that really fast publishing time. MSIX has something that's called "MSIX AppAttach," which is Microsoft's solution to do the same type of thing with the MSIX packages.
So that's something that I think I saw yesterday; maybe it wasn't even released. It's getting awfully close to actually being released and what's getting released is the Azure implementation of that. We expect other vendors to be doing their own implementations of an app attached for those that aren't hosting up in Azure, but that's really kind of the future direction there as well.”

Kevin replied: “With modification packages, it's a bit of a mess right now. One of the things you got to look at is if you want to take a store app and apply a modification package, the management tools don't really do it for you like with SCCM.
You would have to add that in manually, which would mean you'd have to go to the MS Store, get an offline install of the app, and then put it into SCCM with your modification package. But then, it also comes down to what you want to do with your modification package. So, if you're just making some settings modifications, probably is not a big deal, but the big thing is looking at the file system because if the vendor did not package the MSIX package as a VFS package, then the modifications to the file system may not work out so well.
Microsoft may need to fix, but this comes down to how the package was actually built by the vendor.
The management tools should be better at dealing with the modification packages, but it doesn't seem to be fully mature yet. I think the management tools have come a long way and provide a lot of the functionality you need, but I think there are some rough edges we still need to look at. “

Kevin replied:" So this is a tough one because ideally everything's going through the MS Store, and we're going to have applications that are going through a vetting process with Microsoft as they go into the store - and that's a trusted model for delivering your software.
The biggest issue with the Microsoft Store I find is that if a vendor makes a release available, there are some delays in getting it through the store ecosystem. The other piece you have to look at is, if they sell their app through the Microsoft Store, the software vendor is taking about a thirty percent commission of their software that goes to Microsoft.
Now Microsoft is just not simply cutting a check like they are providing a service with the Windows Store, but if it's a ten-dollar app, thirty percent it might not be a big deal.
It's gonna come down to where the ISV feels comfortable because you have the app installer method that I included in the book, and I'm really wondering how many software vendors are going to say: "No, forget everything! I'm going to manage my software releases", and it's going to be done with the app installer".
I'm not sure if enterprise shops would really accept that, but I could see software vendors wanting to use that distribution method for their application. Otherwise, we could see a lot of MSIX packages being handed over for distribution with Configuration Manager or Intune.
Those methods may be the path of least resistance for some vendors.
I deal with iOS and Android, and I can't believe the number of small developers that hand me applications as a file and say: "Please, go deploy this". I have to educate them on how they integrate with the store for those platforms to get their applications properly distributed. Windows is unique because, with Windows, an MSIX package is basically deployable. I know there's some stuff with signing and all that, that you have to consider, but for the most part, it's deployable.

Bogdan replied:" Integrating with Shell Extension was always a challenge for virtualized applications, and MSIX is no exception as we can all see. Obviously, we don't know when Microsoft will provide us with a solution; even when they provide us with a date, that's usually not the real one. So far, we haven't seen any updates on this one.
We know for sure that this is a topic well-known to them, and they are working hard to provide us some solutions.
So far from our tests, we've seen that we can only define a shell context menu, and by context menu, we refer to a menu that has as a target an EXE application. So, that's defined in the package manifest of your MSIX package. It didn't work out in any of our tests when we tried to define a shell extension where the target is a dll. You can read more about this experiment on advanced installer dot com slash msix context menu . But, so far, this capability is a missing feature that we've all been hitting into it."

Tim replied: "To be clear in terms of the context menus, what Microsoft has in there is support for file type-specific context menus. If you right-click on a .zip file, the context menu for that works in the shell extension. What doesn't work is the wild card - so that you can right-click on any file, which is probably the most important shell extension on the context menu for an app like 7-zip, and that's what's missing, and that's what they have to add in and. Given how they build MSIX, it turns out to be one of the more difficult things for them to change, even though it is like a three-character change in a schema. It's still going to end up involving thousands of people over a long period of time for them to fix that."

Bogdan replied: ”So, first of all, just to make it clear for everyone because we've seen this confusion in some other questions. PSFTooling is a separate tool built by Tim and is not part of the Advanced Installer or its functionality for the Packet Support Framework integration.
Now, back to the script support from Advanced Installer. At the moment, you cannot add scripts automatically when converting an MSI or EXE to the MSIX package. After the conversion, you need to open the Advanced Installer project, go to the AppCompat view and manually add the script using our user interface.
We'd love to learn more, to understand why you want to automatically add, probably the same script, I assume, or some slightly modified script. So, please email me at the bogdan advanced installer that's my first name at advancedinstaller.com with more details - why you need to do this, and we will gladly evaluate it.

Tim replied”: PSFTooling is a separate thing that I do, and it is a tool that you would use if you were doing your packaging using the Microsoft MSIX Packaging Tool. If you're using Advanced Installer, they have equivalent functionality to do things of bringing in the packet support framework.”

Tim replied: ”It eventually might be possible if anyone has worked with PSFTooling for a while. You've seen a constant update to it where we really start out with some really raw capabilities that are individual, and we've been kind of consolidating them and trying to automate that.
Quite frankly, in the future, I don't look at PSFTooling as the way that I would want to do that automation process. If you take a look at some of my tooling for App-v, I have a tool called "TMEdit", and TMEdit has an automated method - so there's a GUI method, which is what 99 percent of the people using TMEdit use. They use the GUI piece of that to post-process edit the package.
What I'm looking forward to in MSIX is going to that type of thing within the background; there's also an automatable way. So, there's a command-line prompt that you can feed in an XML file, and it'll just automatically figure out what needs to get added into your package and put in the PSF components and configure them for you.
That's probably more likely what we'll see, but it's going to take quite a bit of time before I get there.”

Kevin replied: “If you're doing any sort of manual installation, you're basically stuck with elevating somehow. Technically, if you're building a fresh OS, you could use a provisioning package, but you're basically an administrator at that point. You're probably looking at using a management system like Intune or SCCM to auto elevate for those packages that need to be installed that way. By default, you know it will install per user on Configuration Manager and that you have to specifically tell it to install per machine if you want it for all users.”

Bogdan replied: "Of course we can. We've provided the free book, so the URL is simple. First of all, you can find the section - which is called "Predefined fix-up" in the book. There you'll find listed all the fixed apps available for the Package Support Framework at the moment. There are also a few paragraphs about each of them to understand how it works and how you can apply them. A similar list is on advanced installer.com package support framework introduction. It's an article I wrote like six months ago, which explains the Package Support Framework and summarizes the fix-ups list. Now, this list is precise to a certain level, so we have the fix ups that Microsoft has added by default in their GitHub repository. Tim actually added I think, two more fix-ups, one for registering, one for environment variables on that list. Depending on the packaging tool that you're using, there might be additional fix-ups automatically included just when you're doing the packaging. For example, with Advanced Installer, we automatically detect that you have additional command-lines or a working directory that needs to be set for your main application and the other stuff like that or migrating app data, but that's a different topic. The official list of fix-ups, as I said, is in the book. Maybe Tim wants to add more details on his predefined fix-ups."

Tim replied: "Microsoft hasn't really talked publicly at all about what they're going to do with the PSF. Quite frankly, what I've seen is that they did the initial development, and they've really then just dumped it on the community. So I'm the one that's done most of the work most recently, and I've been pretty active in adding additional fix-ups as we need them. Right now, I'm actually putting that work a little bit on pause because I think we're at a spot where it's probably more important to get more towards, making the process easier rather than getting more types of fix-ups. So once we figured out how to make it easier, then we'll go back, and we'll start retaking a look at it: What are the other types of fixes that we need to create to be able to get more and more app compatibility."
Bogdan replied: "Well, I think we have a solution for the easy part, but we'll keep it for the next webinar since that's not the topic but just a spoiler for the folks that are live here. In general, it doesn't matter what tool you're using; you shouldn't say:" Hey, maybe this tool doesn't have the latest version of fix-ups". If you know how to use Visual Studio, you can always clone the repository from GitHub, build the available solution, and get the DLLs generated as output, and add them as fix up with whatever tool you're using: MSIX Packaging Tool, Advanced Installer, Install Shield or any other tool that you're using to build your MSIX packages."

Tim replied: “The answer is not really. The documentation for the format on config.json is included in the GitHub repository. Now, you don't need to be a developer to understand this part of it. It's really in the READMEs associated with the Package Support Framework up on GitHub. In the READMEs, it shows you the various configurations. So there's a basic overall configuration, and for each of the fix-ups, they have specific configurations. Now, quite possibly Bogdan just wrote down a little note that we should have an article that describes this on my website, and who knows, maybe they'll do something like that for you in the future.”

Bogdan replied: "It depends on the packaging tool. As I said previously, you can have a shell context menu only for a specific file type association that you define. You cannot have generic wildcard ones like 7zips in this case. But if you have like a generic file association, let's say you're repackaging the Edge, since we still don't have an MSIX package for Edge, and you want to associate HTML files with opening with Edge, you can have the packaging tool to detect this association at conversion time. For example, Advanced Installer has a high-level conversion of elements like file type associations or any other constructs that need to end up in in the package manifest. From what I know, the MSIX team from Microsoft was working on the smartening up of the MSIX Packaging Tool to recognize this type of manifest package resources.
In some cases, you need to manually edit the manifest and tweak it. In the particular case for 7-zip, as Tim said, you cannot have a Shell Extension. But in cases where you know that you have a specific file type association for an application and the packaging tool that you're using hasn't detected that you need to manually add that by directly editing the manifest - if that tool doesn't provide you with a user interface, or if you are using Advanced Installer by clicking two buttons. And it also gets synced automatically between MSI and MSIX build.
If you have an existing project where you were already building an MSI for that application when you duplicate that build to create an MSIX, everything is converted into the corresponding package manifest entries, so you don't have to manually create them."

Bogdan replied: “First, this is a very good question and I'll add some context for those that don't understand Dan's question completely: when you digitally sign an MSIX package, Microsoft imposes a strict requirement for the publisher of the package to match the public share listed under a certificate, and the publisher of the package is written down in the package manifest. So if you have a set of packages already built, the chances are that they have a different publisher. Is it either matching the publisher of the test certificate used by somebody from the packaging team or matching the publisher from an outsider independent software vendor. What Dan wants now is to automatically update this publisher to match his enterprise certificate, I assume. One solution is just as you said, Dan - you extract the packages, you create a small script that just replaces that line in the manifest, and adds your certificate publisher then, you can use makeappx to basically re-bundle back the MSIX package and then resign it with sign tool. Otherwise, at the moment, it depends on the packaging tools. Now, for example, Advanced Installer has a command-line interface only to edit MSIX projects. So, we have an MSIX editor with a UI that allows you to edit but that doesn't have a command-line interface at the moment, so you cannot launch it from the command-line and set publisher name. If you have a project for the MSIX package, in the case where you are editing an existing project that you're maintaining, you can just run command-line tools command lines from Advanced Installer to just set whatever variable you want from the package and we have a command for the publisher name and then you just execute the build command and it builds the MSIX with the new publisher name. What we do if you use the UI, you'll see that we automatically detect that a new certificate is being set for the project and we try to sync it automatically. I don't think the Microsoft PackagingTool - MSIX Packaging Tool does this but I expect that other vendors will be doing this synchronization in the past because from what we've seen, especially for new people trying out MSIX, this is the top of the list mistake that they do. They forgot to sync the publisher from the certificate with the one from manifest and you can't even install the package and that it's just annoying.”

Kevin replied: “It's coming back to using management tools and user targeting. That way it does create a bit of an issue for manual installs that we have to deal with because if the package requires elevation and your user isn't elevated, what can you do the interesting thing. I haven't personally tested. What would be really interesting is to see how the app installer handles this. I'm assuming it would not elevate the user or the install but you know that's something I am not 100% certain on, to be honest.”

Tim replied: “It does, and it does elevate on them, so you have to have credentials to do it so.”

Tim replied: “Not necessarily correct so when you have some software running inside the container it can start processes that live outside the container and it can run inside the container. So as long as you properly configure the config.json you can also have the intercepts applied to those executables. I do that all the time.“

Tim replied: “Yes that is the direction Microsoft wants you to go - there's no doubt about that. Is it still too early though. We are not at a point where we have the ability to take all of our app packages and turn them into successful MSIX packages. We can get a lot of applications that we can work well on. My latest internal testing is showing me that about 60% of the enterprise app we can get working into MSIX in. What I call full fidelity mode meaning the same feature set complete feature set that you would have had natively there's still a whole set that you can't do so if you're thinking about an entire migration project we're going to take everything we have and move it over to MSIX. I'm telling enterprises you're not going to be successful on that project today you're going to get a lot of good stuff that works and I would recommend you start that process. Because you are going to have to learn how to deal with MSIX not just how to get it packaged. There's all the operational stuff on the back end. How does your help desk support these apps? You need to start getting that experience with the simple apps first while the technology evolves and you can do the other pieces later on as we get more capabilities.”

Kevin replied: “Yeah maybe I should finally chime in with a piece I was going to sneak in with Microsoft managed devices. This is kind of hitting organizations in weird ways because Windows 10s mode has been viewed as largely a joke but the fact of the matter is it's an extremely stable secure well-performing platform if you can get there. But the big thing is - is getting your apps onto that device. Now it's very strict - so you're either going to use VDI and remote the apps into the device or you're going to figure out how to package these apps as MSIX apps. And it's funny to watch because if you look at it from a technical point of view customers just turn their noses up at the whole idea of what you're proposing. But you start looking at Microsoft managed services - now I'm not trying to sell Microsoft managed devices because you can do something very similar yourself - but you know you look at how they're selling the hardware, the software, the support - everything for a low low price. A manager looks at that low low price and he goes hey I want that and so then all of a sudden there's this motivation to make some tough technical decisions about what you do with your apps. So when it comes to - are you ready for migration - I guess I should address the question which would be yeah you should be prepared for this. Like it could flip on you pretty fast. I’m not saying you could go Microsoft-managed devices or Intune or modern desktop overnight but all of a sudden a business unit or a user group all of a sudden flips over because they're a good candidate. Now you have to support all that, so I agree with Tim that you have to be prepared; this is something that could sneak in and yelvason have to be an expert.”

Tim replied: “I guess I didn't answer the first part of that question about migrating the app packages over from a batch conversion. I mean, there is a command-line interface the Microsoft Packaging Tool can convert things over Advanced Installer has the ability to convert things over but that conversion is a pretty basic conversion in general. You're still going to have to do a lot of hand massaging particularly if the app would end up needing things like the packet support framework. So it's not just a quick flip of the switch and suddenly your package works as an MSIX package but there are tools there to help.”

Bogdan replied: “Everything that's custom made can be a black hole. At a certain point, Microsoft is striving very hard not to get to that point, especially to stay very far away from where custom actions ended up being for the MSI. And even in that context, everything that is launched by the PSF runs in the container content context. So it's fairly secure because it's contained inside your application and shouldn't have access to information from other applications on your system. If you elevate your applications, so somehow you allow your users to elevate your application from the PSF launcher, then probably they could do a lot more damage with some black box script in there, but if you just keep it clean to a script that handles a license file or some id configuration, something that you need to be handled by the scripts, there shouldn't be any black box. It's a partial script, it's visible in the package so it's very easy to inspect what's in there and it should be pretty safe as long as you don't push this too much. I see this because PSF scripts are practically intended to be used mostly by IT Pro, so we don't expect, we don't have an official answer from Microsoft but we don't expect to see applications published in the Microsoft Store that use PSF. It doesn't make any sense because PSF is intended for applications that are no longer maintained, no longer under active development, so if you are an ISV who does active development then you just fix the app itself and make it work nicely inside MSIX container. So it's also related a little bit to self-control, I could say here, and if you impose the right standards in your packaging team, there shouldn't be any problems with this.”

Bogdan replied: “ I assume that there are others like Robin that are confusing and believe that the output generated by Tim or by Advanced Installer or by other packaging tool is different. And that's not the case. So the PSF framework is a standard that is employed by all the packaging tools. What's different is that some tools could provide additional fix ups but they all leverage this same architecture, they all connect to the PSF launcher in the same way, so if you write a PSF fix up, all and you just want to add that in a package built with Advanced Installer or the Packaging Tool and the PSF tooling from Tim, it should work in the same way as long as you correctly configure the config json. So there is no difference in that. The only difference is in how easy the tool makes it for you to realize what fix up your application needs and how easy it is to add that fix up into the package. Once you start using it, I assume that you probably haven't added any PSF fix ups at the moment, Robin, once you start adding a fix up into your package you'll see that that's the difficult part to understand “hey I need a fire direction, is it failing to load my DLL from a relative directory “ or something else like that. That's where different tools treat this differently and. We'll have a separate webinar probably at the beginning of the next year where we'll show you some cool improvements that we have for the PSF support in Advanced Installer.”

Tim replied: “Microsoft has talked about that feature. They've used different names for it each time I've heard them talk about it and it's something we expect to see in the future I’m hoping the near future. There clearly isn't any support for that, that I can find in the h2 release of the OS this year, so we'll be taking another year out, and of course then whenever you actually deploy that version of the OS as well. So they still have some work to do to get that out to us, but there is that idea that we'd be able to have multiple independent packages all joined together to run inside the same container. We even heard Microsoft on stage at Ignite talk about it in a way, where they said you could just take all your MSIX packages a user if you wanted to, so they are definitely working on that we just don't know when.”

Kevin replied: ”Yeah, that's an interesting comment considering connection groups were a little bit touchy depending on how much you strung together.”

Kevin replied: “This is a lot like App-V. Basically, you can interact with the locally installed applications where it falls apart is when the locally installed application needs to access a resource like a file or a registry key that's inside the MSIX package. That integration doesn't work so well, so it depends on what you need to accomplish. I’ve seen applications do all sorts of ways of interacting with, like Adobe readers. Most of them are smart and they just hand over a file but I’ve actually had an app that actually looks for the adobe reader com object and checks the document across that way, forcing you to have Adobe reader installed locally. So well actually no later versions of App-V you could expose that comm interface but anyway that's a bit of a rabbit hole. The thing is that it's probably going to be a reality for making some of this stuff work because I don't know what mixtures we're gonna see on the device of locally installed apps and MSIX apps. Ideally, everything would be MSIX and they would be talking to each other in modern ways but there's just so much baggage with old apps that we have to deal with. I don't know, it depends on the industry and the job function like some of the worst integration scenarios I saw were in the oil and gas companies because they had engineers that were using like four to five applications that talked to each other but weren't all from the same vendor and you had to package that up with that App-v that that that that made for some interesting situations.”

Tim replied: “We're really kind of going to the basics which we kind of skipped, we sort of assumed everyone understands the basics but from a basic standpoint, you know why MSIX and I think we should kind of address that a little bit. It's very clear to me that MSIX, in the long run, is going to be a better way to be deploying applications. If you look at the whole evolution of the computer industry, you know we really started out with these single-user computers, and we did have no separation between what a user could do and what was protected for the system. Over time, we had to evolve that and separate out the kernel from the user, and then add multi-user in it and separate the users from each other. This is really just part of that next level of evolution, of isolating down at that app-level and making sure that our systems are secure and that we can update and we don't have to throw away the entire image every year and a half just to get decent performance out of our system, so that's the entire goal out of all of this in the long run - to make our systems better and we have to go through a little bit of pain to get there. I think it's really going to be worth it in the long run. From a business today, what I'm telling my customers is: ‘Look, MSIX is the future, the app development world is my mind, definitely gonna go there’. Eventually, it's gonna take them some time to really get there, but they're gonna get there and you're gonna end up dealing with MSIX. I don't think you can just totally ignore it, but if I gotta deploy out a thousand new applications next month I'm not gonna pick MSIX as a way to do it - that it's gonna be a little more work, and some of them aren't gonna work. I view App-V as the technology that can probably do most of those applications today, and it can't do all of them. There isn't any single technology that can not even the MSI, so you have to end up with a mixture of these things in your environment.”

Kevin replied: “My personal opinion is Windows is slowly evolving to be a phone OS, and that means you have MDM, you have S mode, you have MSIX applications. Basically, you want to make this thing as stable and rebuildable as possible, and you know, you just see how Microsoft's trying to shed legacy components. It's going to be a long journey because Win32 APIs are going to be very hard to kill off, but Microsoft's moving that way. When we can get a proper S mode device with modern apps it's a very different experience with Windows than we have today. I wish I had my own data but Microsoft with their users that are using modern devices they're saying that they're getting a lot of positive feedback from the user experience. This will be interesting to see because ultimately, you need to get the apps on there to have a happy user. Right now, it's a very small group of people that you can focus on this modern vision but it will grow and it will generate demand for modern apps.”

Bogdan replied: “Definitely and maintaining Windows 10 as a service practically with a bi-annual updates model it would be a challenge if you wouldn't start adopting a modern packaging and deployment framework around it because as Tim said you don't want to do imaging all day long.”

Bogdan replied: “We have to mention that these are separate tools, so Tim has its own tool, Advanced Installer has its own licensing system agreement. For Advanced Installer you can simply go to Advanced Installer Purchase and you'll see all the editions available there and the pricing, and it starts from 499 and it depends on the features that you need. For TimEdit I really don't know at the moment to be honest but I think you can email him and he has more details on that.”

Tim replied: “It's also directly there online, you can purchase it online so go to tmurgent.com for that one.”

Bogdan replied: “What I can tell for sure is that Microsoft wants to keep MSIX apps in running user mode only, most of the cases. So besides some exceptions like the MSIX Packaging Tool, which requires elevations and other special tools dedicated to IT Pro, their idea is that they don't want the MSIX container to install machine level resources. We've seen not the best, perfect hack with the solution they provided for services now, in the latest updates, I think it was six months ago, but we don't expect to see something similar with drivers. We don't have any signals from them but from the initial announcements they had in the first year of MSIX, there was a clear, strong message from Microsoft saying that drivers should be deployed through the Microsoft Store and not as part of an installation package.”

Tim replied: “Microsoft's answer with drivers right now just doesn't really work, so they're assuming you could trigger it. The idea is you could have it marked inside the package and say hey, I need this driver, but you have to deploy that driver through the Microsoft Store or potentially a WSUS server. Although I'm not quite sure that that ladder actually has support for it in there today, which means the driver store is really missing, and I think it's something that Microsoft has to continue to try to address going forward. As far as the overall extensions within the product, clearly, we don't have everything that App-V has today, but we also have some things that aren't there in App-V. We don't necessarily trigger those things with traditional exe based, dot-net framework-based apps, but these are the things that developers are wanna add for the future and that's where we'll get extensions that do things that we really can't do in App-v today.”

Tim replied: “Yeah, I am planning, so for those who don't know, I have a site m6conf.com where I post the MSIX report card, and I've done this for the last two Januaries up there. It provides an overview and includes a lot of testing of normal enterprise applications, so I think I had 60 in it last year. My current testbed has, I think, 65 or 66 in it. I did do some preliminary testing this summer, working with the 2004 os, and I can tell you that's where I saw some much better numbers. I was getting up to almost 60 percent compatibility. I am planning to do that work again. I am behind schedule; I should have already started it, so it might not hit January, but at some point this winter, I do intend to have another version of that report card out.”

Bogdan replied: “My idea is that, first of all, because you're running as a containerized application, this changes everything. As Tim said in the past, with MSI or even before MSI, the application was having access to all the resources from the system, and that made it easier for the development team from Office to create a package, and I can bet that in the first edition of the MSI where they lacked a lot of support for native integration with the system, they basically added a bunch of scripts and custom actions because they could do that. Now there's no longer the case for that, so they need to play the clean game from the beginning, and that's why it's so hard to get the Office suite inside the MSIX package, especially the Office add-ins.”

Tim replied: “Fortunately, I am an MVP, so I'm sometimes subject to seeing some things that I can't talk about, but in this case, I've actually actively avoided talking to the Office team whatsoever, so I can speak openly to what I think. Office is not just a single thing, it's a whole series of products. If you just take a look at the way little things like the ribbon got added to Office, it didn't just hit all of Office, it hit one product and then hit another, and then hit another. I think when it comes to MSIX, Microsoft is faced with the same sort of thing. They have completely independent teams that have to do this work. Quite frankly, given the way that Office components integrate together themselves, they probably need that equivalent of the connection group, so it can all run in a single container when it happens. So we may end up seeing parts of Office come out in MSIX but not all of it, and it will be a little more limited initially, but over time clearly, if Microsoft wants the industry to move to MSIX, their platform product Office has got to get released in an MSIX format.”

Kevin replied: “It is, you have to eat your dog food, and it's funny because with s mode right now they're faking the modern Office bits, so they really need to complete that vision.”

Kevin replied: “That would be a bad one, I think. I don't know, I've never tried Internet Explorer 11, but no, you need an external target - that's not even supported in MSIX.”

Tim replied: “Right, there's really no way to do that, and I don't see any appetite in Microsoft to try to make that work.”

Tim replied: “Quite frankly, you have your choice there. With App-V, I have a tendency to keep dependencies inside the package so that everything is all in one place. I know Kevin has, even under App-V, a very different attitude towards that, and I think folks that are deploying through Configuration Manager tend to feel more that way; you want to separate out dependencies and manage them separately. With MSIX, we again could go either way. MSIX does have a nice way inside the package to reference dependencies that are also MSIX things as well, so we can make use of that capability, and that's one of those things that we haven't done a lot with yet, but I think as we get more and more things under MSIX, we're going to want to do that. Ultimately with MSIX, if I put that same dependency in more than one package due to the single instance storage nature of MSIX, we're not really bogging down our systems, there's really only going to be one version of that component put down on the system.”

Kevin replied: “That's true. I was wondering about the dependency packages because, right now, it seems people are using it for run times and stuff like that but lacking my packaging expertise with it, what was the potential for the dependency packages? Could I say, make an Oracle client an entire dependency package?”

Tim replied: “You could, the issue becomes really, quite frankly, the tool support to make it easy for you to put that in. You'd also have to make sure you're still going to need to deploy that dependency through a Configuration Manager or an Intune as well, so you're still going to have to manage that process. It's not going to automatically happen but the package install would require that piece to be in place.”

Kevin replied: “Okay, I was just unclear if the dependencies had to be obtained from Microsoft or if we could actually build our own.”

Bogdan replied: “There are very few ones you can obtain from Microsoft like the Visual C++, register bootables...”

Bogdan replied: “First of all, because when you're packaging the app, you end up with a containerized app, you should be very careful with apps that communicate with each other by sharing files for the registry - that will be the problem number one and, especially with older apps where developers weren't using inter-process communication or other ways of communicating with the apps, because now you have app services and Microsoft recommends that you update your code to leverage these frameworks.
So sharing interrupt communication using shared files or registry is one thing, and another one is drivers. Anyway, probably you'll have some apps that try to install machine level resources like drivers or services - it was recently added support for services.
You need to be careful with what version of Windows 10 the clients are running inside because the latest features supported by MSIX like services or some improvements, such as improvements to the shell extensions, will not be backward compatible with all the versions of MSIX.
Very few features that Microsoft introduced work backward compatible with the first version of Windows 10 that supported MSIX. So, assuming that you will need one or two more years to get up to date, the timeline is like, I think, 18 months; you cannot be on an older version of Windows 10 that's 18months older. So it takes between one to two years to get there. Make sure that when you're trying to use the latest features from an MSIX platform, you have the Windows 10 up to date for the entire department where you plan to deploy those apps.”

Tim replied: “If you're doing repackaging for a customer, most of the customers that are going to use an external packaging company are going to be these larger enterprises that have a lot of the older legacy applications. That's my experience, and those are the ones that you're going to have the most problems with. So you're going to have to manage that process with the customer to make sure they understand. You're not going to be able to do everything, the technology is just not ready to do all of their apps. but we can do some of them if you really want us to do that, you're going to have to really focus on that testing and you're going to need to work with the customer to find out what level of that, what I call application fidelity do they need. Do they need every single feature to work exactly the way they worked before, or can they live without this shell extension that's not going to work here? So I normally look at smaller, more agile companies that are not risk-averse as being better candidates for that, than a larger company that has lots of things like change control boards that get involved. Those are the companies that are going to have applications that are going to pass that smell test and are going to need more time before MSIX is ready for them.”

Tim replied: “AppAttach is about rapidly taking the MSIX packages and making them available particularly for instances where the user is logging in or getting deployed upon login, so it speeds up that process. It basically involves converting the MSIX package format into a slightly different format, but it's still running inside the container, so there is no difference. It's just how does it get down there and it acts a little bit more like a layering solution, or from those from APPV may be looking a little bit more like the shared content store mode, so that the actual bits don't have to come down to the virtual machine that you're running the application on. It just redirects remotely in the background to get access to the bits as it needs it.“

Kevin replied: “Hopefully, they'll create more demand for MSIX packages to be put into VDI. I know VDI folks are excited about it, but again we need apps.“

Kevin replied: ”AppAttach would not use Intune for management; it would be separate from it.“

Tim replied: “It would be technically possible even though they don't necessarily have an interface today, would be my guess, as long as we're talking about Intune for VMs running inside the data center.“

Kevin replied: “So that's the thing now, you can run VDI (Virtual Desktop Infrastructure) managed with Intune, which I think is kind of a cool idea, just from the fact that your VDI servers become zero trust entities, which means that if one of them got compromised you can't just leap across to the next Citrix server from there - it limits your lateral movement. Anyway, because of that, you're joined to Azure AD (Active Directory), your authentication is a little bit different, but I think you're okay with AppAttach. You would probably have to manage AppAttach not through Group Policy - they are putting something in the GUI for WVD, but I’m not sure how that works. Our book's Group Policy method would definitely not work with Intune managed devices unless they had a hybrid identity and were actually joined to Active Directory.“

Bogdan replied: “From what I know that's the case. Before this, it was only insider previews, so I think that was the first public release.”

Tim replied: “There's a dependency on there in the PowerShell interface for sure, as well as I believe, the underlying app installer. So while maybe the app installer piece on previous OS’s, I think that PowerShell end of it for the new option they added, is a requirement that you really can only get once you get to that version of the OS.”

Bogdan replied: “We know that we, at Advanced Installer, extended the Microsoft fix app that allows the windows host to basically load HTML files. We had a customer that contained HTML files inside his package with documentation and those were practically not found by the external process of his browser or his default browser, so we needed to create a redirection for that so the HTML files could be loaded. In this case, if it's just a link to an external browser. Have you tested that Tim?”

Tim replied: ”That's just really using the launcher to use the PSF launcher to do a shell-style launch. So then you have to have it tied, and then, even if it was a web page that was within the package itself, you can construct it in a way. That pretty much should work. Certainly, there are going to be some cases of things that people want to put in there that aren't going to work, but generic simple things, absolutely that's going to work.”

Kevin replied: “Isn't containerization still kind of considered app virtualization, or are we split?”

Tim replied: “I consider it app virtualization, yes.”

Bogdan replied: “And the developers that need to fix the app consider it virtualization too so..”

Kevin replied: “I guess also Robin asked about app attach on non - WVD (Windows Virtual Desktop), and I think it works without WVD if you use the group policy method.”

Tim replied: “The WVD that Microsoft is doing is really the management piece on top of that. There are quite a few well-known script methods to be able to do that yourself locally, and you can be sure that vendors who've announced support for MSIX such as Citrix and VMware are doing their own management interface on top of that as well but still using that basic app attached style of capability.”